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

[Francis Shim]

Originally, I had Fedora Core 1 linux distro and then decided to simply
upgrade to Fedora Core 2 via manually rpm-ing the necessary packages. 
Everything went pretty much as expected and now I have the Selinux
policy packages all installed.  I decided to start reading the obvious
README in /etc/security/selinux/src/policy and then went to the NSA
SELinux website.  I did the make load and make relabel and reboot cycle,
leaving the SELinux in permissive mode.

Now, I am ready to take the next step: reading the audit logging
messages and taking some action per audit.  I just need some more
insight and expertise from someone to enlighten me as to which direction
to take.

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

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.

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.

Any good tips and comments?

Thanks,
Frank

[Russell Coker]

On Fri, 11 Jun 2004 22:33, Francis K Shim  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.