AVC Denials on UDEV

Dominick Grift domg472 at gmail.com
Wed Dec 2 23:21:02 UTC 2009


On Wed, Dec 02, 2009 at 05:13:41PM -0600, Chris Richards wrote:
> On 12/02/2009 12:36 PM, Dominick Grift wrote:
> >>>>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.
> Eh?  I'm not understanding something: I thought the source context
> was init_t and that target was file_t?  Now I'm really confused
> again.

Yes sorry i meant to say file_t.
> 
> In any case, I didn't relabel, all I did for that one was the chcon
> mentioned above, and the error no longer exists.  Again, I'm really
> confused.

whatever happend the type changed and thats what counts.

> >>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
> That would be wonderful, except that I don't have the make file.  I
> don't even have the source files.  Gentoo policy is distributed as
> binaries only, to the best of my knowledge.
> 
> >>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.
> >
> That's possible.  There's a v2refpolicy profile in the Portage tree,
> but the Gentoo Selinux Handbook specifically says to ONLY use the
> Portage profile I'm using right now.  Perhaps I need to see if I can
> pick Christopher PeBenito's brain, as I gather he has some
> involvement both in the SELinux community and the Gentoo community.
Yes he is both maintainer for gentoo selinux policy as well as upstream tresys refpolicy
> 
> >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.
> Ah, but therein seems to lie the rub for me: near as I can tell,
> there were some major changes made in how the policy is written
> somewhere around the late May/early June timeframe.  All of the
> documentation that I can find refers to the new framework, whereas
> the policy I'm using appears to be based on the old framework.  As a
> consequence, just about the time I think I'm starting to get a
> handle on what works how, I run into something that doesn't
> correspond to what the SELinux docs are telling me.
> 
> A good is example is refpolicy itself: the policy explained at the
> tresys site:
> 
> http://oss.tresys.com/projects/refpolicy/wiki/UseRefpolicy
> 
> Seems to be rather well thought ought, and reasonably logical and
> orthoginal.  It also seems to bear little resemblance to what I'm
> using.  The instructions for the tools that I come across seem to
> mostly reference things that don't even exist for me, or if they did
> exist would be absolutely useless to me because they are GUI tools,
> and my systems don't even have X installed.

As far is a know the structure is pretty much the same
> 
> I realize that a good deal of this is almost certainly due to the
> fact that I'm on Gentoo.  I'd much rather be part of the solution
> than part of the problem, so I want to get to where I can start
> helping with Gentoo's SELinux implementation, but I'm so blasted
> confused I don't even rightly know how to start.
> 
> As I've said previously, Gentoo SEEMS to be using policy and tools
> from RHEL 4's incarnation of SELinux.  That's all well and good,
> EXCEPT that the documentation describing the policies and tools
> seems to have gone wandering, so those of use poor schmucks stuck
> schlepping through the muck of the previous generation's tools have
> no clue where we are or where we are going, and since I don't even
> have the source for the policies that I AM using, I'm stuck with my
> finger up my nose going "Whuh?"

Well i am not sure but it is unlikely like El4. Any open source project should make the source available so it should be somewhere..

> And now, I think I've done enough whining for one day.  ;)
> 
> Once again, thanks for your time.
> 
> 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/20091203/0c19e053/attachment.sig>


More information about the fedora-selinux-list mailing list