AVC Denials on UDEV

Wed Dec 2 23:13:41 UTC 2009

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.

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.

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

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

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?"

And now, I think I've done enough whining for one day.  ;)

Once again, thanks for your time.

Later,
Chris