[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=ZWg9JmEYXH5KOHHyYdcYqLAJPkMSEQLcjr+mA@mail.gmail.com>
Date: Mon, 8 Nov 2010 12:52:29 +0100
From: yersinia <yersinia.spiros@...il.com>
To: oss-security@...ts.openwall.com
Cc: Daniel Walsh <dwalsh@...hat.com>, agm@...gle.com
Subject: Re: filesystem capabilities
On Mon, Nov 8, 2010 at 3:52 AM, Solar Designer <solar@...nwall.com> wrote:
> Kees, all -
>
> There's a lot of talk lately regarding replacing the SUID bit on program
> binaries in Linux distros with filesystem capabilities. Specifically,
> Fedora and Ubuntu are heading in that direction.
>
> Fedora:
> http://fedoraproject.org/wiki/Features/RemoveSETUID
> https://bugzilla.redhat.com/show_bug.cgi?id=646440
>
> Ubuntu:
> http://www.outflux.net/blog/archives/2010/02/09/easy-example-of-fscaps/
> https://wiki.ubuntu.com/Security/FilesystemCapabilties
>
> While in general this is a good idea, there are issues with it, in
> arbitrary order:
>
> - Some currently-SUID programs are aware of them being (potentially)
> SUID, and will drop the "more privileged" euid when it is no longer
> needed, but they will probably not be aware of them possessing
> capabilities. This may result in larger parts of the programs
> (sometimes orders of magnitude larger) running with elevated privileges
> (or with allowed-to-be-elevated privileges, which is a privilege on its
> own and is usable through vulnerabilities that allow for arbitrary code
> execution). Let's consider ping, which appears to be the classical
> example of "where filesystem capabilities will help" (or so it is
> claimed). IIRC, it starts by acquiring a raw socket (NB: of a certain
> somewhat-limited type), then drops root privs (if it was installed SUID
> root and run by non-root), then proceeds to parse the command-line,
> resolve the provided hostname, and so on. If the SUID bit is replaced
> with cap_net_raw+ep, as seen in Kees' example above, will ping know to
> drop this capability? Hardly. Not without a source code patch.
> Besides, dropping the capability might [need to] require privileges
> beyond CAP_NET_RAW itself (recall the capability-dropping attack on
> sendmail from a decade ago). So does moving from SUID root to
> cap_net_raw+ep improve security? Most likely not. On the contrary, it
> results in hundreds of lines of ping's code and thousands of lines of
> library code (DNS resolver) running with elevated privileges, as
> compared to just a few lines of ping.c, which was the case with simple
> SUID root. Granted, those "elevated privileges" are a lot less than
> root privileges, but they're a lot more than having a single raw socket
> of a specific type.
>
Are you perhaps questioning that the linux capability model, based on POSIX
1.e, is not fine grained ? Well, perhaps. But it the capability model is
always in a DAC framework, and it is possible to augment with a MAC
framework as selinux, for example. That it is what it was written about
this (probably you know already
http://www.linuxsymposium.org/archives/OLS/Reprints-2008/hallyn-reprint.pdf)
"
That being said, privilege is not the only use of the root
identity. There are many files, such as are to be found
in /proc/ and /etc/, that are owned by root. Even
without super-user privilege, a process running in the
context of an impotent root user, can still do a large
amount of damage to a system by altering these files.
Here, DAC and MAC based security will continue to be
important in securing your Linux system.
"
But this not make the capability model without use IF the application are
not capability aware.
In fact I do not see why if I can not use a MAC mechanism, for various
reasons, why I don't should at least be able to reduce the privileges of
applications.Just for a simple example if rsyslog could be use a simple user
+ some capability should be probably sufficient for many as a residue risk :
but today many distro REQUIRE the MAC framework active because rsyslog run
as root: sure it is better to have a MAC framework ALSO in place if
possible. In short every security mesure augment the overall security, the
famous defense in depth. If i have a MAC system, for example, should be BAD
to don't pose any other security mesure in place - as a host based firewall
or a Web application Firewall, if i am using web application.
> - In some cases, the capability sets being granted are (almost)
> equivalent (or expandable to) full root powers. This is seen in:
>
> http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch<http://people.fedoraproject.org/%7Edwalsh/policycoreutils_setuid.patch>
>
> -%attr(4755,root,root) %{_bindir}/newrole
> +%attr(0755,root,root) %caps(cap_audit_write,cap_setuid) %{_bindir}/newrole
>
> Well, not a good example newrole . newrole in selinux target policy is a
confined (newrole_t) selinux application : i don't can, for example, load a
kernel module (CAP_SYS_MODULE) for example
sesearch -A -s newrole_t -c capability
Found 3 semantic av rules:
allow newrole_t newrole_t : capability { dac_override fowner setgid
setuid audit_write } ;
allow newrole_t newrole_t : capability { chown fowner fsetid sys_admin }
;
allow newrole_t newrole_t : capability net_bind_service ;
OTHO, newrule IS capability aware and drops its capabilities, from a quickly
code reading, almost.
In short over the next few years I think there we will be close to the model
described here
http://www.friedhoff.org/posixfilecaps.html
But certainly it will not be easy, require much work. Just for example in
some distro "prelink" drop linux capability
https://bugzilla.redhat.com/show_bug.cgi?id=456105 for now.
Best Regards
Elia
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
