Zack's Kernel News

Loading and Unloading Security Modules After Bootup

Sargun Dhillon recently posted some code to allow Security-Enhanced Linux (SELinux) to load and unload Linux security modules (LSMs) after bootup. He implemented this in the form of hooks in the callback chain. A callback chain is a way for code to get a look at how it was called, to determine whether it's running in one context or another. Depending on the context, a given piece of kernel code might behave differently.

Sargun's hooks were not new features. Hooks are general-purpose programming constructs for triggering certain actions at certain times, but his code added the capability to load and unload arbitrary security modules after bootup.

Tetsuo Handa offered some technical suggestions and a patch to apply on top of Sargun's code, mostly renaming things, restricting the scope of some variables, and making other minor changes. However, he also felt that Sargun's hooks could be misused so as to produce unexpected results – specifically, in the case where the user configured a module to no longer be unloadable, but then tried to unload it anyway. To prevent this, Tetsuo ripped out the run-time module-unloading code.

Sargun felt that it might be better to keep the code and instead produce bug alerts and warnings if the user tried something like that, since it would essentially be user error at that point anyway. But Tetsuo felt, in this case, warnings wouldn't be enough. If the user wanted to unload a security module, but was unable to, even if it was their own fault, the situation should trigger a kernel panic and crash the system.

Sargun found the situation interesting and still had doubts. He asked what the SELinux folks themselves would prefer. He said, "What do you think the behavior should be? If allow_unload_modules/allow_unregister_module is set, do you want to be able to call security_delete_hooks? What do you think the right action should be if it fails?"

Stephen Smalley of the NSA said the primary goal should be to avoid changing the behaviors expected by existing users. In other words, a kernel panic would not be best, nor would removing the module unloading code. He explained:

I personally am in favor of killing SELinux support for run-time disable aka CONFIG_SECURITY_SELINUX_DISABLE; the only reason it exists is that Red Hat originally insisted that bootloader configuration is too painful to modify/update on certain platforms and therefore the selinux=0 boot parameter is insufficient as a mechanism for disabling SELinux.

However, we can't break existing users. User space should still attempt to proceed even if run-time disable fails, just with SELinux left in permissive mode and no policy loaded. That generally should work, but does retain the performance overhead of the SELinux hook function processing, unlike a real disable.

I don't think we particularly care about allow_unload_modules/allow_unregister_module since there is no existing user space or configurations relying on it.

Paul Moore said he also favored removing the SELinux run-time disable code, but he said it wasn't a trivial operation and had a bunch of technical prerequisites before it could be considered, which made it a non-trivial problem.

The discussion ended there. It's not much of a debate, although there were three opposing viewpoints in the discussion. In this particular case, there seems to be support for the overall goal of letting the user load and unload security modules after bootup and also to prevent those things in certain cases, but there are a few little details constraining the exact way the features must be implemented and the way in which they might change over time, as other problems fall away.

An interesting element is the effort to put control directly in the hands of the user. This is in contrast to other "security" projects, which try to put control in the hands of the product vendor and specifically exclude users from altering their systems after bootup.

Splitting Up Security Projects

Sometimes security patches are clandestine efforts to take control away from the user and put it in the hands of the vendor; sometimes they only seem to be trying to do that.

David Howells recently posted some patches to "lock down" the kernel, preventing it from being changed in any way. With his code, it would be possible to stop users from loading and unloading modules, suspend the system to disk, access /dev/mem or various registers, or perform direct memory access (DMA). From the user's perspective, he added two new config options – one to allow the user to lock down the kernel or end a lockdown, and the other to make lockdown mandatory and irreversible until the next boot sequence. He added, "if lockdown mode is enabled, the kernel will not be able to use certain drivers as the ability to manually configure hardware parameters would then be prohibited. This primarily applies to ISA hardware devices."

