From: Christoph Lameter <cl@linux.com>
To: "Andrew G. Morgan" <morgan@kernel.org>
Cc: Andrew Lutomirski <luto@kernel.org>,
Kees Cook <keescook@chromium.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
Andy Lutomirski <luto@amacapital.net>,
Jonathan Corbet <corbet@lwn.net>,
Aaron Jones <aaronmdjones@gmail.com>, "Ted Ts'o" <tytso@mit.edu>,
linux-security-module <linux-security-module@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Andrew Morton <akpm@linuxfoundation.org>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Austin S Hemmelgarn <ahferroin7@gmail.com>,
Markku Savela <msa@moth.iki.fi>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [RFC] capabilities: Ambient capabilities
Date: Fri, 13 Mar 2015 11:06:36 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.11.1503131049150.13899@gentwo.org> (raw)
In-Reply-To: <CALQRfL6HUGMfPtsqLcSed8G14Yqg27R8tpDnMZOKtvQE+rqX0A@mail.gmail.com>
On Fri, 13 Mar 2015, Andrew G. Morgan wrote:
> > prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, CAP_SYS_ADMIN);
> > system("/bin/bash");
>
> Let's call the above two lines [a] and [b]. With this patch, you are
> encouraging folk to write programs that contain a line like [a]
> already. So, yes, I am saying that you are creating an exploitable
> path in these programs that says if someone can inject
> system("/bin/bash") into these programs they can get a new (because of
> this patch) privilege escalation.
Well this is what one naively expects capabilities to give you. An ability
to avoid full superuser binaries by segmenting off capabilities. Often
there is really no other choice. If you do not provide this mode then
the system will be even less secure since people run stuff as root.
This looks to many like the design of capabilties is inherent flawed since
it does not give you what you need. You experience a go around that leads
nowhere and just wastes your time.
> In the prevailing model, this kind of privilege escalation (resulting
> from naive inheritance) is designed out. I recognize that you want to
> add it back in, but I am concerned that you are not allowing for the
> possibility that some folk might still want to still be able to
> prevent it.
The functionalty here depends on CAP_SETPCAP. That was intended as some
point to be off by default? You can have distros/kernels with that being
off.
next prev parent reply other threads:[~2015-03-13 16:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-12 18:08 Andy Lutomirski
2015-03-12 21:49 ` Kees Cook
2015-03-12 22:10 ` Andrew G. Morgan
2015-03-12 22:27 ` Andrew Lutomirski
2015-03-13 13:24 ` Andrew G. Morgan
2015-03-13 16:06 ` Christoph Lameter [this message]
2015-03-13 17:58 ` Andy Lutomirski
2015-03-13 18:52 ` Christoph Lameter
2015-03-13 17:57 ` Andy Lutomirski
2015-03-13 18:52 ` Kees Cook
2015-03-13 19:03 ` Andy Lutomirski
2015-03-13 19:54 ` Kees Cook
2015-03-14 21:09 ` Andrew G. Morgan
2015-03-14 21:45 ` Andy Lutomirski
2015-03-14 22:17 ` Andrew G. Morgan
2015-03-14 22:53 ` Andy Lutomirski
2015-03-14 22:55 ` Andy Lutomirski
2015-03-15 0:04 ` Andrew G. Morgan
2015-03-30 12:55 ` Christoph Lameter
2015-03-30 14:31 ` Andy Lutomirski
2015-03-30 15:05 ` Christoph Lameter
2015-04-09 15:25 ` Christoph Lameter
2015-04-23 14:01 ` Christoph Lameter
2015-04-24 17:53 ` Serge Hallyn
2015-04-24 18:41 ` Andy Lutomirski
2015-04-24 19:09 ` Serge Hallyn
2015-04-24 19:25 ` Christoph Lameter
2015-04-24 19:53 ` Andy Lutomirski
2015-04-24 20:13 ` Christoph Lameter
2015-04-24 20:18 ` Andy Lutomirski
2015-04-24 21:15 ` Serge E. Hallyn
2015-04-24 22:55 ` Andy Lutomirski
2015-04-25 2:45 ` Serge Hallyn
2015-04-27 14:55 ` Christoph Lameter
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=alpine.DEB.2.11.1503131049150.13899@gentwo.org \
--to=cl@linux.com \
--cc=aaronmdjones@gmail.com \
--cc=ahferroin7@gmail.com \
--cc=akpm@linuxfoundation.org \
--cc=corbet@lwn.net \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=morgan@kernel.org \
--cc=msa@moth.iki.fi \
--cc=mtk.manpages@gmail.com \
--cc=serge.hallyn@canonical.com \
--cc=tytso@mit.edu \
--cc=zohar@linux.vnet.ibm.com \
/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
all inboxes | Powered by JetHome®