In fact, the LIDS project(www.lids.org) extend the capability usage to integrit in a MAC way. You can disable a capability world width and give the capability to the needed program( label the capability to a subject).

On Thu, 11 Jan 2001, Stephen Smalley wrote:

>
> On Thu, 11 Jan 2001, Jeffry Smith wrote:
>
> > Sent to both lists
> > Since I hadn't seen any traffic on the two lists about the other project, I
> > thought I'd cross-send a message, to ensure the two communities are aware of
> > what the other is doing. I figure, although the projects are tackling
> > different parts of the security of linux, there should be some overlap, since
> > privileges should make it easier to do the type enforcement (I think), and the
> > type enforcement can help with requirements for privileges (right?).
> >
> > Comments?
>
> The two mechanisms are mostly orthogonal, although SELinux can help
> to support the capability model and perhaps to even replace it. The
> POSIX.1e capabilities can be used to decompose superuser privileges for
> overriding the traditional Unix access controls. SELinux provides a
> flexible mandatory access control architecture that can support a wide
> range of security policies. There is no need for a mechanism to override
> the SELinux mandatory access controls because the security policy can be
> configured as needed to support fine-grained privileges for processes
> with respect to the mandatory controls. There is no need for any kind of
> "trusted" subject that operates outside of the boundaries of the mandatory
> access control architecture in SELinux.
>
> To better support the capability mechanism, the ability to
> use a capability is controlled by the SELinux mandatory access controls.
> A parallel mandatory access control is defined for each capability
> and must be granted by the security policy in order for the
> capability to be used. Since SELinux provides subject labeling and
> can support labels derived both from the attributes of the user and the
> program, it can restrict the use of capabilities to the appropriate
> program through the security policy configuration.
>
> In one of the predecessors of SELinux (the DTOS system), the NSA
> implemented a different mechanism than the POSIX.1e capabilities
> for decomposing superuser privileges. The superuser privileges were
> partitioned by having the security server return a set of override
> decisions along with its access decisions, where these override decisions
> could cause access to be granted even if the Unix access control would
> ordinarily deny access. Unlike the Linux capabilities, these override
> decisions could be based on both the label of the subject and the label of
> the relevant object. This mechanism permitted fine-grained decomposition
> (e.g. permission to override DAC read restrictions could be limited to
> files with certain security labels) and simpler management (through the
> use of the centralized security policy). Similar support could be added
> to the Security-Enhanced Linux as well but is not present in the
> current implementation.
>
> --
> Stephen D. Smalley, NAI Labs
> sds@tislabs.com
>
>
>
>
>
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>

-- 
Happy Hacking

Linux Intrusion Detection System  
http://www.lids.org/



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.