SELinux and access(2), we want to know.

SELinux and access(2), we want to know.

[Eric Paris]

SELinux (and I assume all LSMs) have a bit of a problem with with the
access(2) call.  If a process calls access("/etc/shadow", R_OK) I claim
that we darn sure better return the same result that open("/etc/shadow",
O_RDONLY) would return.  I'm guessing noone is going to argue that
point.  Lets me also say this is only interesting if DAC allows a given
operation but MAC disallows it.  If DAC denies the request none of this
matters.

The only way to tell the right result for access() is for SELinux to
actually do the checks between (subject, file, read).  Again not a lot
of controversy here.

Lets say that the LSM does not allow read for the given subject
to /etc/shadow.  SELinux just denied an operation.  Today we log that a
process was just denied the ability to read /etc/shadow.  But the
process didn't actually try to read it.  If you surf with nautilus
to /etc it's going to call access() on everything to decide what kind of
little icons to put up there.  This could generate hundreds of SELinux
denials that nautilus tried to read everything in /etc.

What SELinux has to do today for programs like this is to not audit the
permission check (subject, file, read).  The problem here is that if the
program does act badly, and actually tries to read the file rather than
just call access() SELinux won't notify us, or report the denial in the
audit log.

I want/need a way for SELinux to know that a particular check can from
access() rather than from a truly misbehaving program.  That way I can
not send denial messages to the log if people just call access(2) but
will send a denial if the program does something illegal.  We had a long
discussion on the SELinux list about how we want to handle and log the
differences, but from the point of view of the VFS all that matters is
that we want to know when inode_permission is being called in access()
or from somewhere else.  The discussion was between not logging ANY
denials SELiunx causes from the access() call and being smarter about
only not logging those we really don't care about in a more fine grained
manor (I plan to go with fine grained version of not logging denials).
The philosophical question is really if there is (and I claim there is)
a difference between access() and open() and if we agree there is a
difference SELinux needs to know about it so logging those is different.

I propose 2 possible solutions.
1) a new VFS flag next to MAY_READ, MAY_WRITE and friends possibly
called "FROM_ACCESS" which we pass down to the LSM in faccessat during
the inode_permission call.

2) a new LSM hook.  security_inode_access_permission() which is called
from inode_permission() along with associated flags and such to
inode_permissions so the LSM knows where this call is coming from.

3) I've also heard it hinted that we could do this with audit by just
having audit drop the denials that include the access(2) syscall and the
scontext and tcontext for the slew of things the SELinux policy writers
know we are not interested in.  And while it seems good, now we have
SELinux 'policy' in places other than the policy, harder to distribute,
and it requires that everyone who turns on SELinux also turns on syscall
auditing with its associated overhead.

Obviously I think the right thing to decide if an LSM wants to send a
denial message or not is the LSM.  The only problem I have is that the
LSM doesn't know today when it is getting different types or requests
and so can't make that decision.

-Eric


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

SELinux and access(2), we want to know.

[Eric Paris]

SELinux (and I assume all LSMs) have a bit of a problem with with the
access(2) call.  If a process calls access("/etc/shadow", R_OK) I claim
that we darn sure better return the same result that open("/etc/shadow",
O_RDONLY) would return.  I'm guessing noone is going to argue that
point.  Lets me also say this is only interesting if DAC allows a given
operation but MAC disallows it.  If DAC denies the request none of this
matters.

The only way to tell the right result for access() is for SELinux to
actually do the checks between (subject, file, read).  Again not a lot
of controversy here.

Lets say that the LSM does not allow read for the given subject
to /etc/shadow.  SELinux just denied an operation.  Today we log that a
process was just denied the ability to read /etc/shadow.  But the
process didn't actually try to read it.  If you surf with nautilus
to /etc it's going to call access() on everything to decide what kind of
little icons to put up there.  This could generate hundreds of SELinux
denials that nautilus tried to read everything in /etc.

What SELinux has to do today for programs like this is to not audit the
permission check (subject, file, read).  The problem here is that if the
program does act badly, and actually tries to read the file rather than
just call access() SELinux won't notify us, or report the denial in the
audit log.

I want/need a way for SELinux to know that a particular check can from
access() rather than from a truly misbehaving program.  That way I can
not send denial messages to the log if people just call access(2) but
will send a denial if the program does something illegal.  We had a long
discussion on the SELinux list about how we want to handle and log the
differences, but from the point of view of the VFS all that matters is
that we want to know when inode_permission is being called in access()
or from somewhere else.  The discussion was between not logging ANY
denials SELiunx causes from the access() call and being smarter about
only not logging those we really don't care about in a more fine grained
manor (I plan to go with fine grained version of not logging denials).
The philosophical question is really if there is (and I claim there is)
a difference between access() and open() and if we agree there is a
difference SELinux needs to know about it so logging those is different.

I propose 2 possible solutions.
1) a new VFS flag next to MAY_READ, MAY_WRITE and friends possibly
called "FROM_ACCESS" which we pass down to the LSM in faccessat during
the inode_permission call.

2) a new LSM hook.  security_inode_access_permission() which is called
from inode_permission() along with associated flags and such to
inode_permissions so the LSM knows where this call is coming from.

3) I've also heard it hinted that we could do this with audit by just
having audit drop the denials that include the access(2) syscall and the
scontext and tcontext for the slew of things the SELinux policy writers
know we are not interested in.  And while it seems good, now we have
SELinux 'policy' in places other than the policy, harder to distribute,
and it requires that everyone who turns on SELinux also turns on syscall
auditing with its associated overhead.

Obviously I think the right thing to decide if an LSM wants to send a
denial message or not is the LSM.  The only problem I have is that the
LSM doesn't know today when it is getting different types or requests
and so can't make that decision.

-Eric

Re: SELinux and access(2), we want to know.

[Serge E. Hallyn]

Quoting Eric Paris (eparis@redhat.com):
> 3) I've also heard it hinted that we could do this with audit by just
> having audit drop the denials that include the access(2) syscall and the
> scontext and tcontext for the slew of things the SELinux policy writers
> know we are not interested in.  And while it seems good, now we have

What is the difference whether an attacker does access(2) to check for
/etc/shadow rights, or does a failed open()?

Either you care that someone is poking around, or you don't.  Right?

> SELinux 'policy' in places other than the policy, harder to distribute,
> and it requires that everyone who turns on SELinux also turns on syscall
> auditing with its associated overhead.
> 
> Obviously I think the right thing to decide if an LSM wants to send a
> denial message or not is the LSM.  The only problem I have is that the
> LSM doesn't know today when it is getting different types or requests
> and so can't make that decision.

