SELinux policy discussion.

SELinux policy discussion.

[Daniel J Walsh]

Ivan Gyurdiev (ivg2@cornell.edu) Has reported a bug that several files 
in /etc/ are world readable and yet SELinux is
preventing them from being read.  Should we add usercanread attribute to 
most of these files (/etc/exports, /etc/yp.servers) ?
Any file in /etc/ that has a security_context other than etc_t and 
doesn't have an attribute of usercanread, is a problem.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129584


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.

Re: SELinux policy discussion.

[Colin Walters]

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

On Wed, 2004-09-15 at 16:03 -0400, Daniel J Walsh wrote:
> Ivan Gyurdiev (ivg2@cornell.edu) Has reported a bug that several files 
> in /etc/ are world readable and yet SELinux is
> preventing them from being read.  Should we add usercanread attribute to 
> most of these files (/etc/exports, /etc/yp.servers) ?
> Any file in /etc/ that has a security_context other than etc_t and 
> doesn't have an attribute of usercanread, is a problem.

I disagree that every file that allows user access via Unix permissions
should have the corresponding MAC permissions as well.  If you use the
strict policy it should be as close to least privilege as possible.
Normal users don't just randomly cat files in /etc.

If a case can be made for a particular file (perhaps some user program
parses /etc/exports and displays a list of mount options or something),
then we can add it to usercanread.

It's also a lot easier for users to add custom permissions than to
remove them.  Just drop the files you want added in
domains/misc/local.te, and that will persist even through policy-sources
upgrades.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: SELinux policy discussion.

[Colin Walters]

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

On Wed, 2004-09-15 at 22:43 -0400, Ivan Gyurdiev wrote:

> What you have right now is not least privilege possible.
> This is the point where my computer is broken and does not work.

You need to point out specific things that are broken.

> > Normal users don't just randomly cat files in /etc.
> 
> So what exactly is the definition of a SElinux MAC system?
> Is it a system which allows only what "normal users do",
> and how exactly do you figure out what that is? 

There are no hard and fast rules, but I am quite sure that no one's end
goal is "cat random file in /etc".  Instead, you cat a file to achieve
something else.  That something else is what is interesting.

> If there is a general consensus that a user has no job 
> reading a particular file in /etc, why is it still created/installed as
> world readable. 

One reason is because (at least before ACLs) it's complicated to
restrict access to only mildly sensitive files that are shared across
multiple daemon uids that a user doesn't really need read access to.

> Why don't you implement the MAC at the permissions level
> and make SElinux respect that?

That doesn't make any sense, if the MAC system respected DAC permissions
it wouldn't be MAC.

> So if a case can be made you'll change the SElinux context to respect
> the Unix permissions? 

No.  What we were discussing here is for a user to read a particular
file in /etc.  Even if the file is world readable, that doesn't mean
that access to it would be granted for all SELinux domains.  Someone may
deliberately create a domain that has no access to etc_t.  A good reason
to do this would be for a secured chroot setup.  

What we would do is grant user_t and staff_t permissions for the file.

> If a case can't be made, why don't you change the
> Unix permissions (in the rpm or whatever creates the file) instead of
> adding restrictions on the SELinux level? 

Because it may be very annoying to do some of this using Unix
permissions, and generally not worth the trouble.

> If I added the permissions 
> manually, doesn't that indicate I definitely want to be able to read the
> file? Seems to me like "usercanread" and rwx bits provide duplicate
> functionality, and furthermore contradict each other.

No, not at all.  To make this discussion a bit more concrete, suppose
that in the strict policy your sendmail daemon (which runs as root) is
compromised.  The compromised daemon can set all the bits on files
in /etc it wants with just Unix permissions.  But with SELinux, even if
it had permission to make /etc/shadow a+r, other domains wouldn't have
access to it.

SELinux and Unix permissions are quite separate for good reason.

> Look, I don't really know how to use SELinux. I have a general idea 
> of how it works, and I've looked at the policy files. 
> I don't want to drop files anywhere when there's already a mechanism
> that deals with whether I can read or write files - Unix permissions. 

What you really seem to be saying is that your system doesn't need
mandatory access control for users.  If so, use the targeted policy,
which leaves users in unconfined_t, with no SELinux restrictions
applied.

> You can claim that because I don't know how to use SELinux

I would never said that..  Heck, I'm still learning how to use SELinux
best myself and I've been at it for over a year now.

>  I shouldn't
> be using it and override Unix permissions for my own good... or you 
> can make this process transparent for me and respect existing
> mechanisms.
>
> Why can't the strict policy be transparent for the end user ?

