Re: [PATCH] private mounts

From: Eric Van Hensbergen (ericvh_at_gmail.com)
Date: 04/26/05

  • Next message: Alan Cox: "Re: IRQ Disabling"
    Date:	Tue, 26 Apr 2005 08:05:30 -0500
    To: Christoph Hellwig <hch@infradead.org>, Andrew Morton <akpm@osdl.org>, miklos@szeredi.hu, jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
    
    

    On 4/26/05, Christoph Hellwig <hch@infradead.org> wrote:
    > On Tue, Apr 26, 2005 at 03:14:14AM -0700, Andrew Morton wrote:
    > > That's one of the major points of FUSE, isn't it? So that unprivileged
    > > users can do interesting things.
    > >
    > > Or are you saying that that's a desirable objective, but it should be
    > > implemented differently?
    >
    > It's a desirable objective, but the implementation is wrong. If we have
    > a user mount that must be known to the VFS so that the VFS can enforce
    > the right restrictions instead of leaving various crude hacks in lowlevel
    > filesystem drivers. Especially as fuse isn't the only filesystem for which
    > this makes sense - smbfs or v9fs want the same features aswell
    >

    As far as I can see, there are (at least) two distinct discussions
    going on. For the sake of clarity I'd like to get the security
    concerns/requirements laid out for each:

    TYPE A) general purpose user-mountable file systems

    This seems to be the feature that would be useful to many of the
    different file systems
    (fuse, v9fs, smbfs, etc). What security restrictions need to be in
    place if we were to take the SYS_CAP_ADMIN check out of sys_mount?
    From what I've gleaned from the discussion so far they would include:
    1) Restricting where the user could mount
    - the suggestion so far is that a user could only mount/bind to a
    directory he could write to and without the sticky bit
    2) Restricting what the user could mount
    - mounting arbitrary file systems could expose a vulnerability
    3) Restricting how the user can mount (nosuid, nogid enforced)
    4) Restricting user mount visibility (in private namespaces) so as not
    to pollute the global namespace
    5) Restricting how much the user can mount (restricting number of
    mounts and/or number of namespaces with a ulimit)

    (1), (3), (4), and (5) seem straightforward to me. (2) seems a little
    less-so. I understand a little bit of the vulnerability (specifically
    when mounting physical devices with file systems that may or may not
    be tolerant to malicious formats), but I hate restricting the user. I
    guess perhaps we could have something in the file system type
    information which describes whether or not it should be user
    mountable.

    Implementation wise, (3), (4), and (5) seem pretty straightforward to
    implement in the kernel. (1) and (2) wouldn't be that bad if the
    policy were kept simple, but any sort of an advanced policy would seem
    to require a user-space application to assist -- but that seems to
    require an suid mount app. Is it better to come up with a simple
    universal policy and implement it within VFS, or allow for a more
    complex policy that would require user-space application assistance?

    Have I missed something from the security angle?

    TYPE B) per-user namespace / attachable namespace / etc.

    This argument seems to come mostly from the FUSE camp, but the goal
    seems noble enough: given enforcement of requiring private namespaces
    for user mounts in (A), how can we create a user-environment similar
    to what the user would expect without private mounts (ie. a global
    namespace per user).

    The main security concern here has been stated in detail before, so
    I'll only summarize: only the user who mounted the file system should
    be granted access to it. Private namespaces in (A) seem to grant that
    security, however, the (B) requirement of a global user namespace
    invalidates that as a new login (or su) woud attatch to the private
    namespace (and if I'm not mistaken a root su'ing to the user would
    also get around the currently implemented permission scheme). I don't
    think anyone has come up with a good solution here.

    My hack at a solution for this (even though I don't see this as a big
    requirement):
    Proper namespace inheritance (meaning changes to the parent are
    propagated to the child as references not copies -- I believe the
    shared subtree RFC covers the right semantics) along with establishing
    a new private namespace for each login session. As far as accessing
    already mounted FUSE file systems between different login sessions --
    I see this as a really obscure requirement that complicates things a
    great deal, however -- if you split the concept of "srv points" from
    file system mounts and remount the file system (perhaps automatically
    as part of initiating the session) for every new login -- then you can
    revalidate security at each of these mounts. This sounds somewhat
    extreme, but with a proper keyring style authentication management
    system it could be made fairly transparent to the user. I believe
    others in this thread have proposed something similar, I'm just
    weighing in that if this must be a requirement (and I don't think it
    should), this is how I think it should be done.

    In general (TYPE A) and (TYPE B) are related but separate
    implementation efforts, I think we should focus on getting (TYPE A)
    right (due to the system security implications) and evolve a solution
    to (TYPE B) based on use.

             -eric
    -
    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/


  • Next message: Alan Cox: "Re: IRQ Disabling"