I think the problem is that you want to guess the intent, and you
can't do that.  Knowing that a process did access instead of open
really isn't sufficient.

-serge

--
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 and access(2), we want to know.

[Serge E. Hallyn]

Quoting Eric Paris (eparis@redhat.com):
> 3) I've also heard it hinted that we could do this with audit by just
> having audit drop the denials that include the access(2) syscall and the
> scontext and tcontext for the slew of things the SELinux policy writers
> know we are not interested in.  And while it seems good, now we have

What is the difference whether an attacker does access(2) to check for
/etc/shadow rights, or does a failed open()?

Either you care that someone is poking around, or you don't.  Right?

> SELinux 'policy' in places other than the policy, harder to distribute,
> and it requires that everyone who turns on SELinux also turns on syscall
> auditing with its associated overhead.
> 
> Obviously I think the right thing to decide if an LSM wants to send a
> denial message or not is the LSM.  The only problem I have is that the
> LSM doesn't know today when it is getting different types or requests
> and so can't make that decision.

I think the problem is that you want to guess the intent, and you
can't do that.  Knowing that a process did access instead of open
really isn't sufficient.

-serge

Re: SELinux and access(2), we want to know.

[Eric Paris]

On Thu, 2009-05-07 at 14:57 -0500, Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@redhat.com):
> > 3) I've also heard it hinted that we could do this with audit by just
> > having audit drop the denials that include the access(2) syscall and the
> > scontext and tcontext for the slew of things the SELinux policy writers
> > know we are not interested in.  And while it seems good, now we have
> 
> What is the difference whether an attacker does access(2) to check for
> /etc/shadow rights, or does a failed open()?
> 
> Either you care that someone is poking around, or you don't.  Right?

No, sadly not true.  Sometimes people have a reason to poke....

> > SELinux 'policy' in places other than the policy, harder to distribute,
> > and it requires that everyone who turns on SELinux also turns on syscall
> > auditing with its associated overhead.
> > 
> > Obviously I think the right thing to decide if an LSM wants to send a
> > denial message or not is the LSM.  The only problem I have is that the
> > LSM doesn't know today when it is getting different types or requests
> > and so can't make that decision.
> 
> I think the problem is that you want to guess the intent, and you
> can't do that.  Knowing that a process did access instead of open
> really isn't sufficient.

That's absolutely true.  But, there are cases where we know that
applications are going to go things which selinux is going to deny and
we don't want to tell or warn the user, like for a long time pam would
try to directly open passwd/shadow if it could and would fall back to a
helper if it couldn't.  We wanted to force it to use the helper but we
didn't want tons of denials telling us it did something stupid.  It also
means that we wouldn't get the notification if it tried to do something
wrong, so it's a tradeoff.  Everyone in the SELinux community realizes
this.

In the case I'm describing our only choice is to stop auditing of ALL
attempts by the application to look at the file.  We know that the
application is going to be calling access() but we have to stop auditing
of both access and open, clearly you're not going to say this is a
better situation.

Your suggestion is the equivalent of knowing that your friend John might
look in your window to see if you are home but shouldn't ever try to
kick down the door.  In the current situation you can't tell the
difference between the window and the door so you won't call the police
even if John tries to kick down the door.  When in reality it would be a
lot better to not call the police if John looks in the window even
though you don't know his intent.  He might be looking in the window to
see if you are home and if not he'll try to kick down the door.  But
that situation of not knowing his intent and still not always calling
the policy is a heck of a lot better than NEVER calling the police.  And
I'm glad you see my side of the SELinux argument that this dontaudit
needs to be per domain, not global for all access calls, since knowing
John might look in the window has nothing to do with Jake and we
probably want to call the policy if he does either!

Often the right thing to do here is to fix the application to not
request things it doesn't need, but at least in the case of Nautilus it
needs to learn everything just so it can draw it's icons, not much we
can do about that example.

-Eric


--
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 and access(2), we want to know.

[Eric Paris]

On Thu, 2009-05-07 at 14:57 -0500, Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@redhat.com):
> > 3) I've also heard it hinted that we could do this with audit by just
> > having audit drop the denials that include the access(2) syscall and the
> > scontext and tcontext for the slew of things the SELinux policy writers
> > know we are not interested in.  And while it seems good, now we have
> 
> What is the difference whether an attacker does access(2) to check for
> /etc/shadow rights, or does a failed open()?
> 
> Either you care that someone is poking around, or you don't.  Right?

No, sadly not true.  Sometimes people have a reason to poke....

> > SELinux 'policy' in places other than the policy, harder to distribute,
> > and it requires that everyone who turns on SELinux also turns on syscall
> > auditing with its associated overhead.
> > 
> > Obviously I think the right thing to decide if an LSM wants to send a
> > denial message or not is the LSM.  The only problem I have is that the
> > LSM doesn't know today when it is getting different types or requests
> > and so can't make that decision.
> 
> I think the problem is that you want to guess the intent, and you
> can't do that.  Knowing that a process did access instead of open
> really isn't sufficient.

That's absolutely true.  But, there are cases where we know that
applications are going to go things which selinux is going to deny and
we don't want to tell or warn the user, like for a long time pam would
try to directly open passwd/shadow if it could and would fall back to a
helper if it couldn't.  We wanted to force it to use the helper but we
didn't want tons of denials telling us it did something stupid.  It also
means that we wouldn't get the notification if it tried to do something
wrong, so it's a tradeoff.  Everyone in the SELinux community realizes
this.

In the case I'm describing our only choice is to stop auditing of ALL
attempts by the application to look at the file.  We know that the
application is going to be calling access() but we have to stop auditing
of both access and open, clearly you're not going to say this is a
better situation.

Your suggestion is the equivalent of knowing that your friend John might
look in your window to see if you are home but shouldn't ever try to
kick down the door.  In the current situation you can't tell the
difference between the window and the door so you won't call the police
even if John tries to kick down the door.  When in reality it would be a
lot better to not call the police if John looks in the window even
though you don't know his intent.  He might be looking in the window to
see if you are home and if not he'll try to kick down the door.  But
that situation of not knowing his intent and still not always calling
the policy is a heck of a lot better than NEVER calling the police.  And
I'm glad you see my side of the SELinux argument that this dontaudit
needs to be per domain, not global for all access calls, since knowing
John might look in the window has nothing to do with Jake and we
probably want to call the policy if he does either!

Often the right thing to do here is to fix the application to not
request things it doesn't need, but at least in the case of Nautilus it
needs to learn everything just so it can draw it's icons, not much we
can do about that example.

