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