MCS/Targeted Policy...

MCS/Targeted Policy...

[Daniel J Walsh]

We at Red Hat are working on a new type of Policy called MCS.  (Multiple 
Category Security)

A quick overview from James Morris..

>It's essentially a scheme where we take MLS and:
> - Ignore sensitivity levels
> - Allow users discretionary control over categories
> - Remove BLP constraints
>
>This is intended as a user-oriented extension to SELinux where DAC and TE 
>are able to be further restricted by user assigned categories of the 
>user's choosing e.g. "Company Confidential" or "Salary Information"
>
>Part of the idea is to make more general use of the MLS infrastructure and 
>to try and enhance community traction.
>
We will describe it more in the future. 

We would like to role this out in FC5, along with some other changes.  
The biggest problem with it is upgrade.
We are turning on the fourth field (MLS) field of the security context, 
but files on disk don't have this field now.
So we want to avoid a complete relabel, on upgrade.  We would like to 
have the kernel default all files to an MLS
field of s0.  Some discussion of this has happened offline. And we are 
looking for a way to do this without adding
a new field/type to the policy and requiring we rev the policy version.  
One suggestion is that the kernel use the
initial_sids_file, and the "sid file" record.

sid file        system_u:object_r:file_t:s0

The kernel could use this to default any missing field to the value from 
this record.

- 



--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[Casey Schaufler]

--- Daniel J Walsh <dwalsh@redhat.com> wrote:

> We at Red Hat are working on a new type of Policy
> called MCS.  (Multiple 
> Category Security)
> 
> A quick overview from James Morris..
> 
> >It's essentially a scheme where we take MLS and:
> > - Ignore sensitivity levels
> > - Allow users discretionary control over
> categories
> > - Remove BLP constraints

I expect that you're going to have an
uphill battle explaining how this is
superior to ACLs.

> >This is intended as a user-oriented extension to
> SELinux where DAC and TE 
> >are able to be further restricted by user assigned
> categories of the 
> >user's choosing e.g. "Company Confidential" or
> "Salary Information"

Which is what ACLs are for.

> >Part of the idea is to make more general use of the
> MLS infrastructure and 
> >to try and enhance community traction.

MLS is really good for strong seperation of
communities, either heirarchicaly or categoricly.
ACLs are really good for finer general use.

The notion of descretionary mandatory controls
has been around for a long time. I suggest that
a good inplementation of DAC give you all the
power of DMAC without the extra cost.

Yes, it is tempting to go looking for nails
when you have a shiney new hammer, especially
if the neighbours are laughing at you for
spending money on it. Resist the temptation.
If ACLs aren't doing what you want, what is
their shortcoming?

> We will describe it more in the future. 

Ok...

> We would like to role this out in FC5, along with
> some other changes.  
> The biggest problem with it is upgrade.
> We are turning on the fourth field (MLS) field of
> the security context, 
> but files on disk don't have this field now.
> So we want to avoid a complete relabel, on upgrade. 
> We would like to 
> have the kernel default all files to an MLS
> field of s0.

This could be a sticking point for MLS in
evaluations. Evaluators have been very clear
in the past that the only acceptable default
sensitivity label is one the is maximally
restrictive, e.g. SystemHigh. Of course, every
team is different, but this has been a very
consistant message in the past.

> Some discussion of this has happened
> offline. And we are 
> looking for a way to do this without adding
> a new field/type to the policy and requiring we rev
> the policy version.  
> One suggestion is that the kernel use the
> initial_sids_file, and the "sid file" record.
> 
> sid file        system_u:object_r:file_t:s0
> 
> The kernel could use this to default any missing
> field to the value from 
> this record.

You can always run this up the flagpole.
I suggest that the potential damage to the
MLS feature combined with the aforementioned
issues of DMAC weaken the argument for the
whole enterprise.

But, that's just me.



Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
 

--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[Daniel J Walsh]

Casey Schaufler wrote:

