ffmpeg
I’ve updated my SE Linux repository for Squeeze to include a modified version of the ffmpeg packages without MMX support for the i386 architecture. When MMX support is enabled it uses assembler code which requires text relocations (see Ulrich Drepper’s documentation for the explanation of this [1]). This makes it possible to run programs such as mplayer under SE Linux without granting excessive access – something which we really desire because mplayer will usually be dealing with untrusted data. In my past tests with such changes to ffmpeg on my EeePC701 have resulted in no difference to my ability to watch movies from my collection, the ones that could be played without quality loss on a system with such a slow CPU could still be viewed correctly with the patched ffmpeg.
$ mplayer
mplayer: error while loading shared libraries: /usr/lib/i686/cmov/libswscale.so.0: cannot restore segment prot after reloc: Permission denied
The AMD64 architecture has no need for such patches, presumably due to having plenty of registers. I don’t know whether other architectures need such patches, they might – the symptom is having mplayer abort with an error such as the above when running in Enforcing Mode.
The below apt sources.list line can be used to add my SE Linux repository:
deb http://www.coker.com.au squeeze selinux
dpkg
In my repository for i386 and AMD64 architectures I have included a build of dpkg that fixes bug #587949. This bug causes some sym-links and directories to be given the wrong label by dpkg when a package is installed. Usually this doesn’t impact the operation of the system and I was unable to think of a situation where it could be a security hole, but it can deny access in situations where it should be granted. I would appreciate some help in getting the patch in a form that can be accepted by the main dpkg developers, the patch I sent in the bug report probably isn’t ideal even though it works quite well – someone who knows absolutely nothing about SE Linux but is a good C coder with some knowledge of dpkg could beat it into shape.
In my repository I don’t currently provide any support for architectures other than i386 and AMD64. I could be persuaded to do so if there is a demand. How many people are using Debian SE Linux on other architectures? Of course there’s nothing stopping someone from downloading the source from my AMD64 repository and building it for another architecture, I would be happy to refer people to an APT repository that someone established for the purpose of porting my SE Linux packages to another architecture.
Policy
selinux-policy-default version 20100524-2 is now in Testing. It’s got a lot of little fixes and among other things allows sepolgen-ifgen to work without error which allows using the -R option of audit2allow – see my post about audit2allow and creating the policy for milters for defails [2].
I have uploaded selinux-policy-default version 20100524-3 to Unstable. It has a bunch of little fixes that are mostly related to desktop use. You can now run KDE4 on Unstable in enforcing mode, login via kdm and expect that everything will work – probably some things won’t work, but some of my desktop systems work well with it. I have to admit that not all of my desktop systems run my latest SE Linux code, I simply can’t have all my systems run unstable and risk outages.
Let me know if you find any problems with desktop use of the latest SE Linux code, it’s the focus of my current work. But if you find problems with chrome (from Google) or the Debian package chromium-browser then don’t report them to me. They each use their own version of ffmpeg in the shared object /usr/lib/chromium-browser/libffmpegsumo.so which has text relocations and I don’t have time to rebuild chromium-browser without text relocations – I’ll make sure it does the right thing when they get it working with the standard ffmpeg libraries. That said the text relocation problem doesn’t seem to impact the use of Chromium, Youtube doesn’t work even when the browser is run in permissive mode.
GNOME is a lower priority than KDE for me at this time. But the only area where problems are likely to occur is with gdm and everything associated with logging in. Once your X session starts up GNOME and KDE look pretty similar in terms of access control. I would appreciate it if someone could test gdm and let me know how it goes. I’ll do it eventually if no-one else does, but I’ve got some other things to fix first.
There is gdm of course (or more interestingly gdm3) but the software which is more likely to fail with SELinux is PolicyKit.
PolicyKit is installed on at least one of my KDE test systems (I noticed it causing some problems and fixed as many as I could – it may have had issues on other machines without me noticing) and seems to be working OK.
A couple of days ago I asked the following question on the SE Linux policy list and CC’d the Utopia package maintainers in Debian:
In Debian we have the file /usr/lib/policykit-1/polkit-agent-helper-1, does anyone know what it does and which of the types policykit_auth_exec_t, policykit_grant_exec_t, and policykit_resolve_exec_t should be assigned to it?
My problem in this regard is that the Debian PolicyKit seems to differ in some significant ways from the Red Hat version. This means that it’s not just a matter of copying what Red Hat are doing. Josselin, I would appreciate it if you could offer some advice in this regard.
PolicyKit 0.9 (which might be the one that has been tested in Red Hat) was architectured differently and has been removed.
For details about how PolicyKit 1 works, see http://hal.freedesktop.org/docs/polkit/
SELinux 11.3 no login to gnome possible in enforcing mode
Sorry of course SuSe 11.3
prelink -af
chcon –reference /etc/passwd /bin/sh
and
chcon –reference /etc/passwd /bin/bash
works, but is it a clean solution?
Florian: There is no way that /etc/passwd should have the same context as /bin/sh or /bin/bash.
Try “restorecon -R -v /etc /bin” and see what it does.
restorecon /bin brought me back to where I started:
** (gdm:2548): WARNING **: Couldn´t connect to system bus: An SELinux policy prevents this sender from sending this message to this recipient (rejected message had sender “(unset)” interface “org.freedesktop.DBus” member “Hello” error name “(unset)” destination “org.freedesktop.DBus”)
#setenforce 1
INIT: ID “1” respawning too fast: disabled for 5 minutes
Seems that SUSE and Gnome have a dbus Problem with policy.24. I will go on with modular policy and SysVinit Thanks for help