Removing DAC.

Removing DAC.

[cinthya aranguren]

[-- Attachment #1: Type: text/plain, Size: 196 bytes --]

Hi,

Is there any way to avoid o remove DAC controls ? I'd like to have only one
security scheme in my system. I mean a pure SElinux system. not DAC + MAC.
only MAC.

Thanks in advance.

Cinthya.

[-- Attachment #2: Type: text/html, Size: 226 bytes --]

Re: Removing DAC.

[Casey Schaufler]

--- cinthya aranguren <cinthya.aranguren@gmail.com> wrote:

> Hi,
> 
> Is there any way to avoid o remove DAC controls ? I'd like to have only one
> security scheme in my system. I mean a pure SElinux system. not DAC + MAC.
> only MAC.

No.

Well, not today.

The LSM, which is the interface that SELinux uses to plug into
the rest of the kernel is explicity designed to allow additional
restrictions but not replacement or override of existing
restrictions. In the early days of LSM both restrictive models,
like what we have today, and authoritiative models, which would
allow replacement of traditional DAC where considered. The
authoritative model was rejected based on how easy it would be
for proprietary modules that had nothing to do with security to
exploit the interface.

I am currently putting some work into separating the LSM into
a pair of interface sets, one for the privilege model and one
for the additional restrictions. Once in place it could be
possible to create a privilege scheme that reports to the 
traditional DAC that everyone has DAC override, and leave it
to SELinux (or whatever restrictive model you might prefer)
to make the only decision.

That work is not done, nor is there any assurance that it
might be accepted when it is. Since it would result in a
system where the privilege module and the access restriction
module could team up to provide an authoritative model
it is within reason that the arguments that blocked an
authoritative LSM could be raised again with the same result.

Now I'll ask the 37 cent question:

Why would you want to do that?



Casey Schaufler
casey@schaufler-ca.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: Removing DAC.

[Casey Schaufler]

--- Casey Schaufler <casey@schaufler-ca.com> wrote:

> 
> --- cinthya aranguren <cinthya.aranguren@gmail.com> wrote:
> 
> > Hi,
> > 
> > Is there any way to avoid o remove DAC controls ? I'd like to have only one
> > security scheme in my system. I mean a pure SElinux system. not DAC + MAC.
> > only MAC.
> 
> No.
> 
> Well, not today.

I will add that if every process runs with CAP_DAC_OVERRIDE set
you can approach "no DAC", but I think you would probably have
to dig very deeply into the behavior of security cognizant
applications (sendmail comes to mind) and make sure that they
aren't explictly dropping that capability. I will let those
who work more closely with SELinux policy than I do describe
how capabilities possessed are related to an SELinux policy
and how that might impact the behavior of SELinux. You should
also note that SELinux takes what are traditionally DAC
attributes into account when making decisions and that if you
use MCS you are using a DAC mechanism within SELinux. I'm not
saying that's bad, just that it's there.


Casey Schaufler
casey@schaufler-ca.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: Removing DAC.

[Russell Coker]

On Monday 24 March 2008 02:54, "cinthya aranguren" 
<cinthya.aranguren@gmail.com> wrote:
> Is there any way to avoid o remove DAC controls ? I'd like to have only one
> security scheme in my system. I mean a pure SElinux system. not DAC + MAC.
> only MAC.

Back in about 2003 as an experiment I changed the ownership of all files on a 
SE Linux strict system to root and changed the permission to 777.  It didn't 
work very well.  One problem was that many programs rely on the Unix 
permissions to identify the difference between a configuration file and a 
shell script.  In directories such as /etc there is not sufficiently 
fine-grained SE Linux labelling to replace this use of Unix permissions.

It's possible that in the last 5 years things have changed significantly, but 
my last experiments showed enough obstacles to make me not want to bother 
going further with it.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: Removing DAC.

[Joshua Brindle]

Russell Coker wrote:
> On Monday 24 March 2008 02:54, "cinthya aranguren" 
> <cinthya.aranguren@gmail.com> wrote:
>   
>> Is there any way to avoid o remove DAC controls ? I'd like to have only one
>> security scheme in my system. I mean a pure SElinux system. not DAC + MAC.
>> only MAC.
>>     
>
> Back in about 2003 as an experiment I changed the ownership of all files on a 
> SE Linux strict system to root and changed the permission to 777.  It didn't 
> work very well.  One problem was that many programs rely on the Unix 
>   

Right, that wouldn't work well because it would deteriorate, programs 
set umasks when making files, etc. Just ignoring the bits would probably 
work alot better :)

> permissions to identify the difference between a configuration file and a 
> shell script.  In directories such as /etc there is not sufficiently 
> fine-grained SE Linux labelling to replace this use of Unix permissions.
>
>   

Why does that matter? /etc is read only for the vast majority of 
processes and anything with passwords, etc in them should have their own 
labels.

> It's possible that in the last 5 years things have changed significantly, but 
> my last experiments showed enough obstacles to make me not want to bother 
> going further with it.
>
>   

we certainly have alot more types today, I'm not sure if that was the 
real obstacle though.


--
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: Removing DAC.

[Stephen Smalley]

On Sun, 2008-03-23 at 12:54 -0300, cinthya aranguren wrote:
> Hi,
> 
> Is there any way to avoid o remove DAC controls ? I'd like to have
> only one security scheme in my system. I mean a pure SElinux system.
> not DAC + MAC. only MAC.

Not recommended - see prior discussions on this list.

Russell Coker has run SELinux systems with published root password
before, which approximates the above, but only for demonstration
purposes - I wouldn't recommend that for production use.

If you really wanted to do it, you'd need to patch and build your own
kernel.  Options there include:
1) Drop out capabilities altogether - just remove the secondary_ops
calls from the SELinux module.  That makes SELinux always authoritative
on capable() calls.  In which case you better make sure that your policy
is configured very tightly.
2) Use the authoritative capabilities patch I posted last summer.  That
makes SELinux selectively authoritative on capable() calls when you add
new allow rules on the cap_override class, so it has no immediate impact
but you can gradually convert over to having SELinux grant capabilities.

