From: "Diego Elio Pettenò" <flameeyes@flameeyes.eu>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
Date: Sat, 26 Jan 2013 17:01:13 +0100 [thread overview]
Message-ID: <5103FDC9.7040603@flameeyes.eu> (raw)
In-Reply-To: <201301260246.12861.vapier@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]
On 26/01/2013 08:46, Mike Frysinger wrote:
>
> at least, this is all my understanding of things. i could be completely
> wrong, so feel free to correct something if you notice it.
All looks good to me, but just because somebody is going to wonder this
I would add a few words:
While this is basically the same underlying idea of selinux and rbac, it
is much more limited in scope. In particular instead of telling each
program exactly what they can or cannot do, we're giving them a broad
spectrum of privileges (but much narrower than what a setuid root
program would have). This is both less rewarding in term of security,
and less headache-prone.
Indeed most of the capabilities currently allowed are pretty much "do
something almost like root" — so for instance `tcpdump` needs
CAP_NET_ADMIN that does... almost everything with the network, while
`ping` would just use CAP_NET_RAW and be able to send out the ICMP ECHO
packets just fine. A web server, or any other server using privileged
TCP/UDP ports (<1024) would need instead CAP_NET_BIND_SERVICE.
All these settings allow tools to run as users who generally don't have
said capabilities, and yet be able to execute higher-level features. As
Mike said, this is just to replace setuid (and if you got selinux, you
go one step further because you can for instance give
CAP_DAC_READ_SEARCH to a tool, but also verify that it doesn't go
randomly reading stuff out of an user's home.
There's also a different kind of capabilities, in theory, relating to
users instead and using PAM — but I never got to get it working :(
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
next prev parent reply other threads:[~2013-01-26 16:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-25 23:51 [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree Mike Frysinger
2013-01-26 0:10 ` Gilles Dartiguelongue
2013-01-26 0:17 ` Diego Elio Pettenò
2013-01-26 7:46 ` Mike Frysinger
2013-01-26 10:17 ` [gentoo-dev] " Duncan
2013-01-26 16:01 ` Diego Elio Pettenò [this message]
2013-01-26 16:13 ` [gentoo-dev] " Rich Freeman
2013-01-26 17:02 ` Diego Elio Pettenò
2013-01-28 19:58 ` Gilles Dartiguelongue
2013-01-26 13:21 ` Michał Górny
2013-01-26 17:08 ` Mike Frysinger
2013-01-26 21:07 ` Doug Goldstein
2013-01-27 17:26 ` Mike Frysinger
2013-01-27 18:24 ` Kacper Kowalik
2013-01-29 12:14 ` [gentoo-dev] " Duncan
2013-01-30 0:47 ` Diego Elio Pettenò
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=5103FDC9.7040603@flameeyes.eu \
--to=flameeyes@flameeyes.eu \
--cc=gentoo-dev@lists.gentoo.org \
/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