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