SELinux & Linux-privs projects

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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Christoph Hellwig]

On Thu, Jan 11, 2001 at 09:44:54AM -0500, 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 

Linux-privs and other Posix1003.1e subsystems currenlty in development
for Linux provide a UNIXish way of trusted systems, while SELinux
implements ruleset-based security and is rather differnt and put
policy into the kernel, something that is dtringly disliked in UNIX.

So they are two rather different ways to archive the same goal.

	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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Stephen Smalley]

On Thu, 11 Jan 2001, Christoph Hellwig wrote:

> Linux-privs and other Posix1003.1e subsystems currenlty in development
> for Linux provide a UNIXish way of trusted systems, while SELinux
> implements ruleset-based security and is rather differnt and put
> policy into the kernel, something that is dtringly disliked in UNIX.
> 
> So they are two rather different ways to achieve the same goal.

Allow me to clarify about SELinux.  I'll respond to your points
in reverse order.  SELinux and Linux-privs are NOT different ways
to achieve the same goal.  SELinux provides a flexible mandatory
access control architecture.  The architecture can enforce a wide
variety of security policies.  It can enforce the separation of
information based on confidentiality and integrity requirements.
This is quite different from Linux Privs, which provides a mechanism
for decomposing superuser privileges.  It is also quite different
from POSIX.1e mandatory access controls, which are tied to a 
specific kind of mandatory security policy.

It is also inaccurate to suggest that the issue is placing policy
in the kernel.  SELinux provides clean separation of policy from
enforcement, with the security policy cleanly encapsulated
in a single component of the operating system called the
security server with a general interface.  Many different
security server implementations are possible, including
implementations that consult user space servers.  The
example security server implementation consists of a
basic policy engine that consults a security policy configuration
read from a file.  This is also a false comparison, because
the POSIX.1e mandatory access control policy implementation would
likewise involve a kernel component, and it is more likely to
involve policy-specific code being used by other components of
the kernel.

--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Christoph Hellwig]

On Thu, Jan 11, 2001 at 11:04:32AM -0500, Stephen Smalley wrote:
> Allow me to clarify about SELinux.  I'll respond to your points
> in reverse order.  SELinux and Linux-privs are NOT different ways
> to achieve the same goal.  SELinux provides a flexible mandatory
> access control architecture.  The architecture can enforce a wide
> variety of security policies.  It can enforce the separation of
> information based on confidentiality and integrity requirements.
> This is quite different from Linux Privs, which provides a mechanism
> for decomposing superuser privileges.

The capabilities do that, right.  But if I'm not completly wrong
Linux-Privs stands for all the Posix 1003.1e stuff, but currently
only caps are implemented, though work is done on other parts
(acl, aud, mac).

> It is also quite different
> from POSIX.1e mandatory access controls, which are tied to a 
> specific kind of mandatory security policy.

Capabilities and mac are of course different, otherwise you probably
won't find them in the same posix standard...

> It is also inaccurate to suggest that the issue is placing policy
> in the kernel.  SELinux provides clean separation of policy from
> enforcement, with the security policy cleanly encapsulated
> in a single component of the operating system called the
> security server with a general interface.  Many different
> security server implementations are possible, including
> implementations that consult user space servers.

Then you basically end up with rsbac.  But your current code does not
look like you provide support for that.

> The
> example security server implementation consists of a
> basic policy engine that consults a security policy configuration
> read from a file.  This is also a false comparison, because
> the POSIX.1e mandatory access control policy implementation would
> likewise involve a kernel component, and it is more likely to
> involve policy-specific code being used by other components of
> the kernel.

No.  The pocily for posix 1003.1e mac is set from usespace and stored
in extented attributes, at least in the TrustedBSD version, my initial
Linux hack and SGIs version.

	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

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

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

[Christoph Hellwig]

On Fri, Jan 12, 2001 at 12:42:56AM +0800, Huagang Xie wrote:
> 
> 
> 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).  

It's rather ugly compared to real filesystem capabilities and even
the elfcap hack.

	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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Stephen Smalley]

> No.  The policy for posix 1003.1e mac is set from userspace and stored
> in extended attributes, at least in the TrustedBSD version, my initial
> Linux hack and SGIs version.

