lkml.org 
[lkml]   [2005]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] private mounts
    From
    Date
    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/

    \
     
     \ /
      Last update: 2005-04-28 21:49    [W:4.383 / U:3.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site