I think you just want the targeted policy.

> Do you not see value in that? Is the restriction imposed on what user_t
> can do the defining feature of the strict policy? 

No, but it is a very core feature.

> I wanted to use strict
> policy because it's more comprehensive (more contexts - more
> separation), 

Do you have a particular daemon you feel should be in the strict policy?




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: SELinux policy discussion.

[Colin Walters]

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

On Thu, 2004-09-16 at 00:05 -0400, Colin Walters wrote:

> Do you have a particular daemon you feel should be in the strict policy?

I mean the targeted policy, obviously.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: SELinux policy discussion.

[Daniel J Walsh]

Colin Walters wrote:

>On Thu, 2004-09-16 at 00:05 -0400, Colin Walters wrote:
>
>  
>
>>Do you have a particular daemon you feel should be in the strict policy?
>>    
>>
>
>I mean the targeted policy, obviously.
>
>  
>
If we added a tunable to allow users to read all sysadmfile files we 
would get somewhere between
strict policy and targeted.

bool user_read_adminfile false;

if (user_read_adminfiles) {
    r_dir_file($1_t, sysadmfile)
}


--
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: SELinux policy discussion.

[Stephen Smalley]

On Thu, 2004-09-16 at 08:25, Daniel J Walsh wrote:
> If we added a tunable to allow users to read all sysadmfile files we 
> would get somewhere between
> strict policy and targeted.
> 
> bool user_read_adminfile false;
> 
> if (user_read_adminfiles) {
>     r_dir_file($1_t, sysadmfile)
> }

Vetoed.  This is far worse than just adding usercanread attribute to
specific types that you want to allow to be read by untrusted user
domains.

The bugzilla comments seem to flow from a fundamental misunderstanding
of mandatory access control; suggest reading
http://www.nsa.gov/selinux/papers/inevit-abs.cfm and
http://www.nsa.gov/selinux/papers/freenix01-abs.cfm.

If you don't want such protection, then use the targeted policy or
disable SELinux.  Don't water down the strict policy any further please,
it should be moving in the opposite direction.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: SELinux policy discussion.

[Colin Walters]

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

On Thu, 2004-09-16 at 03:07 -0400, Ivan Gyurdiev wrote:
> > > > Normal users don't just randomly cat files in /etc.
> > > 
> > > So what exactly is the definition of a SElinux MAC system?
> > > Is it a system which allows only what "normal users do",
> > > and how exactly do you figure out what that is? 
> > 
> > There are no hard and fast rules, but I am quite sure that no one's end
> > goal is "cat random file in /etc".  Instead, you cat a file to achieve
> > something else.  That something else is what is interesting.
> 
> My point is, I don't think you can determine all the possible ways in
> which a user may take advantage of read access, previously available,
> and now no longer there. 

Of course we can't.  But what we can do is consider individual requests
for greater access, and add that on a case-by-case basis.

> Perhaps the user has custom scripts or
> applications that are not selinux-aware at this point and now they'll
> stop working. 

Custom scripts to do *what*?  You need to point out specific things that
would be broken.  Actual examples of real-world code.

> Perhaps the user does want to cat a random file from the
> shell to view its contents (config files?). 

This is just a more complicated way of saying "cat random file in /etc".
I'm not convinced.

> That worked before and now it no longer works. 

A lot of things don't work with SELinux that used to work before,
like /tmp races.  It's not a bug.

> While you can establish exactly what the requirements of an application
> are and write a policy for it, I'm not sure you can establish exactly
> what the requirements of user_t are. There's a whole range of things
> user_t could decide to do. That's why it seems to me that the policy to
> adhere to when it comes to user_t should be compatible with Unix
> permissions.

I completely disagree.  The strict policy is always going to be more
restrictive than Unix permissions for users.  That's the point of it.
If you don't want that, use the targeted policy.

> That's exactly what I was arguing for... DAC permissions for user_t,
> strict MAC policy for other domains. DAC permissions for all domains
> would make no sense at all since it defeat the whole purpose of SELinux.

See above.

> > I think you just want the targeted policy.
> 
> But the strict policy covers more programs.
> It won't let a firefox buffer overflow cause damage to the rest of my
> files (will it?). 

The strict policy helps there.  But we still have a long ways to go to
lock down X.  

If you want a restricted mozilla domain, and allow users to read random
files in /etc, use the strict policy and add a bit of custom policy to
your site to allow users to read those files you want.  The latter isn't
something that should be in the default strict policy.  But SELinux is
flexible enough to allow what you want.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: SELinux policy discussion.