-- 
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: Removing DAC.

[Russell Coker]

On Monday 24 March 2008 23:12, Joshua Brindle <method@manicmethod.com> wrote:
> we certainly have alot more types today, I'm not sure if that was the
> real obstacle though.

The real obstacle is bad design.

I don't think that there has ever been a time when it made sense to use the 
same file name for either a program or a plain text config file.

It might make some sense to try to execute /etc/daemon-config.sh and then 
read /etc/daemon-config if that fails (or the other way around).  Having a 
one-line config file which says "execute program X" would also make sense.

Using the same file name for both such that a horrible disaster is only a 
single chmod command away is just a bad idea.  I recall reading in a version 
of the Unix Horror stories about how someone accidentally made some C source 
code executable, and somehow when the C source in question was executed as a 
shell script it gave the same result as "rm -rf /".

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: Removing DAC.

[cinthya aranguren]

On Sun, Mar 23, 2008 at 2:25 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>
> --- cinthya aranguren <cinthya.aranguren@gmail.com> wrote:
>
> > Hi,
> >
> > Is there any way to avoid o remove DAC controls ? I'd like to have only one
> > security scheme in my system. I mean a pure SElinux system. not DAC + MAC.
> > only MAC.
>
> No.
>
> Well, not today.
>
> The LSM, which is the interface that SELinux uses to plug into
> the rest of the kernel is explicity designed to allow additional
> restrictions but not replacement or override of existing
> restrictions. In the early days of LSM both restrictive models,
> like what we have today, and authoritiative models, which would
> allow replacement of traditional DAC where considered. The
> authoritative model was rejected based on how easy it would be
> for proprietary modules that had nothing to do with security to
> exploit the interface.
>
> I am currently putting some work into separating the LSM into
> a pair of interface sets, one for the privilege model and one
> for the additional restrictions. Once in place it could be
> possible to create a privilege scheme that reports to the
> traditional DAC that everyone has DAC override, and leave it
> to SELinux (or whatever restrictive model you might prefer)
> to make the only decision.
>
> That work is not done, nor is there any assurance that it
> might be accepted when it is. Since it would result in a
> system where the privilege module and the access restriction
> module could team up to provide an authoritative model
> it is within reason that the arguments that blocked an
> authoritative LSM could be raised again with the same result.
>