>--- Daniel J Walsh <dwalsh@redhat.com> wrote:
>
>  
>
>>We at Red Hat are working on a new type of Policy
>>called MCS.  (Multiple 
>>Category Security)
>>
>>A quick overview from James Morris..
>>
>>    
>>
>>>It's essentially a scheme where we take MLS and:
>>>- Ignore sensitivity levels
>>>- Allow users discretionary control over
>>>      
>>>
>>categories
>>    
>>
>>>- Remove BLP constraints
>>>      
>>>
>
>I expect that you're going to have an
>uphill battle explaining how this is
>superior to ACLs.
>  
>
I will let James answer this, since he is much better at it than I. 
One goal of this is to get us the testing of the MLS functionality with
out the headaches of full MLS.  So things like labeled printing and 
auditing
stuff can be used and tested in greater numbers.

>  
>
>>>This is intended as a user-oriented extension to
>>>      
>>>
>>SELinux where DAC and TE 
>>    
>>
>>>are able to be further restricted by user assigned
>>>      
>>>
>>categories of the 
>>    
>>
>>>user's choosing e.g. "Company Confidential" or
>>>      
>>>
>>"Salary Information"
>>    
>>
>
>Which is what ACLs are for.
>
>  
>
>>>Part of the idea is to make more general use of the
>>>      
>>>
>>MLS infrastructure and 
>>    
>>
>>>to try and enhance community traction.
>>>      
>>>
>
>MLS is really good for strong seperation of
>communities, either heirarchicaly or categoricly.
>ACLs are really good for finer general use.
>
>The notion of descretionary mandatory controls
>has been around for a long time. I suggest that
>a good inplementation of DAC give you all the
>power of DMAC without the extra cost.
>
>Yes, it is tempting to go looking for nails
>when you have a shiney new hammer, especially
>if the neighbours are laughing at you for
>spending money on it. Resist the temptation.
>If ACLs aren't doing what you want, what is
>their shortcoming?
>  
>

>>We will describe it more in the future. 
>>    
>>
>
>Ok...
>
>  
>
>>We would like to role this out in FC5, along with
>>some other changes.  
>>The biggest problem with it is upgrade.
>>We are turning on the fourth field (MLS) field of
>>the security context, 
>>but files on disk don't have this field now.
>>So we want to avoid a complete relabel, on upgrade. 
>>We would like to 
>>have the kernel default all files to an MLS
>>field of s0.
>>    
>>
>
>This could be a sticking point for MLS in
>evaluations. Evaluators have been very clear
>in the past that the only acceptable default
>sensitivity label is one the is maximally
>restrictive, e.g. SystemHigh. Of course, every
>team is different, but this has been a very
>consistant message in the past.
>
>  
>
>>Some discussion of this has happened
>>offline. And we are 
>>looking for a way to do this without adding
>>a new field/type to the policy and requiring we rev
>>the policy version.  
>>One suggestion is that the kernel use the
>>initial_sids_file, and the "sid file" record.
>>
>>sid file        system_u:object_r:file_t:s0
>>
>>The kernel could use this to default any missing
>>field to the value from 
>>this record.
>>    
>>
>
>You can always run this up the flagpole.
>I suggest that the potential damage to the
>MLS feature combined with the aforementioned
>issues of DMAC weaken the argument for the
>whole enterprise.
>
>  
>
Maybe unlabled is a better choice

sid unlabeled   system_u:object_r:unlabeled_t:s9:c0.c127
For MLS.

sid unlabeled   system_u:object_r:unlabeled_t:s0
For MCS

>But, that's just me.
>
>
>
>Casey Schaufler
>casey@schaufler-ca.com
>
>
>		
>____________________________________________________
>Start your day with Yahoo! - make it your home page
>http://www.yahoo.com/r/hs
> 
>  
>


-- 



--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[Stephen Smalley]

On Wed, 2005-07-13 at 12:15 -0400, Daniel J Walsh wrote:
> Maybe unlabled is a better choice
> 
> sid unlabeled   system_u:object_r:unlabeled_t:s9:c0.c127
> For MLS.
> 
> sid unlabeled   system_u:object_r:unlabeled_t:s0
> For MCS

Doesn't matter, as long as it can be configured differently for the
evaluated MLS policy vs. the Fedora MCS policy.

The 'file' initial SID is presently used as the default file context for
files on filesystems that support security xattrs when the file lacks an
xattr value for SELinux (i.e. completely missing security context).
Hence, using the MLS value from that context is also quite reasonable
for files that have an xattr but lack any MLS value in the xattr; they
would need to be system high for MLS in both cases.