[Ivan Gyurdiev]

> > While you can establish exactly what the requirements of an application
> > are and write a policy for it, I'm not sure you can establish exactly
> > what the requirements of user_t are. There's a whole range of things
> > user_t could decide to do. That's why it seems to me that the policy to
> > adhere to when it comes to user_t should be compatible with Unix
> > permissions.
> 
> I completely disagree.  The strict policy is always going to be more
> restrictive than Unix permissions for users.  That's the point of it.
> If you don't want that, use the targeted policy.

I guess that's my mistake. I thought the purpose of the strict policy 
was not to additionally restrict the behavior of the user, but to take
away privileges that applications do not use (when operating properly),
therefore do not need. 

What I want from MAC is to restrict my applications while preserving
100% useful functionality and being transparent. I don't want more
restrictions on my behavior. I don't want to be told that I can't use 
mozilla as a file browser, because it's supposed to be a web browser.
I don't want mozilla_readhome and mozilla_writehome that are false by 
default so I can't save a web page to my home folder. In other words I
don't necessarily like the "deny by default" policy on what I can do - I
only want that to apply to individual programs. Maybe that's what
Stephen Smalley means by "fundamental misunderstanding of mandatory
access control" - I'll have to finish reading that paper to see.


-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: SELinux policy discussion.

[Daniel J Walsh]

Colin Walters wrote:

>On Thu, 2004-09-16 at 03:07 -0400, Ivan Gyurdiev wrote:
>  
>
>>>>>Normal users don't just randomly cat files in /etc.
>>>>>          
>>>>>
>>>>So what exactly is the definition of a SElinux MAC system?
>>>>Is it a system which allows only what "normal users do",
>>>>and how exactly do you figure out what that is? 
>>>>        
>>>>
>>>There are no hard and fast rules, but I am quite sure that no one's end
>>>goal is "cat random file in /etc".  Instead, you cat a file to achieve
>>>something else.  That something else is what is interesting.
>>>      
>>>
>>My point is, I don't think you can determine all the possible ways in
>>which a user may take advantage of read access, previously available,
>>and now no longer there. 
>>    
>>
>
>Of course we can't.  But what we can do is consider individual requests
>for greater access, and add that on a case-by-case basis.
>
>  
>
>>Perhaps the user has custom scripts or
>>applications that are not selinux-aware at this point and now they'll
>>stop working. 
>>    
>>
>
>Custom scripts to do *what*?  You need to point out specific things that
>would be broken.  Actual examples of real-world code.
>
>  
>
>>Perhaps the user does want to cat a random file from the
>>shell to view its contents (config files?). 
>>    
>>
>
>This is just a more complicated way of saying "cat random file in /etc".
>I'm not convinced.
>
>  
>
>>That worked before and now it no longer works. 
>>    
>>
>
>A lot of things don't work with SELinux that used to work before,
>like /tmp races.  It's not a bug.
>
>  
>
>>While you can establish exactly what the requirements of an application
>>are and write a policy for it, I'm not sure you can establish exactly
>>what the requirements of user_t are. There's a whole range of things
>>user_t could decide to do. That's why it seems to me that the policy to
>>adhere to when it comes to user_t should be compatible with Unix
>>permissions.
>>    
>>
>
>I completely disagree.  The strict policy is always going to be more
>restrictive than Unix permissions for users.  That's the point of it.
>If you don't want that, use the targeted policy.
>
>  
>
>>That's exactly what I was arguing for... DAC permissions for user_t,
>>strict MAC policy for other domains. DAC permissions for all domains
>>would make no sense at all since it defeat the whole purpose of SELinux.
>>    
>>
>
>See above.
>
>  
>
>>>I think you just want the targeted policy.
>>>      
>>>
>>But the strict policy covers more programs.
>>It won't let a firefox buffer overflow cause damage to the rest of my
>>files (will it?). 
>>    
>>
>
>The strict policy helps there.  But we still have a long ways to go to
>lock down X.  
>
>If you want a restricted mozilla domain, and allow users to read random
>files in /etc, use the strict policy and add a bit of custom policy to
>your site to allow users to read those files you want.  The latter isn't
>something that should be in the default strict policy.  But SELinux is
>flexible enough to allow what you want.
>
>
>  
>
One argument for allowing users to read most of these files, is we are 
forcing a user in strict
policy to run in a higher domain then he might otherwize.  IE if a user 
wants to regularly look
at files in /etc, he might decide to add admin privs to his user account 
and login as sysadm_r.

I tend to agree though that most users and users on a locked down box do 
not need to be reading these files.