Thanks for the reply...

Thats means it's imposible to separate DAC from MAC. There is no way
to have only one security scheme.


> Now I'll ask the 37 cent question:
>
> Why would you want to do that?
>
>

Just because i'm trying to simplify the security management of a linux
instalation. I'd like to use  MAC security, but i realize  this means
still have DAC. I can't get rid of this. I have to admin the DAC
burden plus MAC.
May be I'm thinking in a oversimplified reality.



>
> Casey Schaufler
> casey@schaufler-ca.com
>


Cinthya.

--
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: Removing DAC.

[cinthya aranguren]

On Sun, Mar 23, 2008 at 2:40 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>  --- Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>  >
>  > --- cinthya aranguren <cinthya.aranguren@gmail.com> wrote:
>  >
>  > > Hi,
>  > >
>  > > Is there any way to avoid o remove DAC controls ? I'd like to have only one
>  > > security scheme in my system. I mean a pure SElinux system. not DAC + MAC.
>  > > only MAC.
>  >
>  > No.
>  >
>  > Well, not today.
>
>  I will add that if every process runs with CAP_DAC_OVERRIDE set
>  you can approach "no DAC", but I think you would probably have
>  to dig very deeply into the behavior of security cognizant
>  applications (sendmail comes to mind) and make sure that they
>  aren't explictly dropping that capability. I will let those
>  who work more closely with SELinux policy than I do describe
>  how capabilities possessed are related to an SELinux policy
>  and how that might impact the behavior of SELinux. You should
>  also note that SELinux takes what are traditionally DAC
>  attributes into account when making decisions and that if you
>  use MCS you are using a DAC mechanism within SELinux. I'm not
>  saying that's bad, just that it's there.
>

This is a good point. I will experiment with CAP_DAC_OVERRIDE.
but .. why SELinux take DAC attributes into account when making
decisions ?? this does not violate the separation of "policy" from
"Enforcement" ??


>
>
>
>  Casey Schaufler
>  casey@schaufler-ca.com
>

Cinthya.

--
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: Removing DAC.

[Stephen Smalley]

On Mon, 2008-03-24 at 14:29 -0300, cinthya aranguren wrote:
> On Sun, Mar 23, 2008 at 2:40 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> >
> >  --- Casey Schaufler <casey@schaufler-ca.com> wrote:
> >
> >  >
> >  > --- cinthya aranguren <cinthya.aranguren@gmail.com> wrote:
> >  >
> >  > > Hi,
> >  > >
> >  > > Is there any way to avoid o remove DAC controls ? I'd like to have only one
> >  > > security scheme in my system. I mean a pure SElinux system. not DAC + MAC.
> >  > > only MAC.
> >  >
> >  > No.
> >  >
> >  > Well, not today.
> >
> >  I will add that if every process runs with CAP_DAC_OVERRIDE set
> >  you can approach "no DAC", but I think you would probably have
> >  to dig very deeply into the behavior of security cognizant
> >  applications (sendmail comes to mind) and make sure that they
> >  aren't explictly dropping that capability. I will let those
> >  who work more closely with SELinux policy than I do describe
> >  how capabilities possessed are related to an SELinux policy
> >  and how that might impact the behavior of SELinux. You should
> >  also note that SELinux takes what are traditionally DAC
> >  attributes into account when making decisions and that if you
> >  use MCS you are using a DAC mechanism within SELinux. I'm not
> >  saying that's bad, just that it's there.
> >
> 
> This is a good point. I will experiment with CAP_DAC_OVERRIDE.
> but .. why SELinux take DAC attributes into account when making
> decisions ?? this does not violate the separation of "policy" from
> "Enforcement" ??