The 'unlabeled' initial SID is presently used as the initial state of
incore inodes when they are first allocated, prior to being associated
with an actual file, and for files in filesystems that have no
associated labeling scheme configured in the policy at all.  Invalidated
SIDs are also re-mapped to the unlabeled SID.  Hence, the unlabeled SID
will also likely have a system high level in a MLS policy.
  
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[James Morris]

On Wed, 13 Jul 2005, Casey Schaufler wrote:

> I expect that you're going to have an
> uphill battle explaining how this is
> superior to ACLs.

I would not claim that MCS is superior to ACLs (whatever superior is 
supposed to mean).

MCS categories, as initially envisioned, are functionally similar to ACLs, 
but not equivalent.

There are some fundamental differences between the systems; here are some
very basic definitions:

- ACLs govern discretionary access rights to an object.
- MCS constrains DAC and TE access rights to an object.

ACLs impose a specific set of access rights (rwx) and semantics, which are
not necessarily appropriate to our needs. For example, TE provides a
richer set of permissions and security abstractions, which MCS can readily
constrain.  MCS can also operate on TE attributes.

ACL labeling semantics are fixed.  Examples:
- ACLs must be copied from a directory's default ACL list for files
  created in that directory.
- If a user has newgrp'd to a supplementary group, files created by the
  user will be created with that group.

We don't necessarily want these things to always happen, and in fact,
definitely don't under the initial model.  MCS labeling semantics could be
more flexible, if required, via policy specification and/or changes in fs
labeling behavior.

ACLs are limited to a small set of file type OS objects.  MCS could be
applied to any of the objects which SELinux controls, including userspace
components.  Down the track, MCS could be useful for things like Security
Enhanced X and Postgresql.  MCS seems to provide far more extensibility
and scope as an SELinu-based technology.

MCS may not always be as simple DAC mechanism.  This is how it is
initially envisioned, but via SELinux policy, its behavior can be changed.

Note that MCS is merely a simplified MLS policy (but should not be
considered in any way to actually be MLS of course: I'm referring to the
technology base).  It is essentially a filesystem relabel and a policy
change which makes use of existing or planned MLS components.

MCS would be more closely integrated with both SELinux and CAPP audit,
and better leverage existing technologies and efforts in these areas.

An ACL failure, by default, will not be audited.  An MCS failure will be
audited as an SELinux denial, which will contain important security
information, such as security contexts containing category labels.
Auditing can be further enhanced if necessary with auditallow rules, and
ultimately, enabling auditd.  Adding an audit rule for ACL controlled
operations is not as useful: neither the object's ACL nor the subject's
supplementary groups are included in audit records.

If ACLs were to be considered as an alternative to MCS, setting aside the 
relative inflexibility, reduced integration with CAPP/SELinux and fixed 
semantics as discussed above, there are still issues such as:

- ACL functionality needs to be mapped to basic MCS functionality. e.g.
  higher level tools than get/setfacl would be needed ensure that the
  effective rights mask is set correctly and that 'rwx' is always set.
  It's simpler just to use MCS directly.

- What happens if SELinux is disabled on the system? ACLs will still be in 
  effect, and security could be seriously degraded without TE in place, as 
  ACLs are a privilege escalation mechanism.  In the case of MCS, the 
  category labels would do nothing without SELinux enabled.

- Re-using ACLs for this purpose may also clash with other uses of ACLs 
  and Unix groups on the same system.  We'd be kind of hijacking ACLs.


-- 
James Morris
<jmorris@redhat.com>




--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[Casey Schaufler]

--- James Morris <jmorris@redhat.com> wrote:

> On Wed, 13 Jul 2005, Casey Schaufler wrote:
> 
> > I expect that you're going to have an
> > uphill battle explaining how this is
> > superior to ACLs.
> 
> I would not claim that MCS is superior to ACLs
> (whatever superior is 
> supposed to mean).

In this context I would suggest that superior
means that if Linux were only going to support
one general purpose DAC mechanism it would
be the superior one.

> MCS categories, as initially envisioned, are
> functionally similar to ACLs, 
> but not equivalent.

Yes, I can see that. They are based on
attributes other than user id and group
membership.

> There are some fundamental differences between the
> systems; here are some
> very basic definitions:
> 
> - ACLs govern discretionary access rights to an
> object.
> - MCS constrains DAC and TE access rights to an
> object.

