So I’ve been writing about a couple of weeks as a user of SELinux on Fedora. I thought I’d give an update about the experience.
After a week as a user of SELinux in enforcing mode, I had learned a few things. I had learned that it isn’t always possible (without using command line utilities) to download a CD image and use it to install a virtual machine, or to use an alternate location for virtual machine images, and a number of other (minor) issues. By this, I mean that none of these things can be done trivially by end users or developers who don’t know about commands like chcon, and their use. To many end users, this simply means these (seemingly quite straightforward) activities are now “impossible”, since they simply will not properly understand why they are not working in the way they had intended. In this case the appearance of us being secure has trumped over general functionality.
Late last week, I decided to allow my laptop to apply the latest Fedora updates. I rebooted into the updated environment (new kernel image) and tried to connect to my corporate VPN using VPNC. Although it was able to connect, the connection script generated repeated errors trying to run commands like “ip” and “ifconfig”. So, I spent roughly 6 hours on Sunday night reading SELinux documentation, books, whitepapers, commands, and the Fedora SELinux “targeted” policy itself. I concluded that the update had disallowed the VPNC domain access to the sysnetwork domain in which those various networking commands exist.
Without getting into specifics too much (BZ453236 has my analysis attached), NetworkManager is able to start VPNC because it runs in a system context (which has a specific policy item to allow access to network commands), whereas regularly started tty incantations of VPNC will run unconfined. In that case, audit2allow suggested adding:
role unconfined_t types ifconfig_t
Which was actually in a pending update to the policy (it hadn’t made the changelog so I hadn’t noticed it when skimming recent koji builds). I installed the new build, and lo-and-behold my VPNC worked again. I wasn’t particularly bothered by this experience – I learned a lot about SELinux policy, the different files, and how it all goes together that I’m sure has changed since I looked at this stuff nearly a decade ago. But I’m not blogging about this because of me, I’m thinking about the end-user experience. The user facing this problem might have filled a Bugzilla, and they might even have realized this was due to SELinux (no AVC denial messages given) and tried fixing the problem for themself. But they probably instead decided that something was broken with Fedora and just went away frustrated. Security trumped over functionality of a generic laptop system.
All I can do is hope that, in time, the community will realize the many uses that SELinux has, and the many that it does not. It’s great if you work for the NSA, have lots of servers to protect from the Interwebulous Tubes of the Internet, or are just a paranoid type. In those cases, SELinux has many advantages – especially if you’re running a timesharing system and distrust all of your users, to varying or equal amounts. This is one of many compelling justifications for SELinux to exist in Enterprise Linux products, and as an optional installation item on various other spins of Fedora – for example, for server targets. These are also good reasons to offer end users the option of turning on SELinux, if they desire.
But for the average Desktop user (you know, the type that we, as a community occasionally like to encourage…) SELinux often ostensibly gets in their way. You don’t have to choose to believe this if you don’t want to, but it can’t be managed graphically (that’s where most people will give up), the policy is highly complex (I’ve read bits of it), and what exactly does the average laptop user sitting behind a firewall with only a few non-external-facing Desktop applications need it for anyway? To protect them from themself? In case the guy in Starbucks is a l33t h4×0r? To protect them from a relatively minor subset of possible security attack vectors unlikely to be used against them at home? I’m still waiting to be convinced that it should *always* be on by default.
As a final note, remember that I’m not criticizing the Fedora community, SELinux developers, or other individuals. I’m saying that the end user experience is lacking in a few fixable ways. Mainly by bringing back an obvious option during installation that explains why Fedora offers this feature, and gives users who don’t want it a choice of turning it off.
Jon.
I appreciate your views. However chcon is part of coreutils like chmod and chown it has a manual page (8). Users do not run guest systems. Super users or power users do. Power users use system-config-selinux to label any objects and use restorecon to restore file objects to their types.
Why would a owner of a computer use SELinux at home? Simple, not primarily to protect himself from haxxors or even himself…. but also to protect himself or any other people that trust their personal belonging to your system, from buggy/rogue applications. More generally any system abnormalities.
I agree that there is still much room for improvement but i am confident that SELinux is beneficial for everyone.
I do not really know other peoples opinion on what a ‘user’ or a ‘fedora user’ is. I consider my mother a Fedora user. She’s running SElinux enforced and works in the confined user domain. I admit, she complained when she could not watch her favorite tv channel in big screen in firefox/nsplugin totem. I just told her it was just another error like so often happens and that people are working to solve any issue. A few weeks later the issue was cprrected just like i predicted and everything else works just fine. BTW my grandma runs Fedora in enforcing mode aswell. She is the user and i am the power user that is assuming administrator responsibilities over her system.
So, you’re administrating these systems…in that case these are non-typical end-user installs. Just because you understand when SELinux is breaking functionality, doesn’t mean these users would figure this out on their own.
Manual pages, command line utilities, and “power” tools do not make a system usable for end users. Most of them do not need SELinux to protect them from rogue applications – a bug in the kernel or in a millions of lines of code not protected by SELinux will still tear down the system.
Jon.