linux-kernel - Re: [RFC] [PATCH] file posix capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Aug 2006 21:50:36 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Crispin Cowan <crispin@...ell.com>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Nicholas Miell <nmiell@...cast.net>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org, chrisw@...s-sol.org
Subject: Re: [RFC] [PATCH] file posix capabilities

Quoting Crispin Cowan (crispin@...ell.com):
> Stephen Smalley wrote:
> > Also, think about the real benefits of capabilities, at least as defined
> > in Linux.  The coarse granularity and the lack of any per-object support
> > is a fairly significant deficiency there that is much better handled via
> > TE.
> Only if the user wants to buy all the way into TE. Making POSIX
> Capabilities, TE, and AppArmor composeable choices seems like a good
> goal. The question is whether POSIX Capabilities on their own are worth
> while. But consider:
> 
>     * They are already there on their own, pulling POSIX Capabilities
>       out seems like a non-option because too much already uses them.
>     * They are nearly useless without some kind of management interface.
>       Adding a decent management interface can only make it better.
> 
> Serge has proposed a reasonable model. I would like to suggest that
> people, especially Serge, consider the AppArmor model as well before
> deciding.

So far this is not deciding on anything, just trying to follow the
partially implemented draft to it's specified and logical conclusion.
It may well be that it will turn out to just not be manageable, safe, or
useful, or none of the three.

> To quickly summarize the AppArmor model, you have an external policy

Does this stack with the capability module, or do you use purely your
own logic?

> file that says that e.g. /usr/local/foo can have net_bind_service and
> ipc_lock. This is a bit mask overlaid on top of whatever capabilities
> the process already has, e.g. because it is UID 0 it has all of them. So
> if someone runs /usr/local/foo as an unprivileged user, it has no
> capabilities, and the bitmask does nothing. If someone runs
> /usr/local/foo as root, then instead of all 32 capabilities, they get
> only those 2.

Can't do that with the fs capabilities.

But, the fs caps aren't intended to be an alternative to a policy-basd
system.  What I like about them is simply that instead of making a
binary setuid 0, and expecting it to give up the caps it doesn't need,
it can be given just the caps it needs right off the bat.

The apparmor and selinux policies would be complementary and useful as
ever on top of those, just as they currently are on top of setuid.

> >  At least some of the Linux capabilities lend themselves to easy
> > privilege escalation to gaining other capabilities or effectively
> > bypassing them.
> >   
> Certainly; cap_sys_admin effectively gives you ownership of the machine.
> But that is fundamental to the POSIX Capabilities model, and not
> something that Serge can change.

Yup, sigh...

A better split of the caps might be more useful than fs caps
themselves...

-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/