By "policy", are you simply referring to file labels?  What about
the security policy logic that determines whether access is granted?
Where is that implemented?  It sounds like there may be a misunderstanding
here.  In SELinux, file labels can likewise be set by applications
and are associated with files through a combination of a field in
the inode and a set of label mapping files.  We would have used extended
attributes, except that they weren't available in ext2fs.  The
format and contents of security labels can be arbitrarily changed
without modifying or even recompiling the file system code (or
networking code or process management code, etc).  The security policy
decisions are specified through a set of security policy
configuration files that can be edited and compiled into a 
binary representation that is loaded and used by the security server.
Most desired security policy changes can be implemented simply
by changing that configuration and reloading it.  If you want a 
radically new style of policy, you can reimplement the security server
itself, but that still doesn't require any changes or even recompilation
of the other components of the operating system.

The POSIX.1e MAC tightly couples policy and enforcement because
it is designed for a particular kind of security policy.
It assumes a certain kind of security label.  It assumes hierarchical
relationships among labels.  It assumes that it is
sufficient to treat all operations as being read, write, or execute.  
In order to support Type Enforcement or Role-Based Access
Control or other kinds of mandatory security, you are very likely
to need to change or at least recompile the file system code,
the networking code, etc.  

--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Stephen Smalley]

On Thu, 11 Jan 2001, Christoph Hellwig wrote:

> > It is also quite different
> > from POSIX.1e mandatory access controls, which are tied to a 
> > specific kind of mandatory security policy.
> 
> Capabilities and mac are of course different, otherwise you probably
> won't find them in the same posix standard...

I guess my antecedent was ambiguous.  I was trying to say that
the SELinux mandatory access controls are quite different from
POSIX.1e mandatory access controls, because SELinux provides
a flexible mandatory access control architecture that can
support many different kinds of security policies while
POSIX.1e is limited to a particular kind of security
policy (multi-level security, and perhaps Biba integrity
or other lattice-based models).  SELinux can support
lattice-based models like multi-level security, but it
can also support Type Enforcement, Role-Based Access
Control, and other models.  So POSIX.1e MAC only does
a subset of what SELinux does.

--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Casey Schaufler]

Stephen Smalley wrote:

> The POSIX.1e MAC tightly couples policy and enforcement because
> it is designed for a particular kind of security policy.
> It assumes a certain kind of security label.

I don't know who told you that, but it certainly wasn't
anyone who worked on the standard. The 1e MAC specification
is explicitly devoid of any such assumptions. That's one
reason there's no specification on Moldy directories, for
example.

> It assumes hierarchical relationships among labels.

It assumes that there are two relationships, equality
and dominance, between labels. I can easily show labeling
schemes which are cyclic, but which can be represented
in terms of these relationships.

> It assumes that it is
> sufficient to treat all operations as being read, write, or execute.

That's because those are the only operations POSIX systems
support! It's implicit in being a POSIX (DRAFT) standard.

> In order to support Type Enforcement or Role-Based Access
> Control or other kinds of mandatory security, you are very likely
> to need to change or at least recompile the file system code,
> the networking code, etc.

Yes, and?

-- 

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

[Stephen Smalley]

On Thu, 11 Jan 2001, Casey Schaufler wrote:

> I don't know who told you that, but it certainly wasn't
> anyone who worked on the standard. The 1e MAC specification
> is explicitly devoid of any such assumptions. That's one
> reason there's no specification on Moldy directories, for
> example.

I assume that "devoid of any assumptions" refers to the kind
of label as opposed to being designed for a particular kind
of security policy.  Are you suggesting that POSIX.1e was
not designed specifically for lattice-based models like
BLP and Biba?  The fundamental statement of mandatory access
control policy in the standard is hardly suitable for all
mandatory security policies:  Subjects cannot cause information
labeled at some MAC label L1 to become accessible to subjects
at L2 unless L2 dominates L1.  You can't represent Type
Enforcement by such a statement.  And the kind of label is
implicit by the dominates relatinship.

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

> > In order to support Type Enforcement or Role-Based Access
> > Control or other kinds of mandatory security, you are very likely
> > to need to change or at least recompile the file system code,
> > the networking code, etc.
> 
> Yes, and?

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.  BLP and Biba
are not enough for everyone.  And I'm not suggesting that
Type Enforcement is the magic solution either - the
point is that we need a flexible mandatory access control
architecture so that the system can be customized and
can evolve easily to meet different security requirements.

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

