[Fwd: Re: Experiences with selinux enabled targetted on Fedora Core 3]

[Fwd: Re: Experiences with selinux enabled targetted on Fedora Core 3]

[Richard Hally]

-------- Original Message --------
Subject: 	Re: Experiences with selinux enabled targeted on Fedora Core 3
Date: 	Thu, 21 Apr 2005 00:37:07 -0400
From: 	Richard Hally <rhally@mindspring.com>
To: 	russell@coker.com.au
References: 	<20050221160539.6aba22bd.r.godzilla@comcast.net> 
<200504201621.46953.russell@coker.com.au> 
<42661F69.30102@mindspring.com> <200504210927.10015.russell@coker.com.au>



Russell Coker wrote:

>On Wednesday 20 April 2005 19:22, Richard Hally <rhally@mindspring.com> wrote:
>  
>
>>>Using dontaudit rules for such things also gives correct behavior in
>>>situations where relabelling will not.  As an example there is the
>>>following rule:
>>>dontaudit lvm_t file_t:dir search;
>>>
>>>Without this rule the lvm utilities when run before /var is mounted would
>>>create the /var/lock directory on the mount-point.  This is not desired
>>>functionality, the machine is in single-user mode at the time (so the lack
>>>of locking is not a problem) and creating directories that later get
>>>hidden by mounting a file system is not desirable.
>>>
>>>So far no-one has provided any reasons not to use dontaudit rules.
>>>Accusations of kludging don't count as a reason.
>>>
>>>I don't consider file_t labelling for a mount point as "mislabelling". 
>>>The mount point directory is expected to be hidden, so generally only
>>>mount needs to access it.
>>>      
>>>
>>I for one consider the use of "dontaudit" to be unethical but that is
>>just my opinion.
>>    
>>
>
>Why is it unethical to make software perform correctly even when it is not 
>written to?
>
>  
>
Because you(and other people) have not made an attempt to have the 
software changed to perform correctly!

>>Think about preventing someone's software from doing what was designed
>>and implemented to do. Shouldn't you at least notify the
>>developer/maintainer that there is a problem with their software? That
>>    
>>
>
>Yes, I do that.  I don't always notify them first.  The first priority is to 
>get the policy fixed, if I don't do it then someone else may do it and do it 
>badly (see this thread as an example).
>
>  
>
Apparently, there are many cases where notification has not taken place 
at all. The last I looked there were over 4100  dontaudit rules(in the 
strict policy) and that number is not decreasing.

>>seems to be the correct thing to do in the open source community.
>>If there is a actual security problem shouldn't there be some
>>notification of the vulnerability as a minimum? If it is not an actual
>>security vulnerability but perhaps a theoretical one, a proof of concept
>>is usually appropriate.
>>    
>>
>
>If it's a functionality issue such as creating a directory /var/lock on the 
>root file system when /var is a mount point then it's not such a big deal.
>
>  
>
In those cases(not necessarily this one) where it is no "big deal" then 
why  not "allow" rather than "dontaudit". In those cases where there 
isn't a good reason for not allowing something it should be allowed. If 
there is a good reason for not allowing something then there need to be 
changes made to the software.

>>If it is a violation of some generally accepted standard, isn't a
>>bugzilla the right thing to do?
>>    
>>
>
>Yes.  Of course there are other considerations.  Sometimes I already have some 
>open bug reports and don't feel inclined to make minor bug reports when more 
>serious bugs are open.
>
>  
>
>>If some action by the software is "uninteresting" shouldn't it be
>>allowed absent some reason that makes it in fact "interesting"?
>>    
>>
>
>Searching a directory of type file_t that is an empty mount point isn't 
>interesting.  If however a directory that shouldn't be accessed by the 
>program in question gets type file_t through file system corruption or other 
>errors then we do not want to allow such access.
>
>  
>
I think the use of the term "interesting" is just so much hand-waving. 
If there is file system corruption or other errors, the problem is 
elsewhere.

