Sunday 28 October 2007

gpg signatures sent

I finally managed to resend the signatures to the few people I decided to send them a while back after debconf7.

I actually resent all the signatures I thought I should sign (if I didn't socialize at all with you during debconf or before you shouldn't receive a signature from me).

So, please:
  • sorry, if you get my signatures again; if so, ignore
  • don't be mad if you didn't receive a signed key from me, I probably don't consider I know you enough to do that yet ;-)
Now I can cross one more item on my long todo list. Yay!

This message has emerged thanks to: caff, dato, python's smtplib and rfc822, vi, gpg, exim, linksys, dell, todo(the application from openhand) and blogger :-)

Monday 15 October 2007

svn-buildpackage 0.6.22 released to experimental

Thanks to Damyan Ivanov for the upload, svn-buildpackage 0.6.22 is now in experimental. The upload was done to experimental due to the big number of changes affecting it and because I wanted to get a fairly significant amount of testing of the major fixes before propagating the code to unstable.

This release should fix 15 (yes, fifteen) bugs[0], most of which were important bugs or bugs affecting usability.

The major fixes are:
  • mkdir -p like functionality in the repo for the tags and other possibly missing directories - this means that even repositories created with older broken versions should be fixed automatically[1]
  • .svn/deb-layout is no longer a broken cache, but only a real local override for the layout information; .svn/deb-layout is created only on express request via --svn-savecfg; note that although .svn/deb-layout is no longer created automatically, old checkouts should be purged of this cruft (unless the override is wanted)
  • build dependencies are not required on --svn-export
  • automatic creation of the origDir when using origUrl
  • some code clean up
Installing the package on an etch, lenny or sid system should be straight forward: just get the deb from experimental and install it (no backporting is necessary).


If you usually use svn-buildpackage, please install the experimental version and report any bugs and/or success stories. I am particularly interested in feedback related to the behaviour around .svn/deb-layout and the other methods of specifying layout information.

Please send success stories to me directly eddy.petrisor @ gmail.com. Bugs should be directed to the BTS, but I hope there will be mail just directly to me :-) .


[0] I wonder, does the thickness of the yellow area on these graphs ever decreases?
[1] as soon as the breakage would have been visible in the past

Saturday 13 October 2007

SELinux: MLS/MCS support

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

Friday 12 October 2007

SELinux: unusable from a newbie perspective

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.

Tuesday 9 October 2007

selinux darcs policy; same for oolite

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

SELinux is enabled. Now what?

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.