Newbie - From audit log message ("avc: denied") to an appropriate fix

[Russell Coker]

On Fri, 11 Jun 2004 22:33, Francis K Shim <belfrancis2001 at yahoo.ca> wrote:
> To start off with I am looking at the following audit line (with some
> editing out of irrelevant info) from "dmesg":
>
> audit(...): avc:  denied  { search }
>     for pid=458 exe=/usr/bin/rhgb
>     name=.themes dev=hda... ino=...
>     scontext=system_u:system_r:rhgb_t
>     tcontext=root:object_r:staff_home_t
>     tclass=dir
>
> This audit line reports that the process (pid=458) running the
> executable program (/usr/bin/rhgb), the RedHat Graphics Boot program,
> was trying to access the target object ".themes" (a directory).

I think that is a bug in rhgb.  I can imagine a situation where the 
administrator may put bogus data in the .themes directory.  While the system 
is operational there will be no problem as the admin never logs in to X as 
root.  But then after some months of uptime the machine is rebooted and fails 
to correctly complete the boot process because rhgb stuffs up.

Please file a bugzilla about this.

> Okay, the rhgb process is running in the source context with an identity
> of "system_u" (System user) in the role of "system_r" (System role)
> within the domain of "rhgb_t" (RedHat Graphics Boot domain) and is
> trying to access the directory target object ".themes" which has a
> target context with an identity of "root" in the role of "system_r"
> (System role) with a type of "staff_home_t" (Staff Home object type).
>
> Given that the audit process denies the "search" on this access, that
> means that the rhgb domain does not have "search" access to a
> staff_home_t type object.

Correct.  When I wrote the rhgb policy I did not have a /root/.themes 
directory (I never use X as root), so such an access was not required.

> Okay, I guess I should go to the /etc/security/selinux/src/policy
> directory and edit the policy.conf(?) file to add a suitable transition
> policy... but I am not confident as to what.

policy.conf is a generated file, editing it by hand is a bad idea.  You can 
edit domains/program/rhgb.te and then run "make load" to install the new 
policy.  Alternately you can create a new file domains/misc/custom.te to have 
such rules to keep your policy separate from policy that is provided by RPMs.

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