>>I would like to hear what others think of  this "dontaudit considered
>>harmful"  idea. I understand the use of dontaudit as a temporary
>>expedient but other than that it seem that there should be more done
>>about the situations where it is used at least in terms of notifying the
>>developers/maintainers of the software involved.
>>    
>>
>
>Why don't you go through the policy, remove a bunch of dontaudit rules and see 
>what happens.
>
>  
>
Perhaps you should change all the "dontaudit" rules to "allow" and see 
what happens.

The use of "dontaudit" implies that software is doing something that is 
should not be doing. In prohibiting the software from doing whatever 
that is _without attempting_ to have it corrected is where I find the 
current approach lacking.
Richard Hally
P.S. Russell, please do not think I am attacking you personally. I'm 
not. I am grateful for all your hard work on SELinux over the years.




--
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: [Fwd: Re: Experiences with selinux enabled targetted on Fedora Core 3]

[Stephen Smalley]

On Thu, 2005-04-21 at 05:42 -0400, Richard Hally wrote:
> Because you(and other people) have not made an attempt to have the 
> software changed to perform correctly!

In many cases, I think that they have (i.e. filed bugzilla reports,
introduced patches into the Fedora packages to avoid e.g. leaked file
descriptors, etc).

> Apparently, there are many cases where notification has not taken place 
> at all. The last I looked there were over 4100  dontaudit rules(in the 
> strict policy) and that number is not decreasing.

Notification doesn't mean that it will be immediately fixed upstream,
eh?  Or ever fixed until SELinux is more pervasive and until strict
policy is more pervasive.  If it only shows up with SELinux, and it only
shows up with strict policy, then most upstream package maintainers
aren't going to have a lot of motivation to change it right now.

> In those cases(not necessarily this one) where it is no "big deal" then 
> why  not "allow" rather than "dontaudit". In those cases where there 
> isn't a good reason for not allowing something it should be allowed. If 
> there is a good reason for not allowing something then there need to be 
> changes made to the software.

Principle of least privilege; if the program doesn't have a legitimate
need for the access, it should be denied.  Allowing "trivial" accesses
that aren't truly needed has an unfortunate way of allowing escalation
of access far beyond what you might expect from the individual "trivial"
accesses as independent units.  And yes, changing the software is
desirable, but we aren't in a position to dictate such changes; we can
only ask.  In the meantime, we _can_ deny the access until such a time
as the software is changed.

> Perhaps you should change all the "dontaudit" rules to "allow" and see 
> what happens.

Well, for one thing, a lot more programs would be able to directly
read /etc/shadow rather than having to use the chkpwd helper.

> The use of "dontaudit" implies that software is doing something that is 
> should not be doing. In prohibiting the software from doing whatever 
> that is _without attempting_ to have it corrected is where I find the 
> current approach lacking.

dontaudit implies that software is doing something in violation of
policy.  But policy is dependent on your particular security
requirements, and it is fairly safe to say that not all applications are
going to be written with your particular security requirements in mind.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: [Fwd: Re: Experiences with selinux enabled targetted on Fedora Core 3]

[Daniel J Walsh]

If someone is willing to read through the dontaudits and find the ones 
that are legitimate bugs versus,
Access to /etc/shaodow or daemons wanting to talk to the terminal on 
startup. 

Some are also very difficult to fix.  A low level kerberos library does 
a "access" check of all its config
files.  One of the checks is if (access(filename, W_OK))  this triggers 
an write denial, which we have
dontaudit for.  To change kerberos would envolve a serious redisign of 
lowlevel libraries.

Some are aguably running correctly just not the way SELinux wants them 
to.  IE Daemons having access to TTY's

Probably a lot of them are also legitimate bugs and should be 
bugzilla'd.  We can always use help if some one wants
to look for those situations.

Dan

-- 



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