Re: FUSE merging? (2)

[Miklos Szeredi <miklos@szeredi.hu>]

> "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 see your point.  But then this is really not a security issue, but
an "are you sure you want to format C:" style protection for the
user's own sake.  Adding a mount option (checked by the library) for
this would be fine.  E.g. with "mount_nonempty" it would not refuse to
mount on a non-leaf dir, and README would document, that using this
option might cause trouble.  Otherwise the mount would be refused with
a reference to the above option.

Is that what you were thinking?

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

Private namespaces in their current form are not really useful.  But
that's irrelevant to the current discussion.  If somebody needs
private namespaces they will have to add the missing features (Ram Pai
is working on shared subtrees, the biggest chunk).

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

The backup problem is a consequence of 1).  It has absolutely zero to
do with 2).  If the fuse_allow_task() security check didn't exist the
backup script would still not work.

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

Wrong.  It's still needed, because suid/sgid programs can

  - run under the private namespace without doing anything special

  - run with extra privileges, not possesed by the user executing the
    program

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

I don't think you could change the rules of namespace inheritence,
without causing trouble.

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/