From: daw@cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges
Date: Sat, 2 Jan 2010 06:23:24 +0000 (UTC) [thread overview]
Message-ID: <hhmoos$vnu$1@taverner.cs.berkeley.edu> (raw)
In-Reply-To: 20100101144629.54fe6cb6@lxorguk.ukuu.org.uk
Alan Cox wrote:
>daw@cs.berkeley.edu (David Wagner) wrote:
>> You lost me there. The ability of a specific piece of code to voluntarily
>> relinquish privileges can be a big benefit to security.
>
>Can be - but its historically been an endless source of bugs and flaws
>because the code being run after you take the rights away is being run in
>an environment it didn't expect and wasn't tested in.
Are you just *shrugging* at the goals underlying these efforts?
The goals of enabling privilege separation and sandboxing seem like
highly laudable goals to me. I don't understand why anyone would
be opposed to efforts to achieve those goals.
Privilege-separation is a powerful software architecture technique.
It's been used in openssh, qmail, vsftpd, and other highly regarded
security-critical applications. (When a software designer uses privilege
separation, he *intends* for his code to be run in a low-privilege
environment. That's not a source of bugs.)
Sandboxing is a powerful security tool. It's been used for many
purposes. (When we invent a sandboxing tool, the whole purpose is
to run the sandboxed code to run in a low-privilege environment.)
There is indeed one undesired source of bugs sometimes introduced by
privilege-separation and sandboxing tools, and that is an increased
potential for attacks against setuid programs by local users. But calling
this "an endless source of bugs and flaws" seems over the top to me.
How many examples have there been? I can think of one of any significance
(sendmail). In any case, I would classify these flaws as inherently
relatively low-severity, because they can only be exploited by local
users.
I'm far more concerned about attacks by remote attackers. I don't
let untrusted people have accounts on my system. So I really am not
that concerned about ways that a local user might try to attack
setuid root programs. But I am quite concerned about remote exploits.
And privilege separation and sandboxing are two of the best techniques
we have available to defend against remote exploits.
To do that, application developers need better mechanisms to enable
them to voluntarily and irrevocably relinquish privilege. That seems
like a worthwhile goal, and something that ought to be attainable without
introducing much risk of opening up new ways of attacking setuid programs.
(Indeed, there have been a number of proposals for how to achieve that
here on linux-kernel in the past few days.) So why are you pushing back
against that goal? Why are you so critical even of reasonable attempts
to provide a way to achieve the benefits without enabling those kinds
of attacks on setuid programs? What am I missing?
Perhaps I'm reading you wrong, but I seem to sense an attitude where you
consider privilege separation and sandboxing to be relatively unimportant,
and where you consider the risk of local attacks on setuid programs to
be unavoidable and of paramount importance. I'm surprised to get this
impression, because that seems narrow and counter-productive to me.
next prev parent reply other threads:[~2010-01-02 6:23 UTC|newest]
Thread overview: 179+ 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-12 18:30 ` [PATCH 2/3] Security: Implement disablenetwork semantics. (v4) David Wagner
2010-01-13 20:23 ` Pavel Machek
2010-01-11 1:46 ` 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-11 1:29 ` David Wagner
2010-01-11 13:39 ` Simon Horman
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-14 14:30 ` David Wagner
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-11 1:41 ` David Wagner
2010-01-10 22:58 ` James Morris
2010-01-11 1:21 ` David Wagner
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 22:10 ` David Wagner
2009-12-28 23:54 ` Valdis.Kletnieks
2009-12-29 0:42 ` David Wagner
2009-12-29 1:39 ` Valdis.Kletnieks
2010-01-01 15:55 ` Pavel Machek
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
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 ` David Wagner
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
2009-12-31 17:55 ` David Wagner
2010-01-01 14:46 ` Alan Cox
2010-01-02 6:23 ` David Wagner [this message]
2010-01-02 13:55 ` Alan Cox
2010-01-04 0:55 ` David Wagner
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
2009-12-30 7:24 ` David Wagner
2009-12-30 16:26 ` Valdis.Kletnieks
2010-01-01 11:41 ` Eric W. Biederman
2010-01-02 6:28 ` David Wagner
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='hhmoos$vnu$1@taverner.cs.berkeley.edu' \
--to=daw@cs.berkeley.edu \
--cc=daw-news@taverner.cs.berkeley.edu \
--cc=linux-kernel@vger.kernel.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