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] [day] [month] [year] [list]

Message-ID: <20060822031911.GZ2584@suse.de>
Date:	Mon, 21 Aug 2006 20:19:12 -0700
From:	Seth Arnold <seth.arnold@...e.de>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Crispin Cowan <crispin@...ell.com>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	"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

On Mon, Aug 21, 2006 at 09:50:36PM -0500, Serge E. Hallyn wrote:
> > 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?

We link against the commoncap facility introduced by Bert Hubert, to
provide 'standard' capabilities support; we simply add another check at
capable() time to _also_ check the capability against the list allowed
in the current profile.

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

Seems like a great idea for e.g. binding to low ports, chroot, and
changing users for e.g. password changing. The other 24-26 capabilities
may be less useful. :) Still, I agree, complementary, and hopefully a
mechanism such as this proposed mechanism would help drag capabilities
out of the dark ages.

Thanks Serge

Content of type "application/pgp-signature" skipped