From: Serge Hallyn <serge.hallyn@canonical.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Andrew G. Morgan" <morgan@kernel.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Casey Schaufler <casey@schaufler-ca.com>,
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>,
Markku Savela <msa@moth.iki.fi>
Subject: Re: [RFC] Capabilities still can't be inherited by normal programs
Date: Wed, 12 Dec 2012 12:45:20 -0600 [thread overview]
Message-ID: <20121212184520.GA1797@serge-ThinkPad-X130e> (raw)
In-Reply-To: <CALCETrWa10sLekJZaaRBJOJW8jnNNWNMy0pVTeu5+OvxS6ZY9A@mail.gmail.com>
Quoting Andy Lutomirski (luto@amacapital.net):
> On Sat, Dec 8, 2012 at 3:57 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >
> > I just tried to search to find actual uses of pI/fI. Here's what I found:
>
> I downloaded all the Fedora spec files and searched for file
> capabilities. Assuming I didn't mess up, here's what I found:
>
> fping.spec:%attr(0755,root,root) %caps(cap_net_raw=ep) %{_sbindir}/fping
> fping.spec:%attr(0755,root,root) %caps(cap_net_raw=ep) %{_sbindir}/fping6
> glibc.spec:%attr(755,root,root) %caps(cap_chown,cap_fowner=pe)
> %{_prefix}/libexec/pt_chown
> gnome-keyring.spec:%attr(0755,root,root) %caps(cap_ipc_lock=ep)
> %{_bindir}/gnome-keyring-daemon
> httpd.spec:%caps(cap_setuid,cap_setgid+pe)
> %attr(510,root,%{suexec_caller}) %{_sbindir}/suexec
> iputils.spec:%attr(0755,root,root) %caps(cap_net_raw=ep) %{_sbindir}/clockdiff
> iputils.spec:%attr(0755,root,root) %caps(cap_net_raw=ep) %{_sbindir}/arping
> iputils.spec:%attr(0755,root,root) %caps(cap_net_raw=ep
> cap_net_admin=ep) %{_bindir}/ping
> iputils.spec:%attr(0755,root,root) %caps(cap_net_raw=ep
> cap_net_admin=ep) %{_bindir}/ping6
> mtr.spec:%attr(0755,root,root) %caps(cap_net_raw=pe) %{_sbindir}/mtr
> policycoreutils.spec:%caps(cap_setpcap,cap_setuid,cap_fowner,cap_dac_override,cap_sys_admin,cap_sys_nice=pe)
> %{_sbindir}/seunshare
> policycoreutils.spec:%attr(0755,root,root)
> %caps(cap_setpcap,cap_audit_write,cap_sys_admin,cap_fowner,cap_chown,cap_dac_override=pe)
> %{_bindir}/newrole
> rpm.spec:- fix double-free on %caps in spec (#877512)
> rsh.spec:%attr(0755,root,root) %caps(cap_net_bind_service=pe) %{_bindir}/rcp
> rsh.spec:%attr(0755,root,root) %caps(cap_net_bind_service=pe) %{_bindir}/rlogin
> rsh.spec:%attr(0755,root,root) %caps(cap_net_bind_service=pe) %{_bindir}/rsh
> systemd.spec:%caps(cap_dac_override,cap_sys_ptrace=pe)
> %{_bindir}/systemd-detect-virt
> wireshark.spec:%attr(0750, root, wireshark)
> %caps(cap_net_raw,cap_net_admin=eip) %{_sbindir}/dumpcap
> xorg-x11-server.spec:%global Xorgperms %attr(0711,root,root)
> %caps(cap_sys_admin,cap_sys_rawio,cap_dac_override=pe)
>
> The only inheritable bit is on dumpcap, and it's not necessary there.
These are all cases of using caps to replace setuid-root. In itself this
doesn't make the point you're aiming to make. At the same time I don't
dispute that you may be right that almost noone is using fI the way we'd
like.
The reason I was in an earlier email laying out how a sudo-adm-like
replacement could work is that I do think we're missing some userspace
plumbing to make use of fI easier. We miss a tool to easily say "let
joe use /usr/bin/X with caps Y". We miss a way for packaging tools to
easily say "create a new user foo which has pI=xyz" and "install bar
so that foo can run it with fI=xyz (by placing a copy under
/var/lib/privs/foo). And we miss a one-liner for init scripts to
launch services as a specific user that way.
That still doesn't address the wrapper issue you raised, though it
could lead to a design to solve it.
-serge
next prev parent reply other threads:[~2012-12-12 18:45 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
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 [this message]
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=20121212184520.GA1797@serge-ThinkPad-X130e \
--to=serge.hallyn@canonical.com \
--cc=casey@schaufler-ca.com \
--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=luto@amacapital.net \
--cc=morgan@kernel.org \
--cc=msa@moth.iki.fi \
--cc=serge@canonical.com \
--cc=serge@hallyn.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.