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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
