So yesterday’s post apparently got a little interest – mostly positive, insomuch as it’s realized that there are a few issues. But wait! There’s more! Call in the next 10 minutes and we’ll super extra double size your order!
Tonight, I decided to install a virtual machine containing a copy of the latest experimental Ubuntu (that’s known as “Ubuntu unstable”). To do this, I decided to install Hardy Heron via a CD image (bootstrap via ISO) and then perform an upgrade to the experimental release (dist-upgrade using apt). I downloaded a CD image from the MIT Media Lab using Firefox, then fed this into virt-manager. It failed, with a nice backtrace.
Now, this would seem to be the kind of activity that many people would want to undertake. Downloading images, booting them inside a virtual machine manager, and then using the resultant virtual machine image. But more than just that, what I wanted to do wasn’t exactly rocket science – skip the virtualization bit if that makes you think this is complex, I’m just talking about downloading a CD image and using it somehow.
The reason this activity failed was because of the SELinux configuration. The CD image Firefox had downloaded was in a temporary file download context, living in my Download directory, whereas virt-manager is not allowed to read from this kind of file until you’ve blessed it with a magical incantation of chcon. So, in this case, the “Microsoft Windows Vista” approach to security won out – get in the way so much that the user is quickly driven to distraction and inclined to turn it off. As I am, almost. After precisely one day of using SELinux in enforcing mode on a laptop (which has an encrypted disk and is only used by me) I’m about ready to throw it away…I’d hate to be an end user trying to manage this stuff.
No, this isn’t just like moving to UNIX permissions and groups. With the former, everything is well documented and widely understood already, but more importantly, there are nice tools to manage them. For example, right clicking on the file in the graphical file management application (nautilus) allows one to do many things, including viewing the SELinux context, but not actually changing this. I can’t find a nice pretty way for users to do this without having to grep through the policy files (to find out what the context should be) and then run other commands from the console. The point is, it’s a bit early in the game to have such complex policies with crazy numbers of contexts if users can’t easily manage this stuff. They need to be able to fix the problem too.
I tried to stop always blaming SELinux for everything by forcing myself to actually use it, but I’m beginning to regret this decision.
Jon.
SELinux is a mandatory access control model. Unlike traditional GNU Linux security which i based on a discretionary access control model. The point here is that in an SELinux environment policy is enforced upon users. User can see only the contextx that they are allowed to see, and users are only allowed to change types of objects that they are allowed to change context of.
I practise a user could change the context file type of their objects in home to a context file type of their objects in /tmp, and that is about all.
Once you start confining applications in the user space, users may be able to manage more in terms of changing types of objects but in this point it does not make sense to make a user app for these things.
For authorrzed personel there is semanage and its GUI system-config-selinux.
SELinux is powerful and flexible. It can make or break processes. But someone has to make security decisions.
I once made a joke about forking SELinux, reverse the way it works, and call it xuniles. Instead of denying everything unless policy is specified , everything would be allowed unless specified otherwise.
Of course i do not have a broad enough vision on this matter to make sound judgement.
SELinux is really two parts one part is the framework that enables all these pesky rules and the other part is that pesky policy. Many if not all comments are about selinux-policy since that is what processes are confronted with.
Ah, I think you’re missing two things:
*). I know what SE Linux is, and what it’s supposed to do. I’ve even read pieces of the kernel side implementation. I feel reasonably confident that I can moan
*). It’s not up to the “administrator” or “authorized personnel” to administer my laptop or home desktop system running Fedora. There is nobody else doing this in the vast majority of cases. Therefore, if you have to file a BZ with your distro every time you want to do something new (like open a VM on a different volume, and then also open a CD image too), you lose. If we’re going to have policy like this, it needs to be controllable with user-visible tools.
John,
Long time no see – I hope you’re well!
I suspect the point I’m about to make means I agree with you if I understand the point that you’re trying to make (if you see what I mean)!!
I’m a very firm believer in using the simplest tool possible to achieve the desired goals. In the case of your laptop – you have a single user system administered by an expert – therefore all the permissions models you currently require can be implemented using the standard unix security mechanisms. This situation is also not likely to change – you therefore have no need for the SELinux functionality and shouldn’t be using it. If I have a file server which thousands of people access daily then the permissions models will be more complex and SELinux may well be appropriate – its about having tools available to achieve the desired tasks.
The issues you’re seeing with SELinux are analogous to someone complaining that there Granny can’t drive an Articulated Lorry to the shops twice a week (or possibly that the engine from an artic doesn’t fit in her metro).
I think the point you’re making is that distributions shouldn’t turn on SE Linux by default. I guess I agree with that, but I think it depends more on what the distribution is targeted at. Whatever the default is, there should definitely be a simple and straightforward opt in/out at the point of installation.
I also agree that the support tools for SELinux suck – but then that’s why server ops get paid isn’t it?
One thing to keep in mind is the fact that ordinary users do not run virtual machines, Apache, or most of the other things that cause people to complain about SE Linux.
I’ve observed many people install and use SE Linux machines without knowing anything about it, their machine just works.
The amount of skill required to run virtual machines is significantly greater than the skill required to run Firefox. So if you have that skill then being able to determine how to get SE Linux to work with it (which at a last result only requires asking on a mailing list) should not be too difficult.
There are always trade-offs between security and usability. The fact that most users don’t notice it’s presence indicates to me that SE Linux is not unfriendly to users.
This is the reason why I have sealert -s as part of my startup in gnome-session-properties — in the situation like this (and yes, I haven’t managed to make virtual machines work in F9 with SELinux in the enforcing mode — BTW, what’s the bugzilla number of your bug?) I quickly see who is to be blamed for failure to do what I want to be done.
The user visible tool is setroubleshoot but it is useless by nature in my view since it can only inform users ( make users panic even more) . I’ve been opting for a kerneloops kind of daemon that takes care of this in the background.
First it should determine whether it is a missing TE rule or a disabled tunable / unset file type. If its a TE rule than it should only just ask a user if it can send the oops upstream. If it is a misconfiguration it should send the diagnose to root@localhost and tell a user to contact admin, or maybe prompt for a root password and or to auto configure or something…