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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome