Should this be a dontaudit or an allow in targeted.

Should this be a dontaudit or an allow in targeted.

[Daniel J Walsh]

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

Basically if a normal uses does a ps -ef on a system, his process will attempt to read the context of udev and friends that are running at a higher sensitivity level.  So apps like login, udev and others will generate 
AVC messages with MCS policy.

-- 



--
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: Should this be a dontaudit or an allow in targeted.

[Stephen Smalley]

On Mon, 2005-10-31 at 10:04 -0500, Daniel J Walsh wrote:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172040
> 
> Basically if a normal uses does a ps -ef on a system, his process will attempt to read the context of udev and friends that are running at a higher sensitivity level.  So apps like login, udev and others will generate 
> AVC messages with MCS policy.

We already have dontaudit rules for similar kinds of denials under
strict policy when a user process does a ps -el.  Hence, dontaudit seems
appropriate here.  The only case where an unconfined_t process would
encounter such a denial would be due to MCS.

On a related note, it has been suggested (on lspp) that we might need
dontaudit/auditallow rules based on MLS level.  Is that true, or can we
just leverage the existing TE-based rules to control such auditing based
on type (which typically gives us finer granularity anyway)?

-- 
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: Should this be a dontaudit or an allow in targeted.

[Russell Coker]

On Tuesday 01 November 2005 03:02, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On a related note, it has been suggested (on lspp) that we might need
> dontaudit/auditallow rules based on MLS level.  Is that true, or can we
> just leverage the existing TE-based rules to control such auditing based
> on type (which typically gives us finer granularity anyway)?

It seems sensible to have audit controlled on the same basis as access.  So 
for any criteria on which access can be allowed/denied it should be possible 
to base audit decisions on the same criteria.

auditconstrain/mlsauditconstrain?

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