Re: [PATCH 0/3] Various gssd fixes including machine-credential issue.

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3747 bytes --]

On Wed, 5 Jun 2013 11:37:12 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:

> Again, I ask: what is being protected?  Why would an administrator make this requirement?  I would like to clearly understand this particular attack so we can design a smart solution that does what administrators want.

I honestly have no idea.  But if there is nothing to be protected, why would
someone recommend (even if they don't require) integrity protection?

If I was setting up a server and was concerned about security I would be
choosing options that required signed messages where-ever possible, even if I
couldn't see the exact scenario by which a non-signed message could cause a
problem.

Certainly in an AUTH_SYS environment (trusted network transport), AUTH_SYS or
AUTH_NONE should be enough for SETCLIENTID.  But you want an AUTH_GSS
environment, why not aim to make everything use AUTH_GSS?

> 
> > For 3.6 (and earlier?) a client could work with this by running "kinit" as
> > both themselves and root, and running "gssd -n".  Then whenever they access
> > files, or whenever root accesses files on their behalf, the access uses their
> > credential and works.  The only access that tried to use the machine
> > credential (which doesn't exist) would be performed in the context of an
> > access by the user (an open) and would fall back on the user's credential.
> > 
> > In 3.[789] the mount doesn't work because it requires a SETCLIENTID which
> > tries to use the machine credential and has no user to fall back on.
> > It falls back on AUTH_NONE (is that right?) which the server doesn't accept.
> 
> The 3.7+ fallback logic works just like 3.6 and earlier.  The difference is that now the SETCLIENTID occurs as the first operation on the first mount.  At that early stage, there are no user credentials available because no-one has attempted to create any open or lock state, which is what is mined on the client for a user credential.
> 
> > In 3.10 the same happens but now it falls back on AUTH_SYS and the server
> > still doesn't accept it (because Dave said integrity protection is important).
> 
> No one has proposed a server change, so AUTH_SYS should be a reasonable choice.  Servers do not have to enforce the use of integrity-protecting security flavors for lease management unless the administrators recognize a palpable threat.  I'm trying to identify what kind of threats that might be, because so far we have been talking in hypotheticals.

If it is only hypothetical, why is it even recommended?  I must be missing
something.
If we expect the server will always accept AUTH_SYS, why ever bother sending
anything else?
If we expect the server might not accept AUTH_SYS, we should do our best to
send the appropriate authentication.



> > Your desire to make it "just work" without monkeying around with flags to gssd
> > is certainly good.  However there is a key difference between a multi-user
> > client and a single-user client.  For the multi-user client there must be a
> > separate "root" identity, whether in the form of a machine credential or a
> > credential for uid=0.  For the single-user client there is only one identity.
> > So somewhere that distinction needs to be configured.
> 
> I believe we will be fundamentally better off if we use the same mechanism in both cases.  The implementation is less complex and easier for us to test and maintain.  The promise of a broad "no configuration" solution also has its appeal.

Certainly agree it would be better.  Not convinced it is actually possible.
Not an important issue for me at the moment though.

I've provided a patched kernel to customer.  Hopefully will hear back soon.

Thanks
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]