lkml.org 
[lkml]   [2005]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: FUSE merging? (2)
    From
    Date
    > "solving it properly" refers to hardening the leaf node constraint
    > against circumvention I assume. Suppose there's a script for doing simple
    > on-line backups using "find". Now explain to the user why he lost his
    > data due to a backup script geting EACCES on a non-leaf FUSE mount.

    I see your point. But then this is really not a security issue, but
    an "are you sure you want to format C:" style protection for the
    user's own sake. Adding a mount option (checked by the library) for
    this would be fine. E.g. with "mount_nonempty" it would not refuse to
    mount on a non-leaf dir, and README would document, that using this
    option might cause trouble. Otherwise the mount would be refused with
    a reference to the above option.

    Is that what you were thinking?

    > > There's a nice solution to this (discussed at length earlier): private
    > > namespaces.
    >
    > I thought that's rejected because a process doesn't automatically get the
    > right namespace after rsh into such a machine? And fixing it by adjusting
    > the name-space of a process (by whatever means) is not transparent.

    Private namespaces in their current form are not really useful. But
    that's irrelevant to the current discussion. If somebody needs
    private namespaces they will have to add the missing features (Ram Pai
    is working on shared subtrees, the biggest chunk).

    > > I think we are still confusing these two issues, which are in fact
    > > separate.
    > >
    > > 1) polluting global namespace is bad (find -xdev issue)
    > >
    > > 2) not ptraceable (or not killable) processes should not be able to
    > > access an unprivileged mount
    > >
    > > For 1) private namespaces are the proper solution. For 2) the
    > > fuse_allow_task() in it's current or modified form (to check
    > > killability) should be OK.
    > >
    > > 1) is completely orthogonal to FUSE. 2) is currently provably secure,
    > > and doesn't seem cause problems in practice. Do you have a concrete
    > > example, where it would cause problems?
    >
    > See above backup scenario.

    The backup problem is a consequence of 1). It has absolutely zero to
    do with 2). If the fuse_allow_task() security check didn't exist the
    backup script would still not work.

    > Issues (1) and (2) are tied together I'm afraid:
    >
    > When using a private name-space and thus assuming an unrelated process
    > needs to do something very special to get that name-space then (2)
    > would not be needed at all.

    Wrong. It's still needed, because suid/sgid programs can

    - run under the private namespace without doing anything special

    - run with extra privileges, not possesed by the user executing the
    program

    > On the other hand, Name-space inheritance by setuid processes suddenly
    > becomes an issue: issue (2) is re-appearing but at another place.

    I don't think you could change the rules of namespace inheritence,
    without causing trouble.

    Miklos
    -
    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-07-04 12:35    [W:4.231 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site