public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Colin Walters <walters@verbum.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	morgan@kernel.org, "Eric W. Biederman" <ebiederm@xmission.com>,
	dhowells@redhat.com, kzak@redhat.com
Subject: Re: chroot(2) and bind mounts as non-root
Date: Sat, 10 Dec 2011 05:29:46 +0000	[thread overview]
Message-ID: <20111210052945.GA14931@hallyn.com> (raw)
In-Reply-To: <1323280461.10724.13.camel@lenny>

Quoting Colin Walters (walters@verbum.org):
>       if (prctl (PR_SET_SECUREBITS,
>                  SECBIT_NOROOT | SECBIT_NOROOT_LOCKED) < 0)
>         fatal_errno ("prctl (SECBIT_NOROOT)");

Sorry, only just saw this now.  Haven't taken too close a look, but a
comment and a few warnings.

First, 	what you are after is an explicit goal of user namespaces:  to
be able to change the environment without risk of fooling privileged
setuid programs with that environment.  And, thereby, to allow unprivileged
users to clone namespaces and, in new namespaces, freely muck with the
resources they own or create.  However, they're not quite usable yet.

So regarding your use of securebits: You are preventing a setuid-root
program from automatically acquiring capabilities, which is a good
start.  However, a setuid-root program will still execute as root (or
a setuid-mysql program as setuid-mysql).  That means it will own
root (or mysql) files while it is running.  That could still be
plenty dangerous.  (With user namespaces, programs running as the
container root will not own files belonging to the host root as they
are different users.)  Second, programs with file capabilities -a
more finegrained alternative to setuid-root - will still run with
privilege.  You could prevent that by not allowing xattrs I suppose.

-serge

  parent reply	other threads:[~2011-12-10  5:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-07 17:54 chroot(2) and bind mounts as non-root Colin Walters
2011-12-07 19:36 ` John Stoffel
2011-12-08 16:10   ` Colin Walters
2011-12-08 18:14     ` John Stoffel
2011-12-08 18:26       ` Colin Walters
2011-12-09  0:49         ` Sven-Haegar Koch
2011-12-09 14:55         ` John Stoffel
2011-12-09 15:06           ` Colin Walters
2011-12-08 17:04   ` Arnd Bergmann
2011-12-08 17:15     ` Colin Walters
2011-12-07 19:40 ` Andy Lutomirski
2011-12-08 16:58   ` Colin Walters
2011-12-07 20:34 ` H. Peter Anvin
2011-12-07 20:54   ` Alan Cox
2011-12-15 18:55     ` Andrew G. Morgan
2011-12-16 15:44       ` Colin Walters
2011-12-18  1:22         ` Andrew G. Morgan
2011-12-18 15:19           ` Colin Walters
2011-12-10  5:29 ` Serge E. Hallyn [this message]
2011-12-12 16:41   ` Colin Walters
2011-12-12 23:11     ` Serge E. Hallyn
2011-12-15 20:56       ` Colin Walters
2011-12-16  6:14         ` Eric W. Biederman
2011-12-18 16:01           ` Colin Walters
2011-12-19  0:55             ` Eric W. Biederman
2011-12-19  4:06               ` Serge E. Hallyn
2011-12-19  9:22                 ` Eric W. Biederman
2011-12-20 16:49                   ` Colin Walters
2011-12-20 21:23               ` Colin Walters
2011-12-21 18:15           ` Steve Grubb
2012-01-03 23:13             ` Eric W. Biederman

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=20111210052945.GA14931@hallyn.com \
    --to=serge@hallyn.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=kzak@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=walters@verbum.org \
    /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