All of lore.kernel.org
 help / color / mirror / Atom feed
From: Seth Arnold <seth.arnold@suse.de>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Crispin Cowan <crispin@novell.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Nicholas Miell <nmiell@comcast.net>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org, chrisw@sous-sol.org
Subject: Re: [RFC] [PATCH] file posix capabilities
Date: Mon, 21 Aug 2006 20:19:12 -0700	[thread overview]
Message-ID: <20060822031911.GZ2584@suse.de> (raw)
In-Reply-To: <20060822025036.GA31422@sergelap.austin.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2006-08-22  3:19 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-30  1:13 [RFC] [PATCH] file posix capabilities Serge E. Hallyn
2006-08-14 22:06 ` Serge E. Hallyn
2006-08-15  0:20   ` Eric W. Biederman
2006-08-15  2:06     ` Serge E. Hallyn
2006-08-15  3:29       ` Eric W. Biederman
2006-08-15  4:22         ` Nicholas Miell
2006-08-15 11:49           ` Serge E. Hallyn
2006-08-15 12:20             ` Serge E. Hallyn
2006-08-15 19:31               ` Nicholas Miell
2006-08-15 19:41                 ` Serge E. Hallyn
2006-08-15 16:18             ` Stephen Smalley
2006-08-15 16:36               ` Casey Schaufler
2006-08-16  2:42               ` Serge E. Hallyn
2006-08-16 13:20                 ` Stephen Smalley
2006-08-17 12:00                   ` Joshua Brindle
2006-08-17 12:28                     ` Stephen Smalley
2006-08-21 20:36                       ` Serge E. Hallyn
2006-08-28 21:39                         ` Serge E. Hallyn
2006-08-29 18:37                           ` Seth Arnold
2006-08-29 19:58                             ` Serge E. Hallyn
2006-08-19  2:02                   ` Crispin Cowan
2006-08-19 17:08                     ` Casey Schaufler
2006-08-22  2:50                     ` Serge E. Hallyn
2006-08-22  3:19                       ` Seth Arnold [this message]
2006-08-19  2:02           ` Crispin Cowan
     [not found]   ` <44E1153D.9000102@ak.jp.nec.com>
     [not found]     ` <20060815021612.GC16220@sergelap.austin.ibm.com>
2006-08-15  3:48       ` KaiGai Kohei
2006-08-15 12:04         ` Serge E. Hallyn
2006-08-15 16:02   ` Casey Schaufler
2006-08-16  2:25     ` Serge E. Hallyn
  -- strict thread matches above, loose matches on Subject: below --
2006-08-16  2:43 Albert Cahalan
2006-08-16  3:23 ` Serge E. Hallyn
2006-08-16  3:44 ` Casey Schaufler

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=20060822031911.GZ2584@suse.de \
    --to=seth.arnold@suse.de \
    --cc=chrisw@sous-sol.org \
    --cc=crispin@novell.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=nmiell@comcast.net \
    --cc=sds@tycho.nsa.gov \
    --cc=serge@hallyn.com \
    --cc=serue@us.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.