| |||||||||||||
Re: restricting access to /dev/memRe: restricting access to /dev/memPosted Jul 25, 2005 6:38 UTC (Mon) by mingo (subscriber, #31122)In reply to: Re: restricting access to /dev/mem by sweikart Parent article: Kernel Summit 2005: The ExecShield patches
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.
(Log in to post comments)
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."
|
|||||||||||||