Subject: RE: LOOKUPP and NFS4ERR_WRONGSEC

From: [email-masked]
Date: Mon, 10 Feb 2003 12:54:38 -0500

Here is a recap of what's been said as an attempt to clarification (mainly
for myself). Some new thoughts too...

1. PUTFH+LOOKUP

The server implementation may decide whether to impose any restrictions
on export security administration. There seem to be three common approaches
(Sc is the flavor set of the child export, Sp that of the parent),

a. Sc <= Sp (<= for subset)
b. Sc ^ Sp != {} (^ for intersection)
c. free form

To support b (when client chooses a flavor that is not a member of Sp) and
c,
PUTFH must NOT return NFS4ERR_WRONGSEC in case of security mismatch.
Instead,
it should be returned from the LOOKUP that follows.

Since the above guideline does not contradict a, it should be followed in
general.

2. PUTFH+LOOKUPP

Since SECINFO in its current form only works its way down, there is no way 
LOOKUPP can return NFS4ERR_WRONGSEC without requiring protocol modification.

This shall remain a security weakness for now unless the export security
follows the restriction outlined in 1a.

The problem can be solved with SECINFO_P which works in the opposite
direction
as SECINFO (component name is implicit in this case). I prefer SECINFO_P to
SECINFO_CUR (as Mike suggested) in this case since LOOKUPP can now return
NFS4ERR_WRONGSEC without defering that to a later operation (such as
READDIR).
Make it more symmetric to LOOKUP.

3. PUTFH+SECINFO

IMHO, this case should be treated specially.

A security sensitive client should be allowed to choose a strong flavor. The
security flavor chosen by the client does not have to be included in the
flavor list of the export. Of course the server has to be configured for it,
otherwise the request will fail at RPC authentication.

In theory, there is no connection between the security flavor used by
SECINFO
and those supported by the export. But in practice, the client may start
looking
for strong flavors from those supported by the export, followed by those in
the
mandatory set.

4. PUTFH+anything else

PUTFH must return NFS4ERR_WRONGSEC in case of security mismatch. This seems
to be the most straightforward approach without having to add
NFS4ERR_WRONGSEC
to every other operations.

But SECINFO_CUR is needed for the client to recover from this error.

Finally, we could combine different flavors of SECINFO (SECINFO,
SECINFO_CUR,
SECINFO_P) into a single operation, couldn't we?

Peng

> -----Original Message-----
> From: Sergey Klyushin [mailto:[email-masked]]
> Sent: Monday, February 10, 2003 10:47 AM
> To: 'Mike Eisler'
> Cc: [email-masked]
> Subject: RE: LOOKUPP and NFS4ERR_WRONGSEC
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:owner-nfsv4-
> > [email-masked]] On Behalf Of Mike Eisler
> > Sent: Saturday, February 08, 2003 4:30 AM
> > To: Sergey Klyushin
> > Cc: [email-masked]
> > Subject: Re: LOOKUPP and NFS4ERR_WRONGSEC
> > 
> > >
> > >
> > >>>
> > >>I'll agree that the spec has a bit of self inconsistency since it
> > >>says at one place PUTFH can return WRONGSEC, and at another
> > >>
> > >
> > >Don't we need to fix this inconsistency? The way I read protocol is
> > >"PUTFH MUST return WRONGSEC". What about interoperability?
> > >
> > 
> > Well the notion of assigning different security triplets to 
> different
> > file objects
> > is an implementation decision. There is no MUST implement 
> there. Thus
> > why MUST it return
> > WRONGSEC?
> > 
> > PUTFH doesn't actaully compromise securitty so I don't see 
> the issue.
> > Now what follows PUTFH can compromise security, and that's where
> > enforcement might be needed. E.g.
> > 
> >     COMPOUND { PUTFH  ; WRITE }
> > 
> > yes of course, the client better use the appropriate security.
> > 
> > 
> > >>that a fix a WRONGSEC error from LOOKUP, reissue the
> > >>PUTFH / LOOKUP with a different security flavor.
> > >>On the other hand, returning WRONGSEC to a PUTFH
> > >>is an implementation choice, just as allow
> > >>differing security flavors at each file object is an 
> implementation
> > >>choice.
> > >>
> > >>If implementors want to let a customer specify different and
> > >>disjoint sets of security flavors on different objects, then
> > >>the PUTFH can never return WRONGSEC. Conversely,
> > >>
> > To be clear, can never return WRONGSEC when it precedes a LOOKUP
> > that uses the fh that PUTFH injects.
> > 
> 
> Do you mean PUTFH precedes a LOOKUP or LOOKUPP?
> 
> > >
> > 
> > >
> > >for administrator to specify different security flavors 
> for parent and
> > >child.
> > >
> > 
> > As I wrote before, this oversight just means that:
> > 
> >     - LOOKUPP has to be honored if the securirty triplet of the RPC
> > matches that of the
> >         child directory, AND
> >     - a READDIR using any security flavor would need to be permitted
> > regardess what the security
> >         triplet bound to the directory is.  However, thinking that
> > through, it would necessarily
> >         have to be honored. If the client gets WRONGSEC on 
> a PUTFH that
> > precedes a READDIR or
> >         any other operation, and if it doesn't know the 
> parent dir, and
> > the name of the target fh, it
> >         could always try each security flavor it supports. 
> The client
> > should have an idea of
> >         what flavors the server might want ... just keep a record of
> > each unique triplet used from
> >         the time the client mounted the server's directory.
> > 
> > >
> > >I understand that now is very bad time for new operation, 
> so let's find
> > >another solution
> > >
> > So there are two classes of solutions. Implementation 
> strategies versus
> > protocol changes
> > that don't require another spin of the .x file (I think we have
> > consensus that changing the .x
> > file, except to fix my utf8 screw up, are off the table).
> > Let's get consensus that we should solve it via an implementation
> > strategy or via a (non .x file changing)
> > protocol modification.
> > 
> 
> Is it possible to include in implementation section of PUTFH 
> operation your
> comments?
> Personally, I like the idea that client has to 
> > keep a record of each unique triplet used from the time the 
> client mounted
> 
> > the server's directory
> In this case the only exception for NOT returning WRONGSEC 
> from PUTFH will 
> be PUTFH+LOOKUPP. The rest will stay the same as specified now.
> 
> Thanks,
> Sergey
> 
>

---

From: Mike Eisler <[email-masked]>
Date: Mon, 10 Feb 2003 18:35:38 -0800

Peng,

Excellent write up; you've captured the essence of the issues.

>Make it more symmetric to LOOKUP.
[...]

>SECINFO_P) into a single operation, couldn't we?

I suggest adding just one operation to NFSv4.1 that
takes care of SECINFO_P and SECINFO_CUR
functionaility. Say, SECINFO_NO_NAME, with single
argument:

		typedef enum {
			current_fh = 0,
			parent = 1
		} secinfo_nn4_t;

Easy to decode, and doesn't add redundant functionality.
SECINFO_NO_NAME would be in addition to SECINFO. 

If this is considered pressing enough, we could even make it
the single addition to NFSv4.1. 

	-mre