On 12/01/2009 03:44 PM, Chris Richards wrote:
> First, my apologies if I'm in the wrong place or this has been asked
> before (I'm sure it has, but I haven't turned up anything with Google).
>
> I'm running a Gentoo system. This is a fresh build, so not everything
> is installed yet. Basically, I've got the stage 3 tarball, the Selinux
> stuff, syslog-ng and vixie-cron, and that's about it.
>
> When I boot my sysem, I'm getting the following messages in my kernel log:
> * Mounting /dev
> /etc/init.d/udev-mount: line 63: /dev/null: Permission denied
> /etc/init.d/udev: line 69: /dev/null: Permission denied
> * Starting udevd
> * Populating /dev with existing devices through uevents ...
> # Waiting for uevents to be processed ...
> error sending message: Permission denied
> error sending message: Permission denied
> udevadm[601]: errorsending message: Permission denied
>
> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.208:3):
> avc: denied { read } for pid=1 comm="init" name="ld.so.cache" dev=sda3
> ino=737384 scontext=system_u:system_r:init_t
> tcontext=system_u:object_r:file_t tclass=file
> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4):
> avc: denied { getattr } for pid=1 comm="init" path="/etc/ld.so.cache"
> dev=sda3 ino=737384 scontext=system_u:system_r:init_t
> tcontext=system_u:object_r:file_t tclass=file
looks like the file is mislabeled. what does matchpathcon
/etc/ld.so.cache say?
make sure that your file system labeling is correct.
> The pattern of denials above repeats for a number of comm= types,
> including consoletype, dmesg, hwclock, hostname, ifconfig
>
> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.221:5):
> avc: denied { read } for pid=1 comm="init" name="urandom" dev=sda3
> ino=140683 scontext=system_u:system_r:init_t
> tcontext=system_u:object_r:urandom_device_t tclass=chr_file
>
> As above, I get a number of denials on different comm= types.
>
>
> I'm also seeing a buttload of these in my avc.log:
> Dec 1 13:48:41 aoaforums kernel: type=1400
> audit(1259675321.237:1614490880): avc: denied { read } for pid=477
> comm="udevd" path="anon_inode:[signalfd]" dev=anon_inodefs ino=9
> scontext=system_u:system_r:udev_t
> tcontext=system_u:object_r:anon_inodefs_t tclass=file
> This one in particular is bad: my log is full to overflowing with this
> one, and when I'm in enforcing mode udevd is pulling 100% cpu.
If the types in this interaction are correct. Run the avc denial through
audit2why. If audit2why says "missing TE rule"; then consider adding
policy to allow it using audit2allow and semodule.
> Finally, a related question:
> Gentoo is currently running what is labeled as
> "selinux-base-policy-20080525".
That policy is old. See if you can implement some newer policy.
> This seems to bear little resemblance to the policy and tools that I see
> discussed here:
> http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted
>
> In particular, a lot of the booleans don't exist. As near as I can
> tell, this is pretty much the policy that was used in RHEL 4. However,
> I can find precious little in the way of documentation on the older
> policy setup. Can anyone provide any guidance on resources to look at
> for this? Referring me to the current base policy and tools really
> doesn't help me in understanding what my system is doing.....
>
> Many thanks in advance for any guidance you can offer.
Overall it is good to appreciate that SELinux is a framework and that
policy is configuration. The framework allows you to define policy.
The process of adding policy is always on going. In my view no policy
will ever be perfect. There are simply to many variables.
Learn how to implement policy, make security decisions and solve
interaction problems.
Theres a few things to consider:
1. are the types in an interaction the expected types. (mislabeled objects?)
2. is there some tunable policy available to allow an interaction that
is currently denied? (audit2why)
3. is a denial caused by misconfiguration of one of the parties in an
interaction? (check config of app)
4. is a denial signalling an intrusion. (break in?)
5. is a denials signalling a bug in one of the parties in an
interaction? (bug in app)
6. is it a bug in selinux-policy( are rules to allow it missing?)
>
> Later,
> Chris
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