-Eric

Re: SELinux and access(2), we want to know.

[Serge E. Hallyn]

Quoting Eric Paris (eparis@redhat.com):

...

> Your suggestion is the equivalent of knowing that your friend John might
> look in your window to see if you are home but shouldn't ever try to
> kick down the door.  In the current situation you can't tell the
> difference between the window and the door so you won't call the police
> even if John tries to kick down the door.

I don't buy this analogy, unless there a side effect to a failed open()
which I'm not thinking of?

> When in reality it would be a
> lot better to not call the police if John looks in the window even
> though you don't know his intent.  He might be looking in the window to
> see if you are home and if not he'll try to kick down the door.  But
> that situation of not knowing his intent and still not always calling
> the policy is a heck of a lot better than NEVER calling the police.  And
> I'm glad you see my side of the SELinux argument that this dontaudit
> needs to be per domain, not global for all access calls, since knowing

Yes.  It should be distinguishable per domain (and it is, using
dontaudit, right?).  But I don't yet see any reason why it's worth
distinguishing between access() and open().

> John might look in the window has nothing to do with Jake and we
> probably want to call the policy if he does either!
> 
> Often the right thing to do here is to fix the application to not
> request things it doesn't need, but at least in the case of Nautilus it
> needs to learn everything just so it can draw it's icons, not much we
> can do about that example.

If policy lets Nautilus poke around all under /usr without auditing,
then it (and anyone who attacks it) gets to do that...  catching opens
and not accesses doesn't imo buy you anything.

-serge

--
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 and access(2), we want to know.

[Serge E. Hallyn]

Quoting Eric Paris (eparis@redhat.com):

...

> Your suggestion is the equivalent of knowing that your friend John might
> look in your window to see if you are home but shouldn't ever try to
> kick down the door.  In the current situation you can't tell the
> difference between the window and the door so you won't call the police
> even if John tries to kick down the door.

I don't buy this analogy, unless there a side effect to a failed open()
which I'm not thinking of?

> When in reality it would be a
> lot better to not call the police if John looks in the window even
> though you don't know his intent.  He might be looking in the window to
> see if you are home and if not he'll try to kick down the door.  But
> that situation of not knowing his intent and still not always calling
> the policy is a heck of a lot better than NEVER calling the police.  And
> I'm glad you see my side of the SELinux argument that this dontaudit
> needs to be per domain, not global for all access calls, since knowing

Yes.  It should be distinguishable per domain (and it is, using
dontaudit, right?).  But I don't yet see any reason why it's worth
distinguishing between access() and open().

> John might look in the window has nothing to do with Jake and we
> probably want to call the policy if he does either!
> 
> Often the right thing to do here is to fix the application to not
> request things it doesn't need, but at least in the case of Nautilus it
> needs to learn everything just so it can draw it's icons, not much we
> can do about that example.

If policy lets Nautilus poke around all under /usr without auditing,
then it (and anyone who attacks it) gets to do that...  catching opens
and not accesses doesn't imo buy you anything.

-serge

Re: SELinux and access(2), we want to know.

[max]

On Thu, May 07, 2009 at 04:57:18PM -0400, Eric Paris wrote:
> On Thu, 2009-05-07 at 14:57 -0500, Serge E. Hallyn wrote:
> > Quoting Eric Paris (eparis@redhat.com):
> > > 3) I've also heard it hinted that we could do this with audit by just
> > > having audit drop the denials that include the access(2) syscall and the
> > > scontext and tcontext for the slew of things the SELinux policy writers
> > > know we are not interested in.  And while it seems good, now we have
> > 
> > What is the difference whether an attacker does access(2) to check for
> > /etc/shadow rights, or does a failed open()?
> > 
> > Either you care that someone is poking around, or you don't.  Right?

Yes.
 
> No, sadly not true.  Sometimes people have a reason to poke....

This statement is also true. For example(true story), recently a guy claiming to be from the census bureau was poking around my folks neighborhood. One of the neighbors saw the car going up and down the road, stopping at the top of driveways, wandering down, looking around, being nosy and generally acting suspicious, so the neighbor, she gets a little nervous when the guy decides to stop in her driveway and starts moving toward the door.This is out in the country mind you, so she grabs the shotgun and opens the door before he gets there, asks him what the hell he wants,this guy sees the shotgun blurts out he is with the census bureau and hauls ass. I trust you see my point, just because he ran when he saw the shotgun doesn't mean he wasn't legit.  

Personally as a user, I would like to know if a program is misbehaving or if someone is up to no good but as a novice in software development I recognize that this is not going to be even remotely easy. Just like writing policy without understanding what the program does behind the scenes. I could just look at the audit trail to see what it wants but without looking at the code I don't know if its really legit or malicious or just poorly coded.Good admins are hard to find and ones well versed in kernel internals to boot, even harder still.

So really your skirting the issue of whether or not to add some IDS functionality to SELinux.

Now in some cases like /etc/shadow the answer will be fairly obvious, you might be allowed to look but only one program should really need to write to this place. Grub might be another, I can't think of any legitamate reason, right now, why any program other than grub or any user other than root might need to modify grub. So in the obvious cases a big flare should go up telling me that I should absolutely consult with the list or another professional before allowing this access. Skull and cross-bones, big red letters, etc....

In other cases you may have to let SELinux learn if certain behavior is acceptable, now this has its own drawbacks but if users are just going to "allow according to SETroubleshoot" anyway then I don't see that your much worse off in the end. If SELinux can learn based perhaps on the origination point of the call whether or not it should be *audited* then maybe we are getting somewhere. Of course I have no idea at this point how one might go about such a thing or if its even feasible to do so. I am working my way through the code but its going to take me some time to sort this all out.

Now as far as overhead goes, sooner or later, you are going to have to pay the piper somewhere along the line but the kernel stuff I will leave, for now, to the resident wizards. The question I have is this: Is the audit daemon as efficient as it can be? I have auditd running and rsyslog by default on this box. Why two services for what amounts to the same job? I mean from a security perspective isn't every event a potential security issue? Perhaps the whole approach to auditing needs to be revisited. 

In the end I think, at the very least, your going to have to have some sort of IDS style functionality for certain key areas so the effect of a don't audit is less potentially catastrophic. Allowing a potentially dangerous access to go unaudited even if your certain of denial is not really desirable from an auditing standpoint. I need to know if anyone is attempting to abuse the system.  

-- 
"Any fool can know. The point is to understand" --Albert Einstein

Bored??
http://fiction.wikia.com/wiki/Fuqwit1.0

