| |||||||||||
The ExecShield patchesThe ExecShield patchesPosted Jul 19, 2005 19:33 UTC (Tue) by jwb (subscriber, #15467)Parent article: Kernel Summit 2005: The ExecShield patches
/dev/mem is only writable by root. If an attacker has root access, they can load modules which make /dev/mem writable or implements an entirely different device which serves the same purpose.
The other improvements all seems sensible.
(Log in to post comments)
The ExecShield patches Posted Jul 20, 2005 6:47 UTC (Wed) by dlang (subscriber, #313) [Link] however, currently the primary reason why building a monolithic kernel to preveent root from loading modules is the fact that root will have access to /dev/mem (or /proc/kmem) and can therefor fiddle with memory directly.
if access to those is cut off then people running especially security critical systems can build kernels that don't support loading modules AND don't support access to /dev/mem and gain a considerable amount of protection.
and face it, firewalls don't really need modules, they have a very static hardware configuration.
so I definantly see this as a useful option.
The ExecShield patches Posted Jul 20, 2005 7:27 UTC (Wed) by nix (subscriber, #2304) [Link] People running firewalls can already remove CAP_RAWIO from the kernel's capability bounding set, which bans reads and writes to /dev/mem. (Obviously, you have to grant an X server this capability, but there shouldn't be one of those running on a firewall anyway, really.)
The ExecShield patches Posted Jul 20, 2005 20:42 UTC (Wed) by dlang (subscriber, #313) [Link] unless ou are running selinux (which most distros don't do, and I definantly don't trust RedHat enough to use it on a firewall) I am not aware of an easy way to do this.
if there is one please let me know how.
Re: access to /dev/mem Posted Jul 22, 2005 1:47 UTC (Fri) by sweikart (guest, #4276) [Link] Here's a good description of it:
http://lwn.net/1999/1202/kernel.php3
And here's an implementation for dropping capabilities at boot time:
http://lists.nas.nasa.gov/archives/ext/linux-security-aud...
Since you can disable access to /dev/mem with the capability bounding set, I would request that the semantics of /dev/mem not change.
-scott
The ExecShield patches Posted Jul 22, 2005 12:39 UTC (Fri) by mingo (subscriber, #31122) [Link] 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.
Re: restricting access to /dev/mem Posted Jul 25, 2005 2:15 UTC (Mon) by sweikart (guest, #4276) [Link] Since you can already block access to /dev/mem in userspace (using the Capability Bounding Set; see my earlier post, which was posted about the same time as yours), I would request that the kernel not alter the semantics of access to /dev/mem .
Instead, distributors can drop the capability to access /dev/mem in their startup scripts (which can be modified by people who need to access /dev/mem, whether its for driver support or other reasons).
-scott
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."
|
|||||||||||