AVC Denials on UDEV

Wed Dec 2 17:46:15 UTC 2009

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