http://fiction.wikia.com/wiki/Coding_the_Magic_into_the_Eight_Ball

--
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 and access(2), we want to know.

[Casey Schaufler]

Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@redhat.com):
>   
>> 3) I've also heard it hinted that we could do this with audit by just
>> having audit drop the denials that include the access(2) syscall and the
>> scontext and tcontext for the slew of things the SELinux policy writers
>> know we are not interested in.  And while it seems good, now we have
>>     
>
> What is the difference whether an attacker does access(2) to check for
> /etc/shadow rights, or does a failed open()?
>   

I have been studiously ignoring the discussions on the SELinux list because
in the end it really doesn't matter, as Serge (appears to) point out here.
The access() system call was a major thorn in the side of the POSIX security
working group because its behavior is not really very rational. By design
it does not take into account read-only file systems, ACLs, MAC labels,
TOMOYO policy, or anything other than the mode bits. A successful return
from access() gives you no assurance whatever that if you actually try the
operation it will succeed. My recollection is that every version of
"trusted unix" written treats the system call the same way it would a
call to lstat(), because that's really all it is doing.


--
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 and access(2), we want to know.

[Casey Schaufler]

Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@redhat.com):
>   
>> 3) I've also heard it hinted that we could do this with audit by just
>> having audit drop the denials that include the access(2) syscall and the
>> scontext and tcontext for the slew of things the SELinux policy writers
>> know we are not interested in.  And while it seems good, now we have
>>     
>
> What is the difference whether an attacker does access(2) to check for
> /etc/shadow rights, or does a failed open()?
>   

I have been studiously ignoring the discussions on the SELinux list because
in the end it really doesn't matter, as Serge (appears to) point out here.
The access() system call was a major thorn in the side of the POSIX security
working group because its behavior is not really very rational. By design
it does not take into account read-only file systems, ACLs, MAC labels,
TOMOYO policy, or anything other than the mode bits. A successful return
from access() gives you no assurance whatever that if you actually try the
operation it will succeed. My recollection is that every version of
"trusted unix" written treats the system call the same way it would a
call to lstat(), because that's really all it is doing.

Re: SELinux and access(2), we want to know.

[Eamon Walsh]

Casey Schaufler wrote:
> Serge E. Hallyn wrote:
>   
>> Quoting Eric Paris (eparis@redhat.com):
>>   
>>     
>>> 3) I've also heard it hinted that we could do this with audit by just
>>> having audit drop the denials that include the access(2) syscall and the
>>> scontext and tcontext for the slew of things the SELinux policy writers
>>> know we are not interested in.  And while it seems good, now we have
>>>     
>>>       
>> What is the difference whether an attacker does access(2) to check for
>> /etc/shadow rights, or does a failed open()?
>>   
>>     
>
> I have been studiously ignoring the discussions on the SELinux list because
> in the end it really doesn't matter, as Serge (appears to) point out here.
> The access() system call was a major thorn in the side of the POSIX security
> working group because its behavior is not really very rational. By design
> it does not take into account read-only file systems, ACLs, MAC labels,
> TOMOYO policy, or anything other than the mode bits. A successful return
> from access() gives you no assurance whatever that if you actually try the
> operation it will succeed. My recollection is that every version of
> "trusted unix" written treats the system call the same way it would a
> call to lstat(), because that's really all it is doing.
>   

Serge, and the status quo, says access() == open(), not access() == lstat().

Eric's proposed change would be necessary to support access() ==
lstat(), even as an option.



-- 
Eamon Walsh <ewalsh@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: SELinux and access(2), we want to know.

[Eamon Walsh]

Casey Schaufler wrote:
> Serge E. Hallyn wrote:
>   
>> Quoting Eric Paris (eparis@redhat.com):
>>   
>>     
>>> 3) I've also heard it hinted that we could do this with audit by just
>>> having audit drop the denials that include the access(2) syscall and the
>>> scontext and tcontext for the slew of things the SELinux policy writers
>>> know we are not interested in.  And while it seems good, now we have
>>>     
>>>       
>> What is the difference whether an attacker does access(2) to check for
>> /etc/shadow rights, or does a failed open()?
>>   
>>     
>
> I have been studiously ignoring the discussions on the SELinux list because
> in the end it really doesn't matter, as Serge (appears to) point out here.
> The access() system call was a major thorn in the side of the POSIX security
> working group because its behavior is not really very rational. By design
> it does not take into account read-only file systems, ACLs, MAC labels,
> TOMOYO policy, or anything other than the mode bits. A successful return
> from access() gives you no assurance whatever that if you actually try the
> operation it will succeed. My recollection is that every version of
> "trusted unix" written treats the system call the same way it would a
> call to lstat(), because that's really all it is doing.
>   

Serge, and the status quo, says access() == open(), not access() == lstat().

Eric's proposed change would be necessary to support access() ==
lstat(), even as an option.



-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency

Re: SELinux and access(2), we want to know.

[Stephen Smalley]

On Thu, 2009-05-07 at 20:51 -0700, Casey Schaufler wrote:
> Serge E. Hallyn wrote:
> > Quoting Eric Paris (eparis@redhat.com):
> >   
> >> 3) I've also heard it hinted that we could do this with audit by just
> >> having audit drop the denials that include the access(2) syscall and the
> >> scontext and tcontext for the slew of things the SELinux policy writers
> >> know we are not interested in.  And while it seems good, now we have
> >>     
> >
> > What is the difference whether an attacker does access(2) to check for
> > /etc/shadow rights, or does a failed open()?
> >   
> 
> I have been studiously ignoring the discussions on the SELinux list because
> in the end it really doesn't matter, as Serge (appears to) point out here.
> The access() system call was a major thorn in the side of the POSIX security
> working group because its behavior is not really very rational. By design
> it does not take into account read-only file systems, ACLs, MAC labels,
> TOMOYO policy, or anything other than the mode bits. A successful return
> from access() gives you no assurance whatever that if you actually try the
> operation it will succeed. My recollection is that every version of
> "trusted unix" written treats the system call the same way it would a
> call to lstat(), because that's really all it is doing.

Casey, please go read the access(2) / faccessat(2) code in Linux and
then come back to the discussion.  It does in fact take into account all
of those things presently (and notes in a comment that SuS v2 requires
that it report a read-only fs).

-- 
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: SELinux and access(2), we want to know.

[Stephen Smalley]