Discretionary Type Enforcement? Is that
really what you want to propose?

> ACLs impose a specific set of access rights (rwx)
> and semantics, which are
> not necessarily appropriate to our needs.

POSIX ACLs are carefully designed to allow
for extension beyond rwx. While existing
implementations may not make this obvious,
the spec has no restrictions.

> For example, TE provides a
> richer set of permissions and security
> abstractions,

Perhaps not the adjective I'd have chosen,
but fundamentally true...

> which MCS can readily constrain.

Right. I get that. Given the richness
of the SELinux policy scheme it seems
there could be the opportunity here to
add just a little bit more flavor to
the soup.

> MCS can also operate on TE attributes.

Giving users descretionary control over
TE attributes seems counter to the "SELinux
is a MAC scheme" position I've heard
fairly regularly, but it is a logical
extension.

> ACL labeling semantics are fixed.  Examples:
> - ACLs must be copied from a directory's default ACL
> list for files
>   created in that directory.

Well yeah. It's nice to know how the facility
is going to work in advance!

> - If a user has newgrp'd to a supplementary group,
> files created by the
>   user will be created with that group.

File system semantics permitting. Again, I
feel secure when I know what's going to happen!

> We don't necessarily want these things to always
> happen, and in fact,
> definitely don't under the initial model.

OKay. Gosh, it would have helped to have
you around when we were doing the initial
work on LSM. Maybe we could have gotten
authoritative hooks in.

> MCS labeling semantics could be
> more flexible, if required, via policy
> specification and/or changes in fs
> labeling behavior.

Of course. On the other hand, you could
throw out all OS based access control and
leave it to the applications to work out.
That would be flexible, too.

> ACLs are limited to a small set of file type OS
> objects.  MCS could be
> applied to any of the objects which SELinux
> controls, including userspace
> components.

ACLs on sockets have been done in the past,
you know, just as has MLS.

> Down the track, MCS could be useful for
> things like Security
> Enhanced X and Postgresql.

The problem with network service applications
is the transmission of attributes, not the
implementation of policy upon the attributes.
MCS will be no more or less useful to these
environments than the existing TE scheme or
a good B&L.

> MCS seems to provide far
> more extensibility
> and scope as an SELinu-based technology.

Yes, it does seem a somewhat obvious
branch to the TE mindset.

> MCS may not always be as simple DAC mechanism.  This
> is how it is
> initially envisioned, but via SELinux policy, its
> behavior can be changed.

Yeah. Additional sophistication.

> Note that MCS is merely a simplified MLS policy (but
> should not be
> considered in any way to actually be MLS of course:
> I'm referring to the
> technology base).  It is essentially a filesystem
> relabel and a policy
> change which makes use of existing or planned MLS
> components.

Yes, I can see that. While it may help
exercise some of the code paths, don't
think that it will help you understand
MLS. As Mr. Smalley will not doubt attest,
MAC has a whole different set of issues.

> MCS would be more closely integrated with both
> SELinux and CAPP audit,
> and better leverage existing technologies and
> efforts in these areas.

Which still won't help with a mode bit failure.

> An ACL failure, by default, will not be audited.

It would be on all the audit systems I ever
worked on!

> An MCS failure will be
> audited as an SELinux denial, which will contain
> important security
> information, such as security contexts containing
> category labels.

That's good.

> Auditing can be further enhanced if necessary with
> auditallow rules, and
> ultimately, enabling auditd.  Adding an audit rule
> for ACL controlled
> operations is not as useful: neither the object's
> ACL nor the subject's
> supplementary groups are included in audit records.

That's a bug in the audit system, not
a flaw in ACLs.

> If ACLs were to be considered as an alternative to
> MCS, setting aside the 
> relative inflexibility, reduced integration with
> CAPP/SELinux and fixed 
> semantics as discussed above, there are still issues
> such as:
> 
> - ACL functionality needs to be mapped to basic MCS
> functionality. e.g.
>   higher level tools than get/setfacl would be
> needed ensure that the
>   effective rights mask is set correctly and that
> 'rwx' is always set.

ANy time you have two ways to do the same
thing each camp can come up with scenarios
that are easier using their mechanism.

>   It's simpler just to use MCS directly.

