From: Andy Lutomirski <luto@amacapital.net>
To: "Andrew G. Morgan" <morgan@kernel.org>
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Kees Cook <keescook@chromium.org>,
James Morris <james.l.morris@oracle.com>,
Eric Paris <eparis@redhat.com>,
"Serge E. Hallyn" <serge@canonical.com>
Subject: Re: [RFC] Capabilities still can't be inherited by normal programs
Date: Sun, 2 Dec 2012 20:48:03 -0800 [thread overview]
Message-ID: <CALCETrXUSz9EN-tGMfJkw9+1kO0hfmQk4E5XPF0cg9nmpPXepg@mail.gmail.com> (raw)
In-Reply-To: <CALQRfL7e160D+vzVhT-fUS-_Yp55wqnWkRFJdDTOOVjjStd9Jw@mail.gmail.com>
On Sun, Dec 2, 2012 at 6:20 PM, Andrew G. Morgan <morgan@kernel.org> wrote:
> On Sun, Dec 2, 2012 at 3:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Sun, Dec 2, 2012 at 2:26 PM, Andrew G. Morgan <morgan@kernel.org> wrote:
>>> On Sun, Dec 2, 2012 at 10:35 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> On Sun, Dec 2, 2012 at 9:21 AM, Andrew G. Morgan <morgan@kernel.org> wrote:
>>>>> There is a fairly well written paper ;-) explaining how things are
>>>>> supposed to work:
>>>>>
>>>>> http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf
>>>>>
>>>>> The inheritable set is not intended to work the way you seem to want.
>>>>> Naive inheritance like that is quite explicitly the opposite of what
>>>>> was designed.
>>>>
>>>> I'm aware that the system was designed, or perhaps evolved, to prevent
>>>> users with uid != 0 from inheriting capabilities unless vfs
>>>> inheritable caps are granted on a per-file basis. I want a way around
>>>> that -- I want to mix non-root, capabilities, and exec. This is damn
>>>> near impossible right now if I don't have CAP_SETFCAP or root's
>>>> explicit, per-program cooperation. CAP_SETFCAP is essentially
>>>> equivalent to "let me do anything".
>>>>
>>>> As it stands, using something like pam_cap to grant a user cap_net_raw
>>>> is useless -- that user can't use the privilege because (unless uid ==
>>>> 0) the privilege will never end up in the permitted set.
>>>
>>> Have you tried adding fI of cap_net_raw to the file to be executed?
>>
>> Yes, and it works. I don't like this solution because:
>>
>> a) It doesn't scale in terms of sysadmin resources required.
>
> By doesn't scale, you mean it requires the admin to define which
> actual binaries on their system can wield privilege?
Yes.
>>
>> c) tcpdump isn't really special. I trust this user account with
>> cap_net_raw, and that should be all the configuration I need.
>
> But this is a statement about access control, and not a statement
> about privilege. You trust the user to invoke something that can do
> tcpdump, you don't really trust the user to generate arbitrary packets
> on the network.
That *really* doesn't scale. Suppose I trust one user to capture
packets and a second user to run portscans. Setting tcpdump and nmap
as cap_net_raw+i and granting both users cap_net_raw (inheritable)
doesn't do it. (Even ignoring the possibility of bugs in tcpdump and
nmap.)
In the immediate case that prompted this question, I only really trust
the user to run tcpdump, although I don't particularly care if they
generate arbitrary packets. For simplicity, if I could use full
capability inheritance, I'd probably just grant cap_net_raw and be
done with it. In this case, though, I have a helper that's ~50 lines
of code that has cap_net_raw=p. It checks that it's happy about
what's going on, it does some apparmor twiddling (sigh), and it
execve's /usr/sbin/tcpdump. And it only works because I set tcpdump
as cap_net_raw+i.
The ability to run helper programs is *useful*. I find it rather
limiting that privileged programs that don't have uid=0 can't really
do it without administrative help.
>
>> d) If I really wanted, I could emulate execve without actually doing
>> execve, and capabilities would be inherited.
>
> If you could modify the executable properties of the binary that has
> the privilege to wield a privilege then you are either exploiting an
> app bug, or doing something the privileged binary has been trusted to
> do.
That's not what I mean. I would:
fork()
munmap everything
mmap ld.so
set up a fake initial stack and the right fd or mapping or whatever
just to ld-linux.so
That's almost execve, and privilege inheritance works.
>
>> The issue with allowing real capability inheritance is that,
>> currently, it's safe for a program with fP != 0 to add an inheritable
>> capability and then execve something caller-controlled. I don't know
>> whether anything actually does this, but it's hard to prove that
>> nothing does. Hence my idea of requiring no_new_privs to make
>> capabilities inheritable.
>
> Assuming this is not another app bug, and that's what the executable
> with fP != 0 does, then that's why it was given fP != 0 - its what the
> program was designed to do. Why is this an issue?
>
>> An alternative, and considerably more intrusive, change would be to
>> add a fourth mask of genuinely inheritable capabilities.
>
> If you believe that you want to give a user the privilege to grant a
> privilege to an arbitrary binary to do things like this, why not write
> an app that adds file capabilities to target binaries owned by the
> user? You can make it execute-only by said user and let them do
> whatever they want. This requires no kernel changes.
Egads. IMO that's way scarier. I'd rather just mark ld.so as <everything>=i.
My point about no_new_privs is: if I trust a user or a program with a
capability, I probably also trust it to invoke helpers (via execve) as
it sees fit. What I don't trust is everything else on the system that
has fP or set[ug]id bits set -- they probably weren't written to
anticipate inheritable capabilities and something like the sendmail
bug might happen again. With no_new_privs set, though, that whole
vulnerability surface is gone -- the fP bits, setuid, and setgid are
inoperable.
--Andy
next prev parent reply other threads:[~2012-12-03 4:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-02 3:04 [RFC] Capabilities still can't be inherited by normal programs Andy Lutomirski
2012-12-02 17:21 ` Andrew G. Morgan
2012-12-02 18:35 ` Andy Lutomirski
2012-12-02 22:26 ` Andrew G. Morgan
2012-12-02 23:04 ` Andy Lutomirski
2012-12-03 2:20 ` Andrew G. Morgan
2012-12-03 4:48 ` Andy Lutomirski [this message]
2012-12-04 13:54 ` Serge E. Hallyn
2012-12-05 19:32 ` Andy Lutomirski
2012-12-05 20:12 ` Markku Savela
2012-12-05 21:05 ` Serge Hallyn
2012-12-05 21:46 ` Andy Lutomirski
2012-12-05 22:20 ` Serge Hallyn
2012-12-07 0:57 ` Casey Schaufler
2012-12-07 14:42 ` Serge E. Hallyn
2012-12-07 17:00 ` Casey Schaufler
2012-12-07 17:07 ` Andrew G. Morgan
2012-12-07 18:39 ` Andy Lutomirski
2012-12-08 22:33 ` Andrew G. Morgan
2012-12-08 23:37 ` Andy Lutomirski
2012-12-08 23:57 ` Andy Lutomirski
2012-12-12 18:29 ` Andy Lutomirski
2012-12-12 18:45 ` Serge Hallyn
2012-12-19 13:14 ` Pádraig Brady
2012-12-10 14:59 ` Serge Hallyn
2012-12-10 15:47 ` Casey Schaufler
2012-12-10 16:27 ` Serge Hallyn
2012-12-10 18:12 ` Andy Lutomirski
2012-12-10 19:13 ` Casey Schaufler
2012-12-10 19:31 ` Andy Lutomirski
2012-12-10 19:51 ` Casey Schaufler
2012-12-10 19:55 ` Andy Lutomirski
2012-12-10 20:17 ` Kees Cook
2012-12-10 18:05 ` Andy Lutomirski
2012-12-10 14:36 ` Serge Hallyn
[not found] ` <CALQRfL6UWLFpTfvan9oirtLdozJqZX4oZwDuQFVnJp8MP06C_Q@mail.gmail.com>
2012-12-10 14:27 ` Serge Hallyn
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=CALCETrXUSz9EN-tGMfJkw9+1kO0hfmQk4E5XPF0cg9nmpPXepg@mail.gmail.com \
--to=luto@amacapital.net \
--cc=eparis@redhat.com \
--cc=james.l.morris@oracle.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=morgan@kernel.org \
--cc=serge@canonical.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;
as well as URLs for NNTP newsgroup(s).