linux-kernel - Re: chroot(2) and bind mounts as non-root

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Dec 2011 05:29:46 +0000
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Colin Walters <walters@...bum.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, morgan@...nel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>, dhowells@...hat.com,
	kzak@...hat.com
Subject: Re: chroot(2) and bind mounts as non-root

Quoting Colin Walters (walters@...bum.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/