SELinux does not use the DAC attributes (uid, gid, mode bits) as part of
its decision.

SELinux does however control the use of capabilities/privileges in
accordance with its policy.  And it does have a notion of user identity
in its security context, although that is separately managed and is
usually used just as a "role set" construct in modern SELinux (e.g.
staff_u authorized for staff_r and sysadm_r).

-- 
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: Removing DAC.

[cinthya aranguren]

On Sun, Mar 23, 2008 at 7:34 PM, Russell Coker <russell@coker.com.au> wrote:
> On Monday 24 March 2008 02:54, "cinthya aranguren"
>
> <cinthya.aranguren@gmail.com> wrote:
>
> > Is there any way to avoid o remove DAC controls ? I'd like to have only one
>  > security scheme in my system. I mean a pure SElinux system. not DAC + MAC.
>  > only MAC.
>
>  Back in about 2003 as an experiment I changed the ownership of all files on a
>  SE Linux strict system to root and changed the permission to 777.  It didn't
>  work very well.  One problem was that many programs rely on the Unix
>  permissions to identify the difference between a configuration file and a
>  shell script.  In directories such as /etc there is not sufficiently
>  fine-grained SE Linux labelling to replace this use of Unix permissions.


Ok, I understand. In a pure SELinux ditribution this would be fixed or
patched. It does not seems to be a problem. I mean .. a security
issue.



>
>  It's possible that in the last 5 years things have changed significantly, but
>  my last experiments showed enough obstacles to make me not want to bother
>  going further with it.
>

don't lost your faith :-)

>  --
>  russell@coker.com.au
>  http://etbe.coker.com.au/          My Blog
>
>  http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
>

Cinthya.

--
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: Removing DAC.

[Casey Schaufler]

--- cinthya aranguren <cinthya.aranguren@gmail.com> wrote:

> On Sun, Mar 23, 2008 at 2:25 PM, Casey Schaufler <casey@schaufler-ca.com>
> wrote:
> >
> >
> > --- cinthya aranguren <cinthya.aranguren@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Is there any way to avoid o remove DAC controls ? I'd like to have only
> one
> > > security scheme in my system. I mean a pure SElinux system. not DAC +
> MAC.
> > > only MAC.
> >
> > No.
> >
> > Well, not today.
> >
> > The LSM, which is the interface that SELinux uses to plug into
> > the rest of the kernel is explicity designed to allow additional
> > restrictions but not replacement or override of existing
> > restrictions. In the early days of LSM both restrictive models,
> > like what we have today, and authoritiative models, which would
> > allow replacement of traditional DAC where considered. The
> > authoritative model was rejected based on how easy it would be
> > for proprietary modules that had nothing to do with security to
> > exploit the interface.
> >
> > I am currently putting some work into separating the LSM into
> > a pair of interface sets, one for the privilege model and one
> > for the additional restrictions. Once in place it could be
> > possible to create a privilege scheme that reports to the
> > traditional DAC that everyone has DAC override, and leave it
> > to SELinux (or whatever restrictive model you might prefer)
> > to make the only decision.
> >
> > That work is not done, nor is there any assurance that it
> > might be accepted when it is. Since it would result in a
> > system where the privilege module and the access restriction
> > module could team up to provide an authoritative model
> > it is within reason that the arguments that blocked an
> > authoritative LSM could be raised again with the same result.
> >
> 
> 
> Thanks for the reply...
> 
> Thats means it's imposible to separate DAC from MAC. There is no way
> to have only one security scheme.

