From: "Serge E. Hallyn" <serue@us.ibm.com>
To: "Andrew G. Morgan" <morgan@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
"Bryan Donlan" <bdonlan@gmail.com>,
"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
"Benny Amorsen" <benny+usenet@amorsen.dk>,
"Michael Stone" <michael@laptop.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-security-module@vger.kernel.org,
"Andi Kleen" <andi@firstfloor.org>, "David Lang" <david@lang.hm>,
"Oliver Hartkopp" <socketcan@hartkopp.net>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>,
"Evgeniy Polyakov" <zbr@ioremap.net>,
"C. Scott Ananian" <cscott@cscott.net>,
"James Morris" <jmorris@namei.org>,
"Bernie Innocenti" <bernie@codewiz.org>,
"Mark Seaborn" <mrs@mythic-beasts.com>,
"Randy Dunlap" <randy.dunlap@oracle.com>,
"Américo Wang" <xiyou.wangcong@gmail.com>,
"Tetsuo Handa" <penguin-kernel@i-love.sakura.ne.jp>,
"Samir Bellabes" <sam@synack.fr>,
"Casey Schaufler" <casey@schaufl>
Subject: Re: [RFC][PATCH v2] Unprivileged: Disable raising of privileges
Date: Wed, 30 Dec 2009 12:35:13 -0600 [thread overview]
Message-ID: <20091230183513.GC14493@us.ibm.com> (raw)
In-Reply-To: <551280e50912300652r1007dee0j8de750bf33af9b3c@mail.gmail.com>
Quoting Andrew G. Morgan (morgan@kernel.org):
> Eric,
>
> I'm not clear why capabilities need to be manipulated by this feature
> (the pure capability support already has a feature for disabling
> privilege and blocking unsafe, or insufficient privilege, execution).
Not entirely - this option would also prevent file capabilities from
being honored.
> Perhaps I'm just unclear what features can be more safely enabled with
> this in effect - that is, your description suggests that this is why
> you are doing this, but leaves it unclear what they are. Could you
> take a few moments to enumerate some of them?
There are two desirable features which are at the moment unsafe for
unprivileged users, because it allows them to fool privileged (setuid
or bearing file capabilities) programs. One is to unconditionally
restrict privilege to yourself and all your descendents. The recent
disablenetwork patchset is one example. The other is the ability to
make substantial changes to your environment in a private namespace.
A private namespace can protect already-running privileged program,
but cannot protect privilege-bearing binaries. Unless we prevent
them from bearing privilege. Which is what this patch does.
-serge
next prev parent reply other threads:[~2009-12-30 18:35 UTC|newest]
Thread overview: 157+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-27 1:04 RFC: disablenetwork facility. (v4) Michael Stone
2009-12-27 1:06 ` [PATCH 1/3] Security: Add disablenetwork interface. (v4) Michael Stone
2009-12-27 3:26 ` Serge E. Hallyn
2009-12-28 18:13 ` Serge E. Hallyn
2009-12-29 1:21 ` Michael Stone
2009-12-29 5:26 ` Serge E. Hallyn
2009-12-27 7:53 ` Pavel Machek
2009-12-29 1:25 ` Michael Stone
2009-12-30 10:09 ` Pavel Machek
2009-12-30 18:47 ` Serge E. Hallyn
2009-12-27 1:06 ` [PATCH 2/3] Security: Implement disablenetwork semantics. (v4) Michael Stone
2009-12-27 1:20 ` Tetsuo Handa
2009-12-30 18:50 ` Serge E. Hallyn
2010-01-01 14:31 ` Pavel Machek
2010-01-10 21:11 ` James Morris
2010-01-10 21:16 ` Pavel Machek
2010-01-10 21:44 ` James Morris
2010-01-10 21:54 ` Michael Stone
2010-01-10 21:58 ` Pavel Machek
2010-01-10 22:40 ` Michael Stone
2010-01-11 1:07 ` Tetsuo Handa
2010-01-11 1:45 ` Michael Stone
2010-01-11 17:49 ` Serge E. Hallyn
2010-01-12 6:10 ` Michael Stone
2010-01-12 15:52 ` Serge E. Hallyn
2010-01-14 9:23 ` Pavel Machek
2010-01-14 15:00 ` Serge E. Hallyn
2010-01-14 16:36 ` Michael Stone
2010-01-14 16:47 ` Serge E. Hallyn
[not found] ` <20100114171309.GA6372@heat>
2010-01-14 17:36 ` Serge E. Hallyn
2010-01-15 8:10 ` disablenetwork (v5) patches Michael Stone
2010-01-15 8:12 ` disablenetwork (v5): Remove a TOCTTOU race by passing flags by value Michael Stone
2010-01-15 8:12 ` disablenetwork (v5): Simplify the disablenetwork sendmsg hook Michael Stone
2010-01-15 8:13 ` disablenetwork (v5): Require CAP_SETPCAP to enable disablenetwork Michael Stone
2010-01-17 2:58 ` Andrew G. Morgan
[not found] ` <20100117044825.GA2712@heat>
2010-01-17 4:58 ` disablenetwork (v5): Require CAP_SETPCAP to enable Andrew G. Morgan
2010-01-18 19:30 ` Serge E. Hallyn
2010-01-15 8:13 ` disablenetwork (v5): Update documentation for PR_NETWORK_ENABLE_DN Michael Stone
2010-01-17 6:01 ` disablenetwork (v5) patches Kyle Moffett
[not found] ` <20100117180728.GA2848@heat>
2010-01-17 21:17 ` Kyle Moffett
2010-01-11 1:46 ` [PATCH 2/3] Security: Implement disablenetwork semantics. (v4) Casey Schaufler
2010-01-12 3:19 ` Valdis.Kletnieks
2010-01-12 4:01 ` Casey Schaufler
2010-01-11 12:01 ` Pavel Machek
2010-01-12 2:54 ` Valdis.Kletnieks
2010-01-12 7:59 ` Pavel Machek
2010-01-12 14:28 ` Valdis.Kletnieks
2010-01-14 9:22 ` Pavel Machek
2010-01-18 12:54 ` Valdis.Kletnieks
2010-01-18 15:56 ` Andrew G. Morgan
2010-01-10 22:18 ` Kyle Moffett
2010-01-10 23:08 ` Michael Stone
2010-01-10 23:41 ` Bryan Donlan
2010-01-11 1:50 ` Casey Schaufler
2010-01-11 2:15 ` Bryan Donlan
2010-01-11 11:53 ` Pavel Machek
2010-01-10 22:58 ` James Morris
2009-12-27 1:07 ` [PATCH 3/3] Security: Document disablenetwork. (v4) Michael Stone
2009-12-27 1:39 ` Tetsuo Handa
2009-12-27 16:25 ` Michael Stone
2009-12-27 8:36 ` RFC: disablenetwork facility. (v4) Tetsuo Handa
2009-12-27 8:38 ` Pavel Machek
2009-12-27 11:49 ` Tetsuo Handa
2009-12-27 12:18 ` Al Viro
2009-12-27 15:03 ` Serge E. Hallyn
2009-12-27 15:47 ` Michael Stone
2009-12-27 16:12 ` Serge E. Hallyn
2009-12-27 16:36 ` Michael Stone
2009-12-27 18:06 ` Pavel Machek
2009-12-27 19:08 ` Pavel Machek
2009-12-28 6:07 ` Michael Stone
2009-12-28 10:10 ` Pavel Machek
2009-12-28 14:37 ` Valdis.Kletnieks
2009-12-28 20:55 ` Pavel Machek
2009-12-28 21:28 ` Valdis.Kletnieks
2009-12-28 21:33 ` Bryan Donlan
2009-12-29 6:08 ` Serge E. Hallyn
2010-01-01 15:06 ` Pavel Machek
2009-12-28 16:31 ` Michael Stone
2009-12-28 21:08 ` Pavel Machek
2009-12-28 21:24 ` Valdis.Kletnieks
2009-12-28 18:13 ` Serge E. Hallyn
2009-12-29 5:01 ` Michael Stone
2009-12-29 5:56 ` Serge E. Hallyn
2009-12-29 16:31 ` Michael Stone
2009-12-29 11:06 ` Eric W. Biederman
2009-12-29 15:11 ` Serge E. Hallyn
2009-12-29 16:05 ` Bryan Donlan
2009-12-29 16:39 ` Serge E. Hallyn
2009-12-29 17:01 ` Bryan Donlan
2009-12-29 18:36 ` Eric W. Biederman
2009-12-29 19:08 ` Bryan Donlan
2009-12-29 20:56 ` Eric W. Biederman
2009-12-29 21:27 ` Serge E. Hallyn
2009-12-29 21:46 ` Valdis.Kletnieks
2009-12-29 22:16 ` Serge E. Hallyn
2009-12-29 20:10 ` Benny Amorsen
2009-12-29 20:40 ` Eric W. Biederman
2009-12-29 20:43 ` Bryan Donlan
2009-12-29 21:11 ` Alan Cox
2009-12-29 21:14 ` Bryan Donlan
2009-12-29 21:35 ` Alan Cox
2009-12-29 21:29 ` Eric W. Biederman
2009-12-29 22:36 ` Serge E. Hallyn
2009-12-30 3:26 ` Eric W. Biederman
2009-12-30 3:50 ` Serge E. Hallyn
2009-12-30 4:29 ` Eric W. Biederman
2009-12-30 18:00 ` Serge E. Hallyn
2009-12-30 21:12 ` Eric W. Biederman
2009-12-30 3:35 ` [RFC][PATCH] Unprivileged: Disable acquisition of privileges Eric W. Biederman
2009-12-30 3:54 ` Bryan Donlan
2009-12-30 4:33 ` Eric W. Biederman
2009-12-30 4:57 ` Bryan Donlan
2009-12-30 12:47 ` Eric W. Biederman
2009-12-30 12:49 ` [RFC][PATCH v2] Unprivileged: Disable raising " Eric W. Biederman
2009-12-30 14:52 ` Andrew G. Morgan
2009-12-30 18:35 ` Serge E. Hallyn [this message]
2009-12-30 20:07 ` Eric W. Biederman
2009-12-30 20:17 ` Serge E. Hallyn
2009-12-30 21:15 ` [RFC][PATCH v3] " Eric W. Biederman
2009-12-30 21:29 ` Alan Cox
2009-12-30 21:36 ` Eric W. Biederman
2009-12-30 23:00 ` Alan Cox
2009-12-31 2:44 ` Bryan Donlan
2009-12-31 17:33 ` Alan Cox
2009-12-31 17:52 ` Serge E. Hallyn
2009-12-31 18:20 ` Andrew G. Morgan
2009-12-31 18:32 ` Eric W. Biederman
2010-01-01 14:43 ` Alan Cox
2010-01-01 14:53 ` Pavel Machek
2010-01-01 16:26 ` Eric W. Biederman
2010-01-01 21:35 ` Casey Schaufler
2010-01-01 22:39 ` Alan Cox
2010-01-01 23:18 ` Casey Schaufler
2010-01-02 0:42 ` Peter Dolding
[not found] ` <4B3FB0FC.3030809@schaufler-ca.com>
2010-01-03 1:43 ` Peter Dolding
2009-12-31 18:41 ` Eric W. Biederman
2009-12-31 21:46 ` Serge E. Hallyn
2010-01-01 21:17 ` Andrew G. Morgan
2010-01-01 14:57 ` Alan Cox
2009-12-31 8:57 ` Eric W. Biederman
2009-12-31 13:00 ` Samir Bellabes
2009-12-31 14:08 ` Peter Dolding
2009-12-31 17:06 ` Alan Cox
2010-01-01 0:12 ` Peter Dolding
2010-01-01 10:28 ` Pavel Machek
2009-12-31 15:25 ` Serge E. Hallyn
2009-12-31 16:48 ` Eric W. Biederman
2009-12-30 18:29 ` [RFC][PATCH v2] " Serge E. Hallyn
2009-12-30 20:45 ` Eric W. Biederman
2009-12-29 18:03 ` RFC: disablenetwork facility. (v4) Eric W. Biederman
2009-12-29 16:06 ` Michael Stone
2010-01-01 15:11 ` Pavel Machek
2009-12-27 8:51 ` Al Viro
2009-12-27 11:23 ` Valdis.Kletnieks
2009-12-27 12:45 ` Andi Kleen
2009-12-27 15:55 ` Michael Stone
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=20091230183513.GC14493@us.ibm.com \
--to=serue@us.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=bdonlan@gmail.com \
--cc=benny+usenet@amorsen.dk \
--cc=bernie@codewiz.org \
--cc=casey@schaufl \
--cc=cscott@cscott.net \
--cc=david@lang.hm \
--cc=ebiederm@xmission.com \
--cc=herbert@gondor.apana.org.au \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=michael@laptop.org \
--cc=morgan@kernel.org \
--cc=mrs@mythic-beasts.com \
--cc=netdev@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=randy.dunlap@oracle.com \
--cc=sam@synack.fr \
--cc=socketcan@hartkopp.net \
--cc=xiyou.wangcong@gmail.com \
--cc=zbr@ioremap.net \
/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).