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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list