From: Jan Hudec <bulb@ucw.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
Ram <linuxram@us.ibm.com>, Jamie Lokier <jamie@shareable.org>,
Eric Van Hensbergen <ericvh@gmail.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: Mount bind filehandle (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call)
Date: Thu, 21 Apr 2005 11:32:49 +0200 [thread overview]
Message-ID: <20050421093249.GA6197@vagabond> (raw)
In-Reply-To: <20050421080901.GA17629@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]
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 <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-04-21 9:33 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-19 22:13 [RFC][2.6 patch] Allow creation of new namespaces during mount system call Eric Van Hensbergen
2005-04-19 22:23 ` Al Viro
2005-04-19 23:53 ` Eric Van Hensbergen
2005-04-20 3:33 ` Al Viro
2005-04-20 9:45 ` Jamie Lokier
2005-04-20 10:27 ` Al Viro
2005-04-20 12:03 ` Jamie Lokier
2005-04-20 12:39 ` Al Viro
2005-04-20 16:51 ` Ram
2005-04-20 17:09 ` Al Viro
2005-04-20 17:53 ` Miklos Szeredi
[not found] ` <a4e6962a0504201107518416e9@mail.gmail.com>
2005-04-20 18:18 ` Eric Van Hensbergen
2005-04-20 18:34 ` Miklos Szeredi
2005-04-20 20:43 ` Jamie Lokier
2005-04-20 20:54 ` Al Viro
2005-04-20 22:16 ` Jamie Lokier
2005-04-20 21:08 ` Al Viro
2005-04-20 22:19 ` Jamie Lokier
2005-04-20 18:00 ` Eric Van Hensbergen
2005-04-20 18:33 ` Ram
2005-04-20 22:04 ` Jamie Lokier
2005-04-30 8:56 ` Christoph Hellwig
2005-04-30 15:01 ` Jamie Lokier
2005-05-11 9:05 ` Christoph Hellwig
2005-04-21 7:33 ` Mount bind filehandle (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call) Jan Hudec
2005-04-21 8:09 ` Christoph Hellwig
2005-04-21 9:32 ` Jan Hudec [this message]
2005-04-20 18:57 ` [RFC][2.6 patch] Allow creation of new namespaces during mount system call Bryan Henderson
2005-04-20 19:37 ` Miklos Szeredi
2005-04-21 0:08 ` Bryan Henderson
2005-04-21 8:06 ` Miklos Szeredi
2005-04-21 13:33 ` [RFC][patch] mount permissions (was: [RFC][2.6 patch] Allow ...) Miklos Szeredi
2005-04-21 16:57 ` [RFC][2.6 patch] Allow creation of new namespaces during mount system call Bryan Henderson
2005-04-20 20:51 ` Al Viro
2005-04-21 0:23 ` Bryan Henderson
2005-04-21 0:32 ` Al Viro
2005-04-21 8:10 ` Christoph Hellwig
2005-04-20 21:09 ` Ram
2005-04-21 0:42 ` Bryan Henderson
2005-04-21 19:10 ` Ram
2005-04-20 18:25 ` Bryan Henderson
2005-04-20 12:48 ` Jan Hudec
2005-04-20 22:13 ` Jamie Lokier
2005-04-21 10:09 ` Jan Hudec
2005-04-21 18:44 ` Jamie Lokier
2005-04-21 18:52 ` Hiding secrets from root (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call) Jan Hudec
2005-04-21 20:35 ` Jamie Lokier
2005-04-20 13:14 ` [RFC][2.6 patch] Allow creation of new namespaces during mount system call Eric Van Hensbergen
2005-04-20 13:55 ` Eric Van Hensbergen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050421093249.GA6197@vagabond \
--to=bulb@ucw.cz \
--cc=ericvh@gmail.com \
--cc=hch@infradead.org \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).