On Thu, Apr 21, 2005 at 09:09:01 +0100, Christoph Hellwig wrote: > On Thu, Apr 21, 2005 at 09:33:20AM +0200, Jan Hudec wrote: > > I think I can. And I think I can modify the proposal to something a bit > > more sane. > > > > The problem is: The mount should be accessible only by processes started > > by the authorized user, but not by other user, including root, who is > > capable of changing their uid to the authorized user's id. > > > > The solution can be: The mount is only accessible to the process group > > of that user's session. That's easy -- the login process is created > > with new namespace. > > That doesn't make sense. A process with sufficient capabilities (aka root) > can do things including reading or modifying kernel memory and can > access your namespace always, no matter how difficult you're trying to make > it.
Yes, I know. Actually, in the mail you cite, there was also writte:
> > Note however, that it's really hard to protect something against root,
> > because root can ptrace any process.
So determined attacker with root access will break in (actually,
determined attacker with root access can read your ssh keys from your
running ssh session too -- te fact you fuse-mount it does not increase
his chances).
However, there are other reasons mentioned in this thread, why private
namespaces are useful. They can't be corrupted by misconfigured stuff,
don't confuse other (broken) stuff and such. And after all while the
proposal is inspired by this issue, it just means a generic extension to
bind mounts that could be useful for other applications. Sometimes
a program, for reliability or security reasons, need to work with
directory handles -- and this is a way to reliably assign them a path
instead of finding out the current one, which can change under their
hands.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[EMAIL
PROTECTED]>
signature.asc
Description: Digital signature
