Re: [PATCH] private mounts

[Trond Myklebust <trond.myklebust@fys.uio.no>]

to den 28.04.2005 Klokka 10:58 (-0700) skreiv Bryan Henderson:
> >This is why you have identity squashing and/or strong security: to stop
> >the CLIENT administrator impersonating whoever he wants and working
> >around your security measures.
> 
> That's more of a confirmation than a refutation of the statement that NFS 
> root squashing is broken.  Root squashing itself simply does not squash a 
> typical system administrator's ability to get at other people's files. 
> "broken" isn't the right word, because as long as you recognize root 
> squashing for what it is, it's working as designed.  It just isn't what it 
> appears to be.

Root squashing is there to enforce the policy that nobody gets to access
any files with uid=0,gid=0. IOW it is a policy that is first and
foremost meant to make root-owned files untouchable.

Strong security, OTOH, enforces the policy that you need to authenticate
as a given person in order to get at that person's files.

Neither can prevent man-in-the-middle style attacks by root on a client
that is compromised nor can they stop someone who has managed to lift
your username+password from somewhere. Every security policy has its
limitations.

> But, in the context of the current thread, I think the perception of NFS 
> root squashing as something broken and not to be built upon with private 
> mounts has to do with the fact that it messes up Linux's basic file 
> permission scheme:  a process with CAP_DAC_OVERRIDE can get EACCES. 
> EACCESS means discretionary access controls (DAC) prevent access.  So this 
> behavior is unexpected and unnatural.  Worse, an operation can succeed 
> _without_ CAP_DAC_OVERRIDE, but not _with_ it.  I've seen this behavior 
> cause trouble a number of times -- mostly because it's entirely 
> unanticipated.

Tough. Your administrator has set a certain policy on the fileserver,
and it is being correctly enforced. If that policy decision turns out to
be unnecessarily strict then you are quite free to plead with the
administrator to change it.

Note that these days CAP_DAC_OVERRIDE is no longer guaranteed to be
sufficient even for local disk if the administrator is using LSE to set
up custom policies.

Cheers,
  Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/