If you understand the domains and privileges
involved and can be trusted to set your MCS
attributes appropriately, yes. There's a reason
that the traditional Unix policy is limited
in what the user is allowed to specify.

> - What happens if SELinux is disabled on the system?
> ACLs will still be in 
>   effect, and security could be seriously degraded
> without TE in place, as 
>   ACLs are a privilege escalation mechanism.

What! This you've got to explain.

> In the
> case of MCS, the 
>   category labels would do nothing without SELinux
> enabled.

Ah. The POSIX ACL group made sure that adding
an ACL to a file would not interfere with the
mode bits, nor encourage users to set them
"wide open" and count on the ACL alone.

Imagine a system with MCS. If everything
and everyone used MCS, all the mode bits
could be 777, and you might do that so they
would not interfere with the desired MCS
activity. Bring that up without SELinux.

> - Re-using ACLs for this purpose may also clash with
> other uses of ACLs 
>   and Unix groups on the same system.  We'd be kind
> of hijacking ACLs.

Well, enhancing is the positive way to put it.
And yes, you would have to convince the ACL
maintainers it's a good thing.

In review, MCS is a logical extension to
SELinux. I expect you'll have to put more
limits on its flexibility than you think.
I expect to enjoy watching the experiment.
 


Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[James Morris]

On Wed, 13 Jul 2005, Casey Schaufler wrote:

> > There are some fundamental differences between the
> > systems; here are some
> > very basic definitions:
> > 
> > - ACLs govern discretionary access rights to an
> > object.
> > - MCS constrains DAC and TE access rights to an
> > object.
> 
> Discretionary Type Enforcement? Is that
> really what you want to propose?

Not exactly.  The proposal is further discretionary restrictions on TE, to
provide end users with more direct control over their objects.

TE itself always remains a MAC system.

> > MCS can also operate on TE attributes.
> 
> Giving users descretionary control over
> TE attributes seems counter to the "SELinux
> is a MAC scheme" position I've heard
> fairly regularly, but it is a logical
> extension.

This does not necessarily mean user control over TE attributes, just that 
MCS policy constraints can directly reference TE attributes.

> > ACLs are limited to a small set of file type OS
> > objects.  MCS could be
> > applied to any of the objects which SELinux
> > controls, including userspace
> > components.
> 
> ACLs on sockets have been done in the past,
> you know, just as has MLS.

I'd be interested to know where was this done (especially a deployed 
product).

> > ACLs will still be in 
> >   effect, and security could be seriously degraded
> > without TE in place, as 
> >   ACLs are a privilege escalation mechanism.
> 
> What! This you've got to explain.

Ok, assume that ACLs have been used with TE to synthesize an MCS-like
security mechansim.  If TE is disabled (e.g. boot with selinux=0), the
ACLs will still be there, but without TE's containment, integrity control
etc. features.  The big difference with MCS is that it only further
constrains DAC and TE policy.  ACLs are permissive and assign access 
rights directly to objects.

> 
> > In the
> > case of MCS, the 
> >   category labels would do nothing without SELinux
> > enabled.
> 
> Ah. The POSIX ACL group made sure that adding
> an ACL to a file would not interfere with the
> mode bits, nor encourage users to set them
> "wide open" and count on the ACL alone.
> 
> Imagine a system with MCS. If everything
> and everyone used MCS, all the mode bits
> could be 777, and you might do that so they
> would not interfere with the desired MCS
> activity. Bring that up without SELinux.

I don't understand this: MCS only further restricts secuirty policy
implemnted via mode bits.  It cannot directly reduce the security of the
system with or without SELinux enabled.

> In review, MCS is a logical extension to
> SELinux. I expect you'll have to put more
> limits on its flexibility than you think.
> I expect to enjoy watching the experiment.

It is indeed still considered experimental.

Thanks for the input.


- James
-- 
James Morris
<jmorris@redhat.com>



--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[Casey Schaufler]

--- James Morris <jmorris@redhat.com> wrote:


> > ACLs on sockets have been done in the past,
> > you know, just as has MLS.
> 
> I'd be interested to know where was this done
> (especially a deployed 
> product).

Trusted Irix 4.0.1 through 6.2 had 'em,
and that included the B1 evaluated 4.0.5epl
release. Deployed in more places than I'm
legally allowed to know about. That system
used CIPSO (with CIPSO compliant vendor tag
types) to communicate uid, B&L sensitivity and
Biba integrity.

