Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Chris Wright <chris@wirex.com>]

* Stephen Smalley (sds@epoch.ncsc.mil) wrote:
> On Thu, 2003-04-24 at 14:36, Chris Wright wrote:
> > Or perhaps introducing some of the CAP_MAC_* bits.
> 
> I don't think that would help.  As I mentioned during the earlier
> discussion with Andreas, you want to be able to allow the security
> module to call the inode getxattr and setxattr operations without
> restriction for internal management of the security labels, while
> applying access controls to user processes invoking the [gs]etxattr
> system calls.  Hence, you don't want the permission check implemented in
> the handler; it is better to handle the checking entirely via the LSM
> hooks in the [gs]etxattr calls and allow unrestricted internal use of
> the inode [gs]etxattr operations by the module.  Capability checks are

Yes, this makes sense to me.

> also too coarse-grained; you want to be able to perform a permission
> check based on the process and the inode attributes, not just a
> process-based check.

Of course, good point.  I thought I might regret throwing CAP_ into the
picture ;-)

> If the intent of the trusted namespace is for attributes that can be
> managed by superuser processes (this is my impression), then I think it
> would be better to create a separate namespace and handler for security
> modules for clarity.  Or at least for MAC modules.

Yes, there was also some mention of the permission issue w.r.t. HSM and
(i vaguely recall) an xattr interface proposed that noted if the request was
internal from the kernel (skip the capable check) or on behalf of user.
If this were carried through, it could suffice, no?

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net