Messages in this thread | | | Subject | Re: [PATCH] private mounts | From | Miklos Szeredi <> | Date | Tue, 26 Apr 2005 16:14:07 +0200 |
| |
> 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.
Umm, yes. Here's one I prepared earlier:
http://marc.theaimsgroup.com/?l=linux-fsdevel&m=107701207710525&w=2
I stopped maintaining it, because as you can see getting something accepted to mainline is not as easy as it first sounds :)
> (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?
Good question. I'm undecided on the suid/nosuid mount issue. It sure would be nicer not to need a mount helper...
> 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).
Note: I'm mostly concerned with system security not user security. Protecting user data from root is a treacherous thing to attempt.
> 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
It's not that obscure. Scp, sftp each will be a separate session, and you can't set up mounts within an scp.
> 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.
Why would you have to revalidate? A simple bind mount would suffice. However, joining another sessions namespace makes more sense, than copying the mounts individually.
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/
| |