Re: SELinux & Linux-privs projects

Re: SELinux & Linux-privs projects

[Casey Schaufler]

According to Robert Watson:
>
> I've run into a few limitations in the POSIX.1e MAC interface that I've
> needed to work around and suggest directions for future improvement if
> there's any desire towards moving to a more general MAC framework:
> 
> 1) Dominance operator required -- mac_dominate() must return true, false,
>    or an error (EINVAL), but is unable to return that dominance is
>    undefined.  For un-ordered or partially ordered MAC schemes, this will
>    cause problems for applications that rely on the ordering.  In this
>    case, mac_dominate()  will often (or always) return 0, making it less
>    useful; as it's not clear that mac_dominate() will be meaningful in an
>    environment and if it is, what it means may not be consistent. 

In the Trix MAC implementation almost all (I can't think of any
exceptions, but I don't have time to go look'n) calls to
mac_dominate() could be replaced with mac_access(,, READ).
Similarly, mac_equal() could be replaced by mac_access(,, WRITE).

This brings us back to Olin Sibert's assertion that there really
ought to be a take_everything_into_account_access(,....,<mode>)
function, which is policy independent.

> 2) Limited support for compound labels -- when more than one scheme is in
>    use at a time, a compound mac label is required.  However, the
>    dominance operator may be defined differently for different components
>    of the label (for example, Biba dominate differs from MLS dominate). 
>    When moving to different or more complex schemes, it's easy to imagine
>    situations where mac_dominate() has to combine inconsistent results,
>    and presumably always return 0 as a result. 

I could imagine such a policy, but not without mangling
the capability policy to achieve it. OKay, so the policy
could be B&LaP unless you're a general, in which case it's
based on a crypographic siganture. IT's that pesky "unless"
clause that starts pulling you into the realm of privilege.
 
> 3) mac_dominate() is not meaningful without understanding the policy in
>    question: that is, a userland application cannot use it for policy
>    evaluation to determine whether a given operation on a given object is
>    permitted, because mac_dominate() isn't an "is this allowed" request,
>    it has to do with label relationships. 

Yes, this is the problem in a nutshell. A mac_access() function
would be more policy independent.
 
> This would include functions that
> request an access control determination for a pair of labels and an
> operation identifier,

mac_access() above?

> functions to determine inheritence when a subject
> spawns a new object from an existing object (file from directory, packet
> from interface, MIB hiearchies, etc), and so on.

A good topic for a rousing debate.

> Also, an interface to
> push requests concerning MAC labels based on knowledge of the syntax and
> semantics of a component of the label, but without assumptions in the
> interface about what those might be.

How does this differ from mac_from_text()? I expect
you're looking for something more sophisticated, but
in what way?

> In addition, a way to determine what
> components of the label are available, and properties of the policy
> enforcement environment. 

main()
{
	printf("%s\n", mac_what());
}

% mac_what
Well, you've got a Domian Enforcement scheme emulating
Bell & LaPadula Sensitivity, expect that write-up is
not allowed and sockets require label equality to read
and there's a special case label for /dev/null, and
Clarke-Wilson integrity on sockets and a time-stamp
scheme for executables which is only applied to game
programs and there are four-hundred sixteen administrater
role defined. Hope that helps!
%

 
> This won't allow applications invoking privilege to manage mandatory
> labels to be completely free of knowledge of a policy, but it will allow
> the application that is aware of one component of the policy to override
> the policy via general interfaces, at the same time as not overriding
> policies that it doesn't understand, or isn't intended to manipulate. 
> Similarly, it will allow applications maintaining objects to rely on the
> system policy evaluation when enforcing protections on these internal
> objects.  The SELinux implementation allows some aspects of this (in
> particular, allowing applications to use the standard system policy and
> access control mechanisms), as does the NAI DTE implementation.  POSIX.1e
> begins the process of moving towards a general labeling mechanism, and
> though some changes could better support the kind of environment that I
> envision.

Just to throw gas on the fire, please consider the
implications of supporting such a system in the field.
It's hard enough to teach people simple MAC policies.
A general, configurable MAC policy would be a vendor's
nightmare.


Casey Schaufler				Manager, Trust Technology, SGI
casey@sgi.com				voice: 650.933.1634
casey_p@pager.sgi.com			Pager: 888.220.0607

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

Re: [Linux-privs-discuss] SELinux & Linux-privs projects

[Christoph Hellwig]

On Thu, Jan 11, 2001 at 01:31:44PM -0500, Stephen Smalley wrote:
> > That's because those are the only operations POSIX systems
> > support! It's implicit in being a POSIX (DRAFT) standard.
> 
> You can define distinct operations (permissions) in the
> mandatory security policy for distinct kernel services
> without altering the interfaces or behavior for discretionary
> access controls. 

Sure you can.  But Posix 1003.1e is designed to fit nicely into
a UNIX/Posix enviroment.  And that's exactly why I like it.

> As discussed ad nauseum on the robust open source mailing list,
> Type Enforcement is desirable for its support for ensuring that
> applications are unbypassable and tamperproof, that processes
> with any sort of privileges cannot execute untrustworthy
> code, and for providing least privilege.

For this you have capabilities.  Look at the allowed set in filesystem
capabilities.  That's another fine part of Posix 1003.1e: it seperates
cleanly what does not belong together.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.


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

Re: SELinux & Linux-privs projects

[Stephen Smalley]

> For this you have capabilities.  Look at the allowed set in filesystem
> capabilities.  That's another fine part of Posix 1003.1e: it seperates
> cleanly what does not belong together.

A paper by Spencer Minear in this year's BSD Conference and Expo
provided a brief comparison of the POSIX.1e capability mechanism and
a BSD implementation of Type Enforcement.  You can find a copy under
http://www.bsdcon.com/proceedings/spencer_minear.  This ties in
with my earlier discussion of the advantages of using an
architecture like SELinux to provide similar functionality
to the capability mechanism, as was done in one of the predecessors
of SELinux (the DTOS system).  The paper also has some useful background
information on the development of Type Enforcement and its relationship to
MLS.  

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

SELinux & Linux-privs projects

[Jeffry Smith]

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?  

jeff


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

Re: SELinux & Linux-privs projects

[Stephen Smalley]

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.

Re: SELinux & Linux-privs projects

[Huagang Xie]

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.