Rambling around foo

When getting this error message:

bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule -i localresovconf.pp
libsepol.link_modules: Tried to link in a non-MLS module with an MLS base.
libsemanage.semanage_link_sandbox: Link packages failed
semodule: Failed!


You have to go back to the checkmodule step and type the same command, but add also the -M parameter:

bounty:~/usr/src/selinux/localpolicies/resolvconf# checkmodule -m -M -o localresovconf.mod *.te
checkmodule: loading policy configuration from resolvconf.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 6) to localresovconf.mod

After that is all OK:

bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule_package -o localresovconf.pp -m *.mod
bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule -i localresovconf.pp
bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule -l | grep localresolv
localresolvconf 1.0

Thanks Russell for the explanations on the execmem bits.

Now I am trying to go further and set up my system to really work with SELinux enabled because, although the promise of the targeted policy is to allow you to do your job mostly as you did before, that "mostly" has a really wide meaning, more than you'd think you bargained for.

Examples from my laptop: hald does not start by default (various denials), resolvconf is denied some getattr operations on tmpfs, hald-addon-dell-backlight is denied access to some character device I just know it should have access to, etc. Of course, this means that automatic mounting does not work anymore and there is a decrease in usability just because of the "mostly" part.

I am sure that some of the denials are correct (see the execstack stuff or the memexec), but there are cases where this "mostly" is stretched way too much. IMHO, desktop installs should suffer no restrictions when using the targeted policy (and I mean "no restrictions that would make my system less than it was before enabling and enforcing SELinux").


But let me tell a reason why SELinux sucks without any help from others:

The interface sucks big time.

Probably there is are good reasons, but if you need to create and use a new policy based on the denials found in the logs, you need to use no less than 4 (four) different tools with the right incantation (although you can use just 2, if you don't want to customize the rules[1]):

• audit2allow -m local -l
• checkmodule -M -m -o local.mod local.te
• semodule_package -o local.pp -m local.mod
• semodule -i local.pp

In the end, you still hit the bad interface:

bounty:~# semodule -i local.pp
libsepol.check_assertion_helper: assertion on line 0 violated by allow hald_t memory_device_t:chr_file { read };
libsepol.check_assertions: 1 assertion violations occured
libsemanage.semanage_expand_sandbox: Expand module failed
semodule: Failed!

Now what? That error message doesn't tell me much, except that some assertion failed. But where does the assertion come from? Why is it an assertion? What is bad about that line?
To me that really looks like an internal error or an inconsistency in what the SELinux tools generate.


[1] still, why advertise the longer path as the Fedora FAQ does? I would have done it the other way around.

If you enable and enforce the targeted policy in Debian and you use darcs you need to allow it to use execmem:

chcon -t unconfined_execmem_exec_t /usr/bin/darcs


This allows to overcome these denials:

type=AVC msg=audit(1191957463.678:108): avc: denied { execmem } for pid=14811 comm="darcs" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process

And get this ugly message:

$ darcs w -l
darcs: internal error: getMBlock: mmap: Permission denied
(GHC version 6.6.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted



Since oolite complained of the same issue I also ran this:
chcon -t unconfined_execmem_exec_t /usr/lib/GNUstep/System/Applications/oolite.app/oolite

---

Update: If you want to know the reasons why darcs (a VCS) to need execmem read the RedHat bugs related to this and the upstream bug report on GHC: https://bugzilla.redhat.com/show_bug.cgi?id=195820
https://bugzilla.redhat.com/show_bug.cgi?id=195821
http://cvs.haskell.org/trac/ghc/ticket/738

Disclaimer: I am 100% newbie on SELinux, so any inaccuracies, mistakes or fallacies are almost sure due to this fact.

After reading Russell's latest post on SELinux, and reading the 5 minutes tutorial on SELinux I decided I should try SELinux on my laptop, too.

Now I have it enabled/enforcing/permissive/refpolicy-targeted.

First issue, hal didn't start in my GNOME session, although the hal module appears to be loaded:

bounty:/emul/ia32-linux/usr/lib/dri# semodule -l | grep hal
hal 1.4.0


It seemed that gdomap indirectly required execstack. I cleared the execstack bit (or whatever it is) on libcallback.so.0.0.0 and libavcall.so.0.0.0 and gdomap started.

OTOH, oolite failed to start since it required execmem:

0 eddy@bounty ~ $ oolite
trampoline: cannot make memory executable
Aborted

And after allowing execmem it worked:
# setsebool allow_execmem=1

0 eddy@bounty ~ $ oolite
2007-10-09 01:42:04.686 oolite[26717] initialising SDL
open /dev/sequencer: No such file or directory
2007-10-09 01:42:04.789 oolite[26717] init: numSticks=0
2007-10-09 01:42:04.789 oolite[26717] CREATING MODE LIST
2007-10-09 01:42:04.789 oolite[26717] Added res 1024 x 768
...

I also seem to have some other denied messages, but I hope I'll understand this soon enough to make it work.

I would like to know if is possible to allow execmem only for oolite, and since I suspect it is, how can I accomplish this?

So, now my question is, where is the fine manual on setting SELinux? I digged the whole evening to get oolite to start.