That's not quite correct. The problem is that DAC and MAC are separate
and the DAC is not optional, while MAC is optional. You can have only
one security scheme, so long as it is the traditional Linux DAC. You
can impose additional restrictions, such as SELinux or Smack, but you
cannot disregard the mode bits.

> > Now I'll ask the 37 cent question:
> >
> > Why would you want to do that?
> >
> 
> Just because i'm trying to simplify the security management of a linux
> instalation. I'd like to use MAC security,

What are you looking to accomplish by implementing MAC in your
environment? Personally, I don't think you are going to simplify
your security management with SELinux. If you want to simplify
you might think about Smack, which provides a MAC environment
that does not have the overhead of SELinux.

> but i realize  this means still have DAC. I can't get rid of this.

What aspects of the DAC configuration are a problem for you?
You may be able to set up a MAC configuration with Smack or
SELinux that meets your needs.

> I have to admin the DAC burden plus MAC.

Well, again that may depend on how it is that DAC is a burden in
the environment you've created.

> May be I'm thinking in a oversimplified reality.

One of the biggest problems with new security schemes has always
been dealing with programs and people that understand how to
deal with the old schemes and don't want to change. If you're
willing to share a little more about what would make your
set-up easier on you we (the Smack and SELinux teams) may be
able to make seriously helpfull suggestions.

Thank you


Casey Schaufler
casey@schaufler-ca.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: Removing DAC.

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> 

> > This is a good point. I will experiment with CAP_DAC_OVERRIDE.
> > but .. why SELinux take DAC attributes into account when making
> > decisions ?? this does not violate the separation of "policy" from
> > "Enforcement" ??
> 
> SELinux does not use the DAC attributes (uid, gid, mode bits) as part of
> its decision.

I stand corrected. Somehow I thought that uids came into the
equation, but I guess I was wrong.

> SELinux does however control the use of capabilities/privileges in
> accordance with its policy.  And it does have a notion of user identity
> in its security context, although that is separately managed and is
> usually used just as a "role set" construct in modern SELinux (e.g.
> staff_u authorized for staff_r and sysadm_r).

That's were I was confusing things, the security context uid being
a component of the policy that is maintained in addition to the
traditional uid. Thank you for the clarification.


Casey Schaufler
casey@schaufler-ca.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: Removing DAC.

[Russell Coker]

On Monday 24 March 2008 23:20, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Sun, 2008-03-23 at 12:54 -0300, cinthya aranguren wrote:
> > Hi,
> >
> > Is there any way to avoid o remove DAC controls ? I'd like to have
> > only one security scheme in my system. I mean a pure SElinux system.
> > not DAC + MAC. only MAC.
>
> Not recommended - see prior discussions on this list.
>
> Russell Coker has run SELinux systems with published root password
> before, which approximates the above, but only for demonstration
> purposes - I wouldn't recommend that for production use.

http://www.coker.com.au/selinux/play.html

I still run them now, and I also recommend that people don't do it.  From the 
above URL: Note that such machines require a lot of skill if you are to run 
them successfully. If you have to ask whether you should run one then the 
answer is "no".

In past discussions on this topic people have expressed the desire to avoid 
the overhead of Unix permission checks.  It seems obvious that a basic 
bit-mask check of two integers (Unix permission modes) is not going to incur 
any significant overhead, even when performed for every directory in the 
path.  The memory use of the code to check Unix permissions has never been 
measured (AFAIK) due to no-one getting a system to work without it and 
documenting the results.

I suspect that if someone was to get a Linux kernel to build without Unix 
permissions the majority of interest would not come from people who want SE 
Linux without Unix permissions but from people who want no access control at 
all.  When running an embedded device that only has a single program running 
the benefits for any form of access control are often minute (NB it seems 
that nowadays most embedded devices are complex enough to benefit 
significantly from SE Linux).

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

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