Re: [PATCH] private mounts

[Miklos Szeredi]

> > Is it possible to limit all these from kernelspace?  Probably yes,
> > although a timeout for operations is something that cuts either way.
> > And the compexity of these checks would probably be orders of
> > magnitude higher then the check we are currently discussing.
> 
> Yes ... but does the check we are discussing really solve the
> problem?
> 
> Let's say that you attempt to export home directories of users by a
> user-space NFS daemon. This daemon probably changes its fsuid to
> match the remote user, so the check happily accepts the access and
> the user is able to lock up the daemon.

Valid point.  The only defense is that when a program set's fsuid,
it's performing the operation "on behalf of the user".  So the user is
actually doing DoS against himself.

Of course this is not strictly true.  E.g. in the userspace NFS case
it's probably a DoS against all users of the mount.

> It doesn't seem that there is any simple and universal cure -- root
> programs or setuid programs altering their fsuid are just too
> similar to the real user programs to separate them cleanly.

Root programs setting fsuid are relatively rare, most are suid
programs originally started from the user (nfsd is an exception).

So yes the check fsuid is not the perfect solution.  However let me
remind you that neither is the one with private namespace.

> I see a lot of similarities with symlinks -- many programs also need
> to take extra care of symlinks to be safe. However, symlinks are
> already senior citizens of Unix systems and programs know how to
> cope with them since ages.
> 
> Maybe this could be taken advantage of by keeping all user mounts in
> a separate directory like /mnt/usr (and /mnt is very likely to be
> avoided by all programs traversing directory structure
> automatically) and symlinking from the requested mount points there
> (with symlinks naturally not followed by automatic traversals).

Maybe.  It would be trivial to add a config option to fuse.conf to
limit user mounts to some directory.

Thanks,
Miklos



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