Dan

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.

Re: SELinux policy discussion.

[Colin Walters]

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

On Thu, 2004-09-16 at 17:21 -0400, Daniel J Walsh wrote:

> One argument for allowing users to read most of these files, is we are 
> forcing a user in strict policy to run in a higher domain then he might 
> otherwize.  IE if a user wants to regularly look at files in /etc, 
> he might decide to add admin privs to his user account 
> and login as sysadm_r.

True, but no one has yet explained a reason why access to any of the
files being discussed would be needed if you weren't going to log in as
sysadm_r and *do* something with them anyways.




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: SELinux policy discussion.

[Luke Kenneth Casson Leighton]

On Thu, Sep 16, 2004 at 03:53:09PM -0400, Ivan Gyurdiev wrote:
 
> What I want from MAC is to restrict my applications while preserving
> 100% useful functionality and being transparent. I don't want more
> restrictions on my behavior. I don't want to be told that I can't use 

then for _your_ requirements, i believe that the targetted policy
suits your needs must better than the strict one.

targetted policy restricts services but leaves users pretty much
unrestricted.

but remember that unix permissions are checked first _followed_ by
selinux permissions if the unix perms happen to succeed (so if the
unix perms fail there's no need to run the selinux security module).

l.


--
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: SELinux policy discussion.

[Valdis.Kletnieks]

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

On Thu, 16 Sep 2004 15:53:09 EDT, Ivan Gyurdiev said:
> What I want from MAC is to restrict my applications while preserving
> 100% useful functionality and being transparent. I don't want more
> restrictions on my behavior.

The problem is defining "100% useful functionality" in a way that's compatible
with system security and integrity.  Remember that for the guy attacking the
system, being able to exploit a /tmp race is "useful functionality".
Conversely, there's a *lot* of crufty broken code out there that only works
because it abuses some corner-case quirk that really *should* be fixed.

> I don't want mozilla_readhome and mozilla_writehome that are false by 
> default so I can't save a web page to my home folder.

You'll sing a different tune if some hostile Javascript saves a .rhosts in your
home directory (or any other file that will produce surprising results).
There's a reason why FTP servers have for *ages* had an 'incoming' directory
for to sandbox inbound stuff till it's possible to hand-check inbound
content.  The only security-sane way to do this is to have a directory that
Mozilla *can* write to but which isn't trusted by anything else, requiring
the user to 'cp' or 'mv' the file out in order to do anything with it.

I don't see any problem with the concept that the 'strict' policy will make you
change the way you do things slightly, if the way you used to do things were
security-unwise procedures.  In fact, I welcome the idea - if the system
prohibits my users from doing stupid things, my job gets *easier*....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: SELinux policy discussion.

[Dax Kelson]

On Fri, 2004-09-17 at 11:19, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 16 Sep 2004 15:53:09 EDT, Ivan Gyurdiev said:
> > What I want from MAC is to restrict my applications while preserving
> > 100% useful functionality and being transparent. I don't want more
> > restrictions on my behavior.
> 
> The problem is defining "100% useful functionality" in a way that's compatible
> with system security and integrity.  Remember that for the guy attacking the
> system, being able to exploit a /tmp race is "useful functionality".
> Conversely, there's a *lot* of crufty broken code out there that only works
> because it abuses some corner-case quirk that really *should* be fixed.
> 
> > I don't want mozilla_readhome and mozilla_writehome that are false by 
> > default so I can't save a web page to my home folder.
> 
> You'll sing a different tune if some hostile Javascript saves a .rhosts in your
> home directory (or any other file that will produce surprising results).

Your point is valid, but the example is a bit dated.

On any Linux distro made in the past 2-3 years, and certainly all the
2.6 kernel based distros, creating a .rhosts or /etc/hosts.equiv file
will have zero effect.

The trusting of .rhosts/hosts.equiv is not turned on by default, and you
have to jump through some non-trivial hoops to get it enabled.

Dax Kelson
Guru Labs


--
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: SELinux policy discussion.

[Russell Coker]

On Sun, 19 Sep 2004 09:50, Dax Kelson <dax@gurulabs.com> wrote:
> > You'll sing a different tune if some hostile Javascript saves a .rhosts
> > in your home directory (or any other file that will produce surprising
> > results).
>
> Your point is valid, but the example is a bit dated.
>
> On any Linux distro made in the past 2-3 years, and certainly all the
> 2.6 kernel based distros, creating a .rhosts or /etc/hosts.equiv file
> will have zero effect.

So you do the same with ~/.ssh/authorized_keys .

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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