On Thu, 2009-05-07 at 20:51 -0700, Casey Schaufler wrote:
> Serge E. Hallyn wrote:
> > Quoting Eric Paris (eparis@redhat.com):
> >   
> >> 3) I've also heard it hinted that we could do this with audit by just
> >> having audit drop the denials that include the access(2) syscall and the
> >> scontext and tcontext for the slew of things the SELinux policy writers
> >> know we are not interested in.  And while it seems good, now we have
> >>     
> >
> > What is the difference whether an attacker does access(2) to check for
> > /etc/shadow rights, or does a failed open()?
> >   
> 
> I have been studiously ignoring the discussions on the SELinux list because
> in the end it really doesn't matter, as Serge (appears to) point out here.
> The access() system call was a major thorn in the side of the POSIX security
> working group because its behavior is not really very rational. By design
> it does not take into account read-only file systems, ACLs, MAC labels,
> TOMOYO policy, or anything other than the mode bits. A successful return
> from access() gives you no assurance whatever that if you actually try the
> operation it will succeed. My recollection is that every version of
> "trusted unix" written treats the system call the same way it would a
> call to lstat(), because that's really all it is doing.

Casey, please go read the access(2) / faccessat(2) code in Linux and
then come back to the discussion.  It does in fact take into account all
of those things presently (and notes in a comment that SuS v2 requires
that it report a read-only fs).

-- 
Stephen Smalley
National Security Agency

Re: SELinux and access(2), we want to know.

[Daniel J Walsh]

On 05/08/2009 08:27 AM, Stephen Smalley wrote:
> On Thu, 2009-05-07 at 20:51 -0700, Casey Schaufler wrote:
>> Serge E. Hallyn wrote:
>>> Quoting Eric Paris (eparis@redhat.com):
>>>
>>>> 3) I've also heard it hinted that we could do this with audit by just
>>>> having audit drop the denials that include the access(2) syscall and the
>>>> scontext and tcontext for the slew of things the SELinux policy writers
>>>> know we are not interested in.  And while it seems good, now we have
>>>>
>>> What is the difference whether an attacker does access(2) to check for
>>> /etc/shadow rights, or does a failed open()?
>>>
>> I have been studiously ignoring the discussions on the SELinux list because
>> in the end it really doesn't matter, as Serge (appears to) point out here.
>> The access() system call was a major thorn in the side of the POSIX security
>> working group because its behavior is not really very rational. By design
>> it does not take into account read-only file systems, ACLs, MAC labels,
>> TOMOYO policy, or anything other than the mode bits. A successful return
>> from access() gives you no assurance whatever that if you actually try the
>> operation it will succeed. My recollection is that every version of
>> "trusted unix" written treats the system call the same way it would a
>> call to lstat(), because that's really all it is doing.
>
> Casey, please go read the access(2) / faccessat(2) code in Linux and
> then come back to the discussion.  It does in fact take into account all
> of those things presently (and notes in a comment that SuS v2 requires
> that it report a read-only fs).
>
Reality check.

The biggest reason for this is Nautilus and other GUI tools that open a 
directory and look at all of the files in the directory checking their 
access.  So running as staff_t and using nautilus on the /etc directory 
or /bin/directory generates hundreds of AVC indicating that staff_t 
tried to read/write/execute every program it is not allowed to execute.

Totally useless and gives the SELinux SUCKS crowd more ammunition. If 
the MLS people want to treat ACCESS==OPEN then we are going to have a 
big boolean/tunable flag for their paranoia.  For everyone else.  Lets 
try to figure out when an application is actually doing something evil.

Currently pam libraries and kerberos libraries run access checks that 
cause us to DONTAUDIT reads of /etc/shadow and WRITES of /etc/krb5.conf
To pretty critical Security files.  So any app that uses kerberos 
(getpw) call and every app that uses PAM Authentication can try to read 
/etc/shadow and write /etc/krb5.conf without us knowing.



--
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 and access(2), we want to know.

[Daniel J Walsh]

On 05/08/2009 08:27 AM, Stephen Smalley wrote:
> On Thu, 2009-05-07 at 20:51 -0700, Casey Schaufler wrote:
>> Serge E. Hallyn wrote:
>>> Quoting Eric Paris (eparis@redhat.com):
>>>
>>>> 3) I've also heard it hinted that we could do this with audit by just
>>>> having audit drop the denials that include the access(2) syscall and the
>>>> scontext and tcontext for the slew of things the SELinux policy writers
>>>> know we are not interested in.  And while it seems good, now we have
>>>>
>>> What is the difference whether an attacker does access(2) to check for
>>> /etc/shadow rights, or does a failed open()?
>>>
>> I have been studiously ignoring the discussions on the SELinux list because
>> in the end it really doesn't matter, as Serge (appears to) point out here.
>> The access() system call was a major thorn in the side of the POSIX security
>> working group because its behavior is not really very rational. By design
>> it does not take into account read-only file systems, ACLs, MAC labels,
>> TOMOYO policy, or anything other than the mode bits. A successful return
>> from access() gives you no assurance whatever that if you actually try the
>> operation it will succeed. My recollection is that every version of
>> "trusted unix" written treats the system call the same way it would a
>> call to lstat(), because that's really all it is doing.
>
> Casey, please go read the access(2) / faccessat(2) code in Linux and
> then come back to the discussion.  It does in fact take into account all
> of those things presently (and notes in a comment that SuS v2 requires
> that it report a read-only fs).
>
Reality check.

The biggest reason for this is Nautilus and other GUI tools that open a 
directory and look at all of the files in the directory checking their 
access.  So running as staff_t and using nautilus on the /etc directory 
or /bin/directory generates hundreds of AVC indicating that staff_t 
tried to read/write/execute every program it is not allowed to execute.

Totally useless and gives the SELinux SUCKS crowd more ammunition. If 
the MLS people want to treat ACCESS==OPEN then we are going to have a 
big boolean/tunable flag for their paranoia.  For everyone else.  Lets 
try to figure out when an application is actually doing something evil.

Currently pam libraries and kerberos libraries run access checks that 
cause us to DONTAUDIT reads of /etc/shadow and WRITES of /etc/krb5.conf
To pretty critical Security files.  So any app that uses kerberos 
(getpw) call and every app that uses PAM Authentication can try to read 
/etc/shadow and write /etc/krb5.conf without us knowing.

Re: SELinux and access(2), we want to know.

[Serge E. Hallyn]

Quoting Daniel J Walsh (dwalsh@redhat.com):
> Totally useless and gives the SELinux SUCKS crowd more ammunition. If  
> the MLS people want to treat ACCESS==OPEN then we are going to have a  
> big boolean/tunable flag for their paranoia.  For everyone else.  Lets  
> try to figure out when an application is actually doing something evil.

