On 12/01/2009 09:47 AM, Dominick Grift wrote:
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.
I've relabled like 15 times with rlpkg -a -r. LOL
matchpathcon /etc/ld.so.cache
/etc/ld.so.cache system_u:object_r:ld_so_cache_t
ls -Z /etc/ld.so.cache
root:object_r:ld_so_cache_t
Based on the above, I did
chcon -u system_u /etc/ld.so.cache
That seems to have resolved the issues that were plaguing me there.
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.
That's exactly what it says.
When I do the following:
# grep udev /var/log/avc.log > local
# audit2allow -m local > local.te
# checkmodule -M -m -o local.mod local.te
checkmodule: loading policy configuration from local.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 8) to local.mod
# semodule_package -o local.pp -m local.mod
# semodule -i ./local.pp
Everything goes fine up to the semodule -i command, and then I get:
libsepol.link_modules: Tried to link in an MLS module with a non-MLS base.
libsemanage.semanage_link_sandbox: Link packages failed
semodule: Failed!
Based on all the weird problems and heartburn I've had, I'm really
starting to wonder if ANYONE in recent history has gotten a strict
Selinux profile running in enforcing mode on hardened-gentoo according
to the instructions in the Gentoo Selinux Handbook. Getting even to
this point has been frustrating beyond belief.
And before I give anyone the wrong impression, I really do appreciate
the hard work that has gone into this; I'm just suffering from a steep
learning curve, and documentation that I not only don't understand, but
doesn't seem to correspond to my system when I DO understand it.
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.
That's default gentoo-hardened policy. V2 policy horridly breaks a
hardened gentoo system at this stage from what I understand (as in, it
won't even boot).
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?)
Thanks for your response and help.
Later,
Chris
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
