The ExecShield patches [LWN.net]

The ExecShield patches

Posted Jul 22, 2005 12:39 UTC (Fri) by mingo (subscriber, #31122)
In reply to: The ExecShield patches by jwb
Parent article: Kernel Summit 2005: The ExecShield patches

signed modules (an upcoming feature) will prevent the loading of 'rouge' modules.

You are right in that the weakest link determines the strength of the chain, but this does not mean we should not strengthen other links even if we know that they are not the weakest link. Once that final link is strengthened too we'll see a sudden jump in strength.

so i agree that in isolation, restricting /dev/mem is like closing the door but leaving the window open. I'd like to reassure you that we are closing the windows too :)

on a sidenote, rootkits do prefer /dev/mem over module insertion, because it's "more stealth". And not only is it more stealth, it's also more robust: by checking the actual kernel image a rootkit can make it reasonably sure that it has the right kernel version - while with modules you either have the correct symbol map or you dont, and in the latter case the attacker can easily crash the system and raise attention. The most dangerous attackers prefer stealth over all - so that their unique methods stay hidden.

another sidenote is that if you cook your own kernel (which secure sites sometimes do), you can disable module support.

(Log in to post comments)

Re: restricting access to /dev/mem

Posted Jul 25, 2005 6:38 UTC (Mon) by mingo (subscriber, #31122) [Link]

You missed the following detail: we do not want to and cannot restrict access to /dev/mem in a total way, because X.org needs it to map the BIOS and/or the framebuffer. Hence the careful filtering of access, instead of blanket turning off. On those systems where X.org needs no access to /dev/mem at all (they are quite rare) we can turn it off permanently, but this does not solve the problem for all the other systems.

Re: restricting access to /dev/mem

Posted Jul 25, 2005 16:23 UTC (Mon) by sweikart (guest, #4276) [Link]

But I don't think the kernel should enforce *any* specific policy on access rights to /dev/mem; I think this policy should be left to userspace (which can drop the SYS_RAWIO capability from the Capability Bounding set, using /proc/sys/kernel/cap-bound). Other drivers and applicatins (including mine :-) need access to /dev/mem during the boot sequence, and we can drop SYS_RAWIO when we're done.

So, my proposal is that the kernel not enforce access rights. Instead, the distributors can drop SYS_RAWIO in their boot scripts, and people (like me) who need temporary access to /dev/mem can modify the boot scripts as needed.

-scott

Re: restricting access to /dev/mem

Posted Jul 25, 2005 18:26 UTC (Mon) by mingo (subscriber, #31122) [Link]

Let me repeat it again: the problem cannot be solved via the SYS_RAWIO privilege or any other flat privilege bit. We dont want to give blanket /dev/mem access _even to processes that are allowed to read/write the safe portions of it_ (i.e. X.org).

(Furthermore, the kernel is perfecly right in enforcing that what is written/read in /dev/mem actually makes sense and doesnt corrupt the kernel itself.)

Re: restricting access to /dev/mem

Posted Jul 25, 2005 21:01 UTC (Mon) by sweikart (guest, #4276) [Link]

> We don't want to give blanket /dev/mem access _even to processes
> that are allowed to read/write the safe portions of it_
> (i.e. X.org).

I agree, I don't want to do this either. That's why I drop SYS_RAWIO (and CAP_SYS_MODULE, CAP_SYS_ADMIN, etc) in my boot scripts.

>> (Furthermore, the kernel is perfecly right in enforcing that what
> is written/read in /dev/mem actually makes sense and doesnt
> corrupt the kernel itself.)

That's a good point. Here's my dilemma.

On my secure servers, I drop *all* capabilities in the Capability Bounding Set, and drop most process capabilities in most daemons. So, how do I change a daemon's process capabilities?

capsetp(3) tells you that "the only processes that have CAP_SETPCAP available to them are processes started as a kernel-thread", and that "you will need to recompile the kernel to modify this default". Since I want my server operators to be able to install distributor's kernel RPMs, recompiling the kernel doesn't work for me.

So, I wrote a (GPL'ed) command that opens /dev/mem and raises CAP_SETPCAP in cap_bset (the kernel variable that holds the system's Capability Bounding Set), forks, restores cap_bset, then raises CAP_SETPCAP in its parent process capability set (so the parent can change other processes). This command won't run on my Fedora Core workstation, because of ExecShield.

I've thought a little bit about how the kernel could safely make CAP_SETPCAP available to userspace. By default, you don't want any userspace processes (or the Capability Bounding Set) to have CAP_SETPCAP raised; that's too big a change in the normal security model. My idea would be to create an enable-CAP_SETPCAP option for init, that would be placed into the initdefault entry in /etc/inittab; if this option doesn't exist, then init would drop CAP_SETPCAP (in the Capability Bounding Set and in its own process capability set) before it creates any other processes.

-scott

Re: restricting access to /dev/mem

Posted Aug 9, 2006 2:12 UTC (Wed) by bluefoxicy (guest, #25366) [Link]

>> We don't want to give blanket /dev/mem access _even to processes
>> that are allowed to read/write the safe portions of it_
>> (i.e. X.org).
>
>I agree, I don't want to do this either. That's why I drop SYS_RAWIO (and >CAP_SYS_MODULE, CAP_SYS_ADMIN, etc) in my boot scripts.

What Ingo is saying is he wants to do like grsecurity does and block access to /dev/mem EXCEPT for video memory. Xorg would be able to mmap() video memory in through /dev/mem; but it wouldn't be able to touch kernel memory through the same interface.

grsecurity does this so at worst an attacker can hijack X and totally screw up your video and maybe crash your system in the process (touching the video card wrong is BAD); they're just learning from really good example. It's a much more fine-grained model than CAP_SYS_RAWIO because it's not straight "you can have /dev/mem or you can't."