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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |