Re: FUSE merging? (2)

Frank van Maarseveen
2005-07-04T10:11:25Z

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