Re: FUSE merging? (2)

[Frank van Maarseveen <frankvm@frankvm.com>]

On Mon, Jul 04, 2005 at 10:56:30AM +0200, Miklos Szeredi wrote:
> > It is important because on UNIX, "root" rules on local filesystems.
> > I dont't like the idea of root not being able to run "find -xdev"
> > anymore for administrative tasks, just because something got hidden
> > by accident or just for fun by a user.  It's not about malicious
> > users who want to hide data: they can do that in tons of ways.
> 
> That's a sort of security by obscurity: if the user is dumb enough he
> cannot do any harm.  But I'm not interested in that sort of thing.  If
> this issue important, then it should be solved properly, and not just
> by "preventing accidents".

"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
don't think that's acceptable. On the other hand, when the user stored
something _deliberately_ under a mountpoint, circumventing the leaf node
constraint by some trickery then it is clearly his own fault when the data
is lost. Anyway, a leaf node constraint can be hardened against misuse
later on, should it become necessary. Your bind-mount case to circumvent
this restriction is slightly flawed because it requires root interaction.

> 
> 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.

> 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.

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.

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

-- 
Frank