(offtopic) Re: [Linux-privs-discuss] SELinux & Linux-privs projects

[Andrew Morgan]

Stephen Smalley wrote:
> As discussed ad nauseum on the robust open source mailing list,

How 'open' is this 'robust open source' mailing list? Where is it
located, does it have any archives? [Google wasn't able to locate it for
me.]

Thanks

Andrew

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

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

[Casey Schaufler]

Stephen Smalley wrote:
> 
> On Thu, 11 Jan 2001, Casey Schaufler wrote:
> 
> > I don't know who told you that, but it certainly wasn't
> > anyone who worked on the standard. The 1e MAC specification
> > is explicitly devoid of any such assumptions. That's one
> > reason there's no specification on Moldy directories, for
> > example.
> 
> I assume that "devoid of any assumptions" refers to the kind
> of label as opposed to being designed for a particular kind
> of security policy.

No, it means that the developers of the DRAFT couldn't
agree on what the right policy was, so they made sure
that no one would have an advantage by having the DRAFT
specificly match their policy. For example, Sun was doing
restricted Bell&LaPadula sensitivity. SGI did modified
Bell&LaPadula sensitivity and Biba integrity. Data General,
well, we were never sure what they were up to, but it
sure sounded like a reasonably pure Bell&LaPadula. In
the early days AT&T was pushing for time stamp sorts of
policy, too.

> Are you suggesting that POSIX.1e was
> not designed specifically for lattice-based models like
> BLP and Biba?

I'm suggesting that the design goals included supporting
those policies, but also included generality. No one
who came to more than one meeting advocated anything
other than policy independence.

> The fundamental statement of mandatory access
> control policy in the standard is hardly suitable for all
> mandatory security policies:  Subjects cannot cause information
> labeled at some MAC label L1 to become accessible to subjects
> at L2 unless L2 dominates L1.  You can't represent Type
> Enforcement by such a statement.  And the kind of label is
> implicit by the dominates relatinship.

I'll take your word for it that you couldn't represent
TE using the 1e scheme.

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

You're correct. If you really think it's valueable to
seperate left-hand-twiddle permission from write permission
the POSIX.1e scheme is not for you.


> ... - the
> point is that we need a flexible mandatory access control
> architecture so that the system can be customized and
> can evolve easily to meet different security requirements.

I have to disagree. It has not been the policy inflexibility
of MLS systems which have held them back, if in fact they
can be said to have been held back at all. It is the fact
that they're *different*. Flexible policy will not help in
the marketplace, it will hurt. We finally got people to the
point where they generally understood permission bits, when
along come NT ACLs, and the whole thing goes on the floor.
We'd be in much better shape if the MAC policies on MULTICS,
Solaris, HP/UX, AIX, and Irix where all the same. Flexibility?
Bad for the community.

-- 

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

[Robert Watson]

On Thu, 11 Jan 2001, Stephen Smalley wrote:

> On Thu, 11 Jan 2001, Christoph Hellwig wrote:
> 
> > > It is also quite different
> > > from POSIX.1e mandatory access controls, which are tied to a 
> > > specific kind of mandatory security policy.
> > 
> > Capabilities and mac are of course different, otherwise you probably
> > won't find them in the same posix standard...
> 
> I guess my antecedent was ambiguous.  I was trying to say that the
> SELinux mandatory access controls are quite different from POSIX.1e
> mandatory access controls, because SELinux provides a flexible mandatory
> access control architecture that can support many different kinds of
> security policies while POSIX.1e is limited to a particular kind of
> security policy (multi-level security, and perhaps Biba integrity or
> other lattice-based models).  SELinux can support lattice-based models
> like multi-level security, but it can also support Type Enforcement,
> Role-Based Access Control, and other models.  So POSIX.1e MAC only does
> a subset of what SELinux does. 

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. 

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. 

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. 

Everyone has their own feelings on general access control frameworks and
policy mechanisms, but my feeling is that there are a number of
improvements that could be made to POSIX.1e to improve its usefulness with
regards to more arbitrary MAC policies.  This would include functions that
request an access control determination for a pair of labels and an
operation identifier, 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.  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.  In addition, a way to determine what
components of the label are available, and properties of the policy
enforcement environment. 

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.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services





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