There were a few technical comments and suggestions, and Linus Torvalds also came into the discussion, pointing out his own problems with the direction of this particular area of the kernel. He said:

I think many of these things should simply be done as separate config options.

For example, if the distro is sure that it doesn't need /dev/mem, then why the hell is this tied to "lockdown" that then may have to be disabled because other changes may not be acceptable (e.g., people may need that device DMA, or whatever).

If that /dev/mem access prevention was just instead done as an even stricter mode of the existing CONFIG_STRICT_DEVMEM, it could just be enabled unconditionally.

So none of these patches raise my hackles per se. But what continues to makes me very, very uncomfortable is how this is all tied together.

Why is this one magical mode that then – because it has such a big impact – has to be enabled/disabled as a single magical mode and with very odd rules?

I think a lot of people would be happier if this wasn't so incestuous and mixing together independent things under one name and one flag.

He added:

I would seriously ask that the distros that have been using these patches look at which parts of lockdown they could make unconditional (because it doesn't break machines), and which ones need that escape clause.

He went on:

I get the feeling that not a lot of people have actually been testing this, because "turn off secure boot" is such a universal thing when people boot Linux.

So it's really the whole claim that distributions have been running for this for the last five years that I wonder about, and how often people end up being told: "just disable secure boot."

But if people really don't need DEVMEM/DEVKMEM/DEVPORT, maybe we should just disable them in the default configs and consider them legacy.

I'm just surprised. I suspect a lot of people end up actually using devmem as a fallback for dmidecode, etc. Maybe those people don't boot with EFI secure mode, but if so that just shows that this whole "hardening" is just security theater.

In terms of how many people were just told to disable secure boot, Justin Forbes said (somewhat vaguely), "Very rarely in my experience. And the one time that we sent a kernel to updates testing that was signed with the test key instead of the real key, we had a surprisingly high number of reports from users that it was broken before the update even got synched to mirrors. So we don't have actual numbers of users running active secure boot with Fedora, but we do know it is more than we expected. The majority of people who do run into issues are those running out of tree modules, who haven't imported any sort of key for local signing. This isn't like SELinux was at launch where it was so invasive that a large number of users instinctively turned it off with every installation; I would guess even people who turned it off in the past don't even think about it when they get a new machine and leave it on."

Regarding the possibility of splitting the config options up into separate items, he added, "it might make sense to add separate config options for each of these pieces, which can be unconditionally enabled, and a separate option for secure boot, which selects all of them?"

Linus replied, saying again that he'd love to deprecate /dev/{mem,kmem,port} if possible. If they could be separated from the rest of these patches and simply left off, then, Linus said, "they'd stay disabled even if somebody cannot handle the other limitations, like DMA, etc."

This seems to be a case where features that seem to be attempts to lock users out of controlling their own system may simply be legitimate security patches, and by splitting the config options out into separate pieces, the kernel will in fact put more control in the hands of the user, who would then be able to make fine-grained decisions about what their particular setup needs and does not need. This would also theoretically put an end to the grinding debates over lockdown and secure boot, which have pitted developers against kernel maintainers for a while now. If these macro-features are designed as multiple smaller options, it might be relatively easy to decide the fate of this or that individual option, rather than wrangle over a given project as a whole.

The Author

The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • SELinux

    SELinux provides a comprehensive Mandatory Access Control system for Linux, if you are ready for all the details.

  • Kernel News

    Zack Brown discusses preventing the kernel from tainting, encrypting printk() output, and a new kernel bug reporting bot. 

  • SE Linux

    SELinux provides a safer system through the powerful concept of mandatory access controls.

  • Security Bugs in Kernel and Rsync

    Security researchers at Secunia have reported two security bugs in the Rsync synchronization tool and one in the current Linux kernel.

  • Kernel Tips

    Worried about a recent security exploit? Want to take advantage of a new hardware feature? You don’t need to be a Linux expert to patch and compile the Linux kernel. We'll show you how to get started.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

News