[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Dec 2012 12:45:20 -0600
From: Serge Hallyn <serge.hallyn@...onical.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: "Andrew G. Morgan" <morgan@...nel.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Casey Schaufler <casey@...aufler-ca.com>,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
Kees Cook <keescook@...omium.org>,
James Morris <james.l.morris@...cle.com>,
Eric Paris <eparis@...hat.com>,
"Serge E. Hallyn" <serge@...onical.com>,
Markku Savela <msa@...h.iki.fi>
Subject: Re: [RFC] Capabilities still can't be inherited by normal programs
Quoting Andy Lutomirski (luto@...capital.net):
> On Sat, Dec 8, 2012 at 3:57 PM, Andy Lutomirski <luto@...capital.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists