Archives

Categories

/run and SE Linux Policy

Currently Debian/Unstable is going through a transition to using /run instead of /var/run. Naturally any significant change to the filesystem layout requires matching changes to SE Linux policy. We currently have Debian bug #626720 open about this. Currently the initscripts package breaks selinux-policy-default in Debian/Unstable so that you can’t have initscripts using /run if the SE Linux policy doesn’t support it.

A patch has been suggested to the policy which uses a subst file, basically that causes the SE Linux labeling programs to treat one directory tree the same way as another. The problem with this is that it depends on a libselinux patch that is not in any yet released version of libselinux (and certainly won’t be in a Squeeze update). The upside of such a fix is that it would work for policy that I package as well as custom policy, so if someone wrote custom policy referring to /var/run it would automatically work with /run without any extra effort.

I think that the only way to do this is to just have regular expressions that deal with this in the file contexts. It’s a bit ugly and slows the relabel process down a little (probably no more than about 10%) but it will work – and work on Squeeze as well. One thing I really like to do is to have the SE Linux policy for version X of Debian work with version X+1. This makes upgrades a lot easier for the users. Ideally upgrading a server could be a process that involves separate upgrades of the kernel, the SE Linux policy, and user-space in any particular order – because upgrading everything at once almost guarantees that something will break and it may be difficult to determine the cause.

At this time I’m not sure whether I’ll add a new policy using the subs file before the release of Wheezy (the next stable release of Debian) or just keep using regular expressions. I can have the Wheezy policy depend on a new enough libselinux so it won’t be a problem in that regard (a new upstream version of libselinux with the subst feature should be released soon). In any case I need a back-port to Squeeze to use regular expressions to make an upgrade to Wheezy easier.

for n in $(find . -name "*.fc"|xargs grep var/run|cut -f1 -d:|uniq) ; do
  sed -e "s/\/var\/run/\/(var\/)?run/" < $n > $n.new
  mv $n.new $n
done
for n in $(find . -name "*.fc"|xargs grep var/lock|cut -f1 -d:|uniq) ; do
  sed -e "s/\/var\/lock/\/((var\/run)|(run)|(var))\/lock/" < $n > $n.new
  mv $n.new $n
done
for n in $(find . -name "*.fc"|xargs grep dev/shm|cut -f1 -d:|uniq) ; do
  sed -e "s/\/dev\/shm/\/((var\/run)|(run)|(dev))\/shm/" < $n > $n.new
  mv $n.new $n
done

I used the above fragment of shell code to change “/var/run” to “/(var/)?run”, “/var/lock” to “/((var/run)|(run)|(var))/lock”, and change “/dev/shm” to “/(var/run)|(run)|(dev))/shm”. It involves a reasonable number of changes to policy (mostly for /var/run), but hopefully this will be acceptable to the release team for inclusion in the next Squeeze update as the changes are relatively simple and obvious and the size of the patch is due to it being generated code.

There is one final complication, Squeeze currently has selinux-policy-default version 2:0.2.20100524-7+squeeze1, but initscripts in Unstable breaks versions <= 2:0.2.20100524-9. So I guess I could submit a proposed version 2:0.2.20100524-9+squeeze1 to the release team to fix this. I would really like to have the Squeeze policy work with initscripts from Unstable or Wheezy.

Any suggestions for how to deal with this?

Update:

I wrote the above before testing the code, and it turned out to not work. I’ve written another post describing a better solution that I have now uploaded to Unstable. I still have to sort something out with an update for Squeeze.

2 comments to /run and SE Linux Policy

  • It might (or might not) be more efficient to create separate rules for /run, /var/run, etc rather than using regular expressions.

    If you are worried about the size of the patch, then you could put the transformation into debian/rules instead of doing it in advance.

  • etbe

    Actually what I proposed in this post isn’t going to work. I’m writing a new post now about how to do it properly.