I'm really not here to be difficult, but if you believe that a failed
open is a problem bc an attacker can poke around the fs, and you believe
that nautilus can be hacked, then ignoring access just doesn't make
sense.  The fact that users are being inconvenienced doesn't change
that.

Jamie's point (obscured in code because it is implemented through
the use of fsuid) that for DAC purposes access and open use different
creds, is useful.  I can buy that audit should spit out a slightly
different message to show that MAC failed on real cred attempt
instead of subj...  (Even though the values of uid, euid, and fsuid
in the audit msg should make that clear).

So in that case, given how the code is structured currently in
fs/{open,namei}.c and through inode_permission, an extra flag
which selinux simply uses to judge which audit msg (if any) to
spit out seems the simplest way to do it.

-serge

--
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 and access(2), we want to know.

[Serge E. Hallyn]

Quoting Daniel J Walsh (dwalsh@redhat.com):
> Totally useless and gives the SELinux SUCKS crowd more ammunition. If  
> the MLS people want to treat ACCESS==OPEN then we are going to have a  
> big boolean/tunable flag for their paranoia.  For everyone else.  Lets  
> try to figure out when an application is actually doing something evil.

I'm really not here to be difficult, but if you believe that a failed
open is a problem bc an attacker can poke around the fs, and you believe
that nautilus can be hacked, then ignoring access just doesn't make
sense.  The fact that users are being inconvenienced doesn't change
that.

Jamie's point (obscured in code because it is implemented through
the use of fsuid) that for DAC purposes access and open use different
creds, is useful.  I can buy that audit should spit out a slightly
different message to show that MAC failed on real cred attempt
instead of subj...  (Even though the values of uid, euid, and fsuid
in the audit msg should make that clear).

So in that case, given how the code is structured currently in
fs/{open,namei}.c and through inode_permission, an extra flag
which selinux simply uses to judge which audit msg (if any) to
spit out seems the simplest way to do it.

-serge

Re: SELinux and access(2), we want to know.

[Casey Schaufler]

Daniel J Walsh wrote:
> On 05/08/2009 08:27 AM, Stephen Smalley wrote:
>> On Thu, 2009-05-07 at 20:51 -0700, Casey Schaufler wrote:
>>> Serge E. Hallyn wrote:
>>>> Quoting Eric Paris (eparis@redhat.com):
>>>>
>>>>> 3) I've also heard it hinted that we could do this with audit by just
>>>>> having audit drop the denials that include the access(2) syscall
>>>>> and the
>>>>> scontext and tcontext for the slew of things the SELinux policy
>>>>> writers
>>>>> know we are not interested in.  And while it seems good, now we have
>>>>>
>>>> What is the difference whether an attacker does access(2) to check for
>>>> /etc/shadow rights, or does a failed open()?
>>>>
>>> I have been studiously ignoring the discussions on the SELinux list
>>> because
>>> in the end it really doesn't matter, as Serge (appears to) point out
>>> here.
>>> The access() system call was a major thorn in the side of the POSIX
>>> security
>>> working group because its behavior is not really very rational. By
>>> design
>>> it does not take into account read-only file systems, ACLs, MAC labels,
>>> TOMOYO policy, or anything other than the mode bits. A successful
>>> return
>>> from access() gives you no assurance whatever that if you actually
>>> try the
>>> operation it will succeed. My recollection is that every version of
>>> "trusted unix" written treats the system call the same way it would a
>>> call to lstat(), because that's really all it is doing.
>>
>> Casey, please go read the access(2) / faccessat(2) code in Linux and
>> then come back to the discussion.  It does in fact take into account all
>> of those things presently (and notes in a comment that SuS v2 requires
>> that it report a read-only fs).

I stand humbly corrected. My years of experience have gotten
in the way of reality yet again.

>>
> Reality check.
>
> The biggest reason for this is Nautilus and other GUI tools that open
> a directory and look at all of the files in the directory checking
> their access.  So running as staff_t and using nautilus on the /etc
> directory or /bin/directory generates hundreds of AVC indicating that
> staff_t tried to read/write/execute every program it is not allowed to
> execute.
>
> Totally useless and gives the SELinux SUCKS crowd more ammunition.

Not to mention that a call to access() does not open the file. It
reports on the state of attributes of the file relative to the
attributes of a process. No access to the data is made available
via access() as is the case with open().

> If the MLS people want to treat ACCESS==OPEN then we are going to have
> a big boolean/tunable flag for their paranoia.  For everyone else. 
> Lets try to figure out when an application is actually doing something
> evil.

Treating access() the same as open() is wrong. Maybe that's what you
want in the SELinux policy, but it sure isn't consistent with the way
the file system works. Attribute accesses are different from data
accesses.

>
> Currently pam libraries and kerberos libraries run access checks that
> cause us to DONTAUDIT reads of /etc/shadow and WRITES of /etc/krb5.conf
> To pretty critical Security files.  So any app that uses kerberos
> (getpw) call and every app that uses PAM Authentication can try to
> read /etc/shadow and write /etc/krb5.conf without us knowing.
>
>
>


--
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 and access(2), we want to know.

[Casey Schaufler]

Daniel J Walsh wrote:
> On 05/08/2009 08:27 AM, Stephen Smalley wrote:
>> On Thu, 2009-05-07 at 20:51 -0700, Casey Schaufler wrote:
>>> Serge E. Hallyn wrote:
>>>> Quoting Eric Paris (eparis@redhat.com):
>>>>
>>>>> 3) I've also heard it hinted that we could do this with audit by just
>>>>> having audit drop the denials that include the access(2) syscall
>>>>> and the
>>>>> scontext and tcontext for the slew of things the SELinux policy
>>>>> writers
>>>>> know we are not interested in.  And while it seems good, now we have
>>>>>
>>>> What is the difference whether an attacker does access(2) to check for
>>>> /etc/shadow rights, or does a failed open()?
>>>>
>>> I have been studiously ignoring the discussions on the SELinux list
>>> because
>>> in the end it really doesn't matter, as Serge (appears to) point out
>>> here.
>>> The access() system call was a major thorn in the side of the POSIX
>>> security
>>> working group because its behavior is not really very rational. By
>>> design
>>> it does not take into account read-only file systems, ACLs, MAC labels,
>>> TOMOYO policy, or anything other than the mode bits. A successful
>>> return
>>> from access() gives you no assurance whatever that if you actually
>>> try the
>>> operation it will succeed. My recollection is that every version of
>>> "trusted unix" written treats the system call the same way it would a
>>> call to lstat(), because that's really all it is doing.
>>
>> Casey, please go read the access(2) / faccessat(2) code in Linux and
>> then come back to the discussion.  It does in fact take into account all
>> of those things presently (and notes in a comment that SuS v2 requires
>> that it report a read-only fs).

