Message-ID: <44E6714C.3090707@novell.com>
Date:	Fri, 18 Aug 2006 19:02:52 -0700
From:	Crispin Cowan <crispin@...ell.com>
To:	Stephen Smalley <sds@...ho.nsa.gov>
CC:	"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

Stephen Smalley wrote:
> On Tue, 2006-08-15 at 21:42 -0500, Serge E. Hallyn wrote:
>   
>> But since file capabilities cannot survive an exec, analysis with a gui
>> which walks the fs could be pretty simple.
>>     
> Except that people actually want them to be inheritable (under certain
> conditions), just in a way that avoids the problems encountered in the
> past.  If you start on the path of making capabilities useful, you'll
> have to tackle that as well.
>   
Stephen makes a good point here.

Have you looked at how AppArmor handles POSIX Capabilities? It has these
advantages:

    * Whether a capability is inheritable or not is specified by policy,
      addressing Stephan's' point.
    * Does not depend on extended attributes, so becomes filesystem
      independent.
    * As I understand it, it resembles the Solaris "process rights"
      mechanism, and so (as Albert Cahalan suggested) will be less
      surprising to Solaris users transitioning to Linux.

Currently it is implemented as part of the AppArmor module, but I could
imagine it being busted out into a separate module. The main thing I
would wonder about is some kind of API so that policy engines like
AppArmor and SELinux could manipulate the POSIX capabilities.

> Actually, ptrace already performs a capability comparison (cap_ptrace).
> Wrt signals, it wasn't the communication channel that concerned me but
> the ability to interfere with the operation of a process running in the
> same uid but different capabilities, like stopping it at a critical
> point.  Likewise with many other task hooks - you wouldn't want to be
> able to depress the priority of a process running with greater
> capabilities.
>   
Is that a property of Serge's module? Or just a property of the basic
crappyness of the POSIX Capabilities idea in the first place?

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

To quickly summarize the AppArmor model, you have an external policy
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.

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

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes

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

Powered by blists - more mailing lists