We dropped them in Trix 6.5 in favor of TSIG
SAMP. That turned out to be an error, it turns
out, as we did it to improve interoperability
with other vendors who had just decided that
interoperabilty was not in their best interests.
Eh, you live and learn.


> ACLs are permissive
> and assign access 
> rights directly to objects.

I'm sorry, I must to slow today. How are ACLs
permissive? An ACL is an explict statement of
who is allowed to access an object, and who is
not.


> > Imagine a system with MCS. If everything
> > and everyone used MCS, all the mode bits
> > could be 777, and you might do that so they
> > would not interfere with the desired MCS
> > activity. Bring that up without SELinux.
> 
> I don't understand this: MCS only further restricts
> secuirty policy
> implemnted via mode bits.  It cannot directly reduce
> the security of the
> system with or without SELinux enabled.

If a system runs with MCS, and the MCS notions
of "good DAC" are prefered to the "traditional
Unix DAC", the system could be run with all
files mod 777 and all DAC supplied by MCS. So
long as the system always runs with MCS you're
fine. If you ran the system with a kernel that
did not enforce MCS the consequences could be
dire. In all, I would not expect that to happen
often, but it could.

> Thanks for the input.

No problem.



Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[James Morris]

On Thu, 14 Jul 2005, Casey Schaufler wrote:

> > ACLs are permissive
> > and assign access 
> > rights directly to objects.
> 
> I'm sorry, I must to slow today. How are ACLs
> permissive? An ACL is an explict statement of
> who is allowed to access an object, and who is
> not.

They're permissive in comparison with MCS, which does not permit any 
further access to objects.


- James
-- 
James Morris
<jmorris@redhat.com>



--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[Casey Schaufler]

--- James Morris <jmorris@redhat.com> wrote:


> They're permissive in comparison with MCS, which
> does not permit any 
> further access to objects.

I'm sorry. I give up. I do not understand
what you're trying to tell me. I'll have to
buy you a beer sometime and have you explain
real slow like. Thanks for the effort.



Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[Daniel J Walsh]

Casey Schaufler wrote:

>--- James Morris <jmorris@redhat.com> wrote:
>
>
>  
>
>>They're permissive in comparison with MCS, which
>>does not permit any 
>>further access to objects.
>>    
>>
>
>I'm sorry. I give up. I do not understand
>what you're trying to tell me. I'll have to
>buy you a beer sometime and have you explain
>real slow like. Thanks for the effort.
>
>
>  
>
Let me try.  SELinux does not give any more access then standard DAC 
Controls.  So I would say SELinux is only restrictive  on top of 
Standard DAC.  ACL, however grant additional access over standard DAC, 
so they are permissive
on standard DAC.

>Casey Schaufler
>casey@schaufler-ca.com
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>  
>


-- 



--
This message was distributed to subscribers of the selinux mailing 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: MCS/Targeted Policy...

[Casey Schaufler]

--- Daniel J Walsh <dwalsh@redhat.com> wrote:

> Let me try.  SELinux does not give any more access
> then standard DAC 
> Controls.  So I would say SELinux is only
> restrictive  on top of 
> Standard DAC.

Yes, and therein lies a potential problem.
The reason that ACLs are integrated with mode
bits is that DAC -as a whole- needs to be
sensible. If someone decides that SELinux DAC
is better than Unix DAC (somebody will) they
may chose to eschew Unix DAC and make all their
files mode 777 (rwxrwxrwx to those born after
the epoch), counting on the presence of SELinux
to protect them they way they want to be
protected. There is no problem unless there is
a change to the SELinux DAC policy and that
policy is sufficient to meet their needs.

Boot a kernel without SELinux, or with a
different policy and you have a problem.

> ACL, however grant additional access
> over standard DAC, 
> so they are permissive
> on standard DAC.

I don't think you've read the POSIX Draft.
ACLs are intergrated with mode bits. If you
use chmod to set the mode bits the desired
result occurs. The spec is very careful
about that. The statement that ACLs grant
additional access makes no sense to me
whatever, unless you're refering to the
improved granularity of specification.




Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
This message was distributed to subscribers of the selinux mailing 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.