I stand humbly corrected. My years of experience have gotten
in the way of reality yet again.

>>
> Reality check.
>
> The biggest reason for this is Nautilus and other GUI tools that open
> a directory and look at all of the files in the directory checking
> their access.  So running as staff_t and using nautilus on the /etc
> directory or /bin/directory generates hundreds of AVC indicating that
> staff_t tried to read/write/execute every program it is not allowed to
> execute.
>
> Totally useless and gives the SELinux SUCKS crowd more ammunition.

Not to mention that a call to access() does not open the file. It
reports on the state of attributes of the file relative to the
attributes of a process. No access to the data is made available
via access() as is the case with open().

> If the MLS people want to treat ACCESS==OPEN then we are going to have
> a big boolean/tunable flag for their paranoia.  For everyone else. 
> Lets try to figure out when an application is actually doing something
> evil.

Treating access() the same as open() is wrong. Maybe that's what you
want in the SELinux policy, but it sure isn't consistent with the way
the file system works. Attribute accesses are different from data
accesses.

>
> Currently pam libraries and kerberos libraries run access checks that
> cause us to DONTAUDIT reads of /etc/shadow and WRITES of /etc/krb5.conf
> To pretty critical Security files.  So any app that uses kerberos
> (getpw) call and every app that uses PAM Authentication can try to
> read /etc/shadow and write /etc/krb5.conf without us knowing.
>
>
>

Re: SELinux and access(2), we want to know.

[Stephen Smalley]

On Fri, 2009-05-08 at 08:27 -0400, Stephen Smalley wrote:
> On Thu, 2009-05-07 at 20:51 -0700, Casey Schaufler wrote:
> > Serge E. Hallyn wrote:
> > > Quoting Eric Paris (eparis@redhat.com):
> > >   
> > >> 3) I've also heard it hinted that we could do this with audit by just
> > >> having audit drop the denials that include the access(2) syscall and the
> > >> scontext and tcontext for the slew of things the SELinux policy writers
> > >> know we are not interested in.  And while it seems good, now we have
> > >>     
> > >
> > > What is the difference whether an attacker does access(2) to check for
> > > /etc/shadow rights, or does a failed open()?
> > >   
> > 
> > I have been studiously ignoring the discussions on the SELinux list because
> > in the end it really doesn't matter, as Serge (appears to) point out here.
> > The access() system call was a major thorn in the side of the POSIX security
> > working group because its behavior is not really very rational. By design
> > it does not take into account read-only file systems, ACLs, MAC labels,
> > TOMOYO policy, or anything other than the mode bits. A successful return
> > from access() gives you no assurance whatever that if you actually try the
> > operation it will succeed. My recollection is that every version of
> > "trusted unix" written treats the system call the same way it would a
> > call to lstat(), because that's really all it is doing.
> 
> Casey, please go read the access(2) / faccessat(2) code in Linux and
> then come back to the discussion.  It does in fact take into account all
> of those things presently (and notes in a comment that SuS v2 requires
> that it report a read-only fs).

...and it is precisely for this reason that programs like nautilus use
access(2) rather than lstat(2) in order to determine accessibility of
the files.  As do other things like the kerberos libraries.  So we can't
just change the behavior to fit your model of access(2) only checking
mode bits.

-- 
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: SELinux and access(2), we want to know.

[Stephen Smalley]

On Fri, 2009-05-08 at 08:27 -0400, Stephen Smalley wrote:
> On Thu, 2009-05-07 at 20:51 -0700, Casey Schaufler wrote:
> > Serge E. Hallyn wrote:
> > > Quoting Eric Paris (eparis@redhat.com):
> > >   
> > >> 3) I've also heard it hinted that we could do this with audit by just
> > >> having audit drop the denials that include the access(2) syscall and the
> > >> scontext and tcontext for the slew of things the SELinux policy writers
> > >> know we are not interested in.  And while it seems good, now we have
> > >>     
> > >
> > > What is the difference whether an attacker does access(2) to check for
> > > /etc/shadow rights, or does a failed open()?
> > >   
> > 
> > I have been studiously ignoring the discussions on the SELinux list because
> > in the end it really doesn't matter, as Serge (appears to) point out here.
> > The access() system call was a major thorn in the side of the POSIX security
> > working group because its behavior is not really very rational. By design
> > it does not take into account read-only file systems, ACLs, MAC labels,
> > TOMOYO policy, or anything other than the mode bits. A successful return
> > from access() gives you no assurance whatever that if you actually try the
> > operation it will succeed. My recollection is that every version of
> > "trusted unix" written treats the system call the same way it would a
> > call to lstat(), because that's really all it is doing.
> 
> Casey, please go read the access(2) / faccessat(2) code in Linux and
> then come back to the discussion.  It does in fact take into account all
> of those things presently (and notes in a comment that SuS v2 requires
> that it report a read-only fs).

...and it is precisely for this reason that programs like nautilus use
access(2) rather than lstat(2) in order to determine accessibility of
the files.  As do other things like the kerberos libraries.  So we can't
just change the behavior to fit your model of access(2) only checking
mode bits.

-- 
Stephen Smalley
National Security Agency

Re: SELinux and access(2), we want to know.

[Jamie Lokier]

Eric Paris wrote:
> If a process calls access("/etc/shadow", R_OK) I claim
> that we darn sure better return the same result that open("/etc/shadow",
> O_RDONLY) would return.  I'm guessing noone is going to argue that
> point.

This is actually wrong in general - and I see that several posters
have repeated it as if it's a fact.

Since the days prior to the new-fangled security models, access() is
supposed to calculate access for the _real_ user and group of the
process doing the access, whereas open() uses the _effective_ user and
group.

It is one of the things access() is useful for, in setuid/setgid programs.

It should be quite obvious that there are corresponding concepts in
modern security models, such as delegated authority, capabilities
etc. which possibly ought to apply to access(), and which possibly
affect how it's audited.

-- Jamie

Re: SELinux and access(2), we want to know.

[Stephen Smalley]

