AVC Denials on UDEV

Wed Dec 2 18:36:51 UTC 2009

On Wed, Dec 02, 2009 at 11:46:15AM -0600, Chris Richards wrote:
> 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

The -u system_u isnt responsible for the denial. In the avc denials above the type for the file was etc_t. That was mislabeled because matchpatchcon said it should have been ld_so_cache_t. So i think restoration (relabeling) fixed it.
> 
> 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:

The checkmodule command  has some bugs i think.
in fedora we use the make file:

make -f /usr/share/selinux/devel/Makefile myudevfix.pp
semodule -i myudevfix.pp
> 
> 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.

Well i have seen some people who have it in the #selinux irc chan, but i think they used newer policy.

> 
> 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.

Well there are certainly some basics one needs to be familair with , with regard to policy, but when you have that its pretty easy.

SELinux is a framework that lets one define types and assign these types to subjects and objects in a system. The framework also lets on define  policy that governs how types can interact with eashother. To make this possible, the kernel provides classes and permission. if you put that together you get something like this:

allow subjecttype_t objecttype_t:objectclass permissions;

then theres the concept of (subject and object) type transitions. ( go from one type to another type )

Those are the basics of type enforcement. Then youll alsoo need to get familair with how policy is structured upstream (they have some guidelines that make maintenance easier)

Then get to know the tools, and youre halfway there.
> 
> >>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 at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20091202/b1bd9982/attachment.sig>