Re: restricting access to /dev/mem [LWN.net]

Re: restricting access to /dev/mem

Posted Jul 25, 2005 16:23 UTC (Mon) by sweikart (guest, #4276)
In reply to: Re: restricting access to /dev/mem by mingo
Parent article: Kernel Summit 2005: The ExecShield patches

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

(Log in to post comments)

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."