On Thu, 2009-05-07 at 15:18 -0400, Eric Paris wrote:
> SELinux (and I assume all LSMs) have a bit of a problem with with the
> access(2) call.  If a process calls access("/etc/shadow", R_OK) I claim
> that we darn sure better return the same result that open("/etc/shadow",
> O_RDONLY) would return.  I'm guessing noone is going to argue that
> point.  Lets me also say this is only interesting if DAC allows a given
> operation but MAC disallows it.  If DAC denies the request none of this
> matters.
> 
> The only way to tell the right result for access() is for SELinux to
> actually do the checks between (subject, file, read).  Again not a lot
> of controversy here.
> 
> Lets say that the LSM does not allow read for the given subject
> to /etc/shadow.  SELinux just denied an operation.  Today we log that a
> process was just denied the ability to read /etc/shadow.  But the
> process didn't actually try to read it.  If you surf with nautilus
> to /etc it's going to call access() on everything to decide what kind of
> little icons to put up there.  This could generate hundreds of SELinux
> denials that nautilus tried to read everything in /etc.
> 
> What SELinux has to do today for programs like this is to not audit the
> permission check (subject, file, read).  The problem here is that if the
> program does act badly, and actually tries to read the file rather than
> just call access() SELinux won't notify us, or report the denial in the
> audit log.
> 
> I want/need a way for SELinux to know that a particular check can from
> access() rather than from a truly misbehaving program.  That way I can
> not send denial messages to the log if people just call access(2) but
> will send a denial if the program does something illegal.  We had a long
> discussion on the SELinux list about how we want to handle and log the
> differences, but from the point of view of the VFS all that matters is
> that we want to know when inode_permission is being called in access()
> or from somewhere else.  The discussion was between not logging ANY
> denials SELiunx causes from the access() call and being smarter about
> only not logging those we really don't care about in a more fine grained
> manor (I plan to go with fine grained version of not logging denials).
> The philosophical question is really if there is (and I claim there is)
> a difference between access() and open() and if we agree there is a
> difference SELinux needs to know about it so logging those is different.
> 
> I propose 2 possible solutions.
> 1) a new VFS flag next to MAY_READ, MAY_WRITE and friends possibly
> called "FROM_ACCESS" which we pass down to the LSM in faccessat during
> the inode_permission call.

This seems to be the simplest approach, and I don't see any downside to
it.  Just requires adding the flag, passing it down through
inode_permission and to security_inode_permission, and then updating the
Smack and SELinux hook functions to handle it properly.  Then Casey can
even ignore requests from access(2) if he wants in Smack and have it
only return the DAC result if that is his preference...

> 2) a new LSM hook.  security_inode_access_permission() which is called
> from inode_permission() along with associated flags and such to
> inode_permissions so the LSM knows where this call is coming from.
> 
> 3) I've also heard it hinted that we could do this with audit by just
> having audit drop the denials that include the access(2) syscall and the
> scontext and tcontext for the slew of things the SELinux policy writers
> know we are not interested in.  And while it seems good, now we have
> SELinux 'policy' in places other than the policy, harder to distribute,
> and it requires that everyone who turns on SELinux also turns on syscall
> auditing with its associated overhead.
> 
> Obviously I think the right thing to decide if an LSM wants to send a
> denial message or not is the LSM.  The only problem I have is that the
> LSM doesn't know today when it is getting different types or requests
> and so can't make that decision.
> 
> -Eric
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
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: SELinux and access(2), we want to know.

[Stephen Smalley]

On Thu, 2009-05-07 at 15:18 -0400, Eric Paris wrote:
> SELinux (and I assume all LSMs) have a bit of a problem with with the
> access(2) call.  If a process calls access("/etc/shadow", R_OK) I claim
> that we darn sure better return the same result that open("/etc/shadow",
> O_RDONLY) would return.  I'm guessing noone is going to argue that
> point.  Lets me also say this is only interesting if DAC allows a given
> operation but MAC disallows it.  If DAC denies the request none of this
> matters.
> 
> The only way to tell the right result for access() is for SELinux to
> actually do the checks between (subject, file, read).  Again not a lot
> of controversy here.
> 
> Lets say that the LSM does not allow read for the given subject
> to /etc/shadow.  SELinux just denied an operation.  Today we log that a
> process was just denied the ability to read /etc/shadow.  But the
> process didn't actually try to read it.  If you surf with nautilus
> to /etc it's going to call access() on everything to decide what kind of
> little icons to put up there.  This could generate hundreds of SELinux
> denials that nautilus tried to read everything in /etc.
> 
> What SELinux has to do today for programs like this is to not audit the
> permission check (subject, file, read).  The problem here is that if the
> program does act badly, and actually tries to read the file rather than
> just call access() SELinux won't notify us, or report the denial in the
> audit log.
> 
> I want/need a way for SELinux to know that a particular check can from
> access() rather than from a truly misbehaving program.  That way I can
> not send denial messages to the log if people just call access(2) but
> will send a denial if the program does something illegal.  We had a long
> discussion on the SELinux list about how we want to handle and log the
> differences, but from the point of view of the VFS all that matters is
> that we want to know when inode_permission is being called in access()
> or from somewhere else.  The discussion was between not logging ANY
> denials SELiunx causes from the access() call and being smarter about
> only not logging those we really don't care about in a more fine grained
> manor (I plan to go with fine grained version of not logging denials).
> The philosophical question is really if there is (and I claim there is)
> a difference between access() and open() and if we agree there is a
> difference SELinux needs to know about it so logging those is different.
> 
> I propose 2 possible solutions.
> 1) a new VFS flag next to MAY_READ, MAY_WRITE and friends possibly
> called "FROM_ACCESS" which we pass down to the LSM in faccessat during
> the inode_permission call.

This seems to be the simplest approach, and I don't see any downside to
it.  Just requires adding the flag, passing it down through
inode_permission and to security_inode_permission, and then updating the
Smack and SELinux hook functions to handle it properly.  Then Casey can
even ignore requests from access(2) if he wants in Smack and have it
only return the DAC result if that is his preference...

> 2) a new LSM hook.  security_inode_access_permission() which is called
> from inode_permission() along with associated flags and such to
> inode_permissions so the LSM knows where this call is coming from.
> 
> 3) I've also heard it hinted that we could do this with audit by just
> having audit drop the denials that include the access(2) syscall and the
> scontext and tcontext for the slew of things the SELinux policy writers
> know we are not interested in.  And while it seems good, now we have
> SELinux 'policy' in places other than the policy, harder to distribute,
> and it requires that everyone who turns on SELinux also turns on syscall
> auditing with its associated overhead.
> 
> Obviously I think the right thing to decide if an LSM wants to send a
> denial message or not is the LSM.  The only problem I have is that the
> LSM doesn't know today when it is getting different types or requests
> and so can't make that decision.
> 
> -Eric
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Stephen Smalley
National Security Agency