Re: PATCH: signals security

Rik van Riel (
Fri, 22 May 1998 01:17:05 +0200 (MET DST)

On Fri, 22 May 1998, Alexander Kjeldaas wrote:

> However, cap_used doesn't really do what you want. What you want is to
> know if you can reliably kill a process. You can kill it if (in this
> context) a process has not used CAP_RAW_IO _and_ don't have any open
> file descriptors inherited from a parent process which used
> cap_used as I hacked up doesn't take care of the last case. However,
> if we don't clear cap_used during fork, the process tree started by X
> will be permanently "dirtied". I think this is ok for your use.

I just checked, and X is just a leaf off of the xinit process
tree. We should be OK on this one.
However, we don't want the used rights from init and inetd
to be inherited by child processes, so we _do_ need some other
kind of check. Just checking the parent processes shouldn't be
too difficult...

> It all depends on what you want to know about a process.

I just need to know if I can kill a process without
messing up some hardware device :-)

> I've attached a new patch which has a cap_used as well as cap_dirty
> capabilities. cap_dirty should be what you check against since it will
> be inherited by fork().

OK, I'll save the message and generally keep it in mind.

> When the device is open()ed, the kernel should check whether the
> process has the CAP_RAW_IO capability. If it doesn't, it's a bug
> (unless the frame-buffer isn't "raw" access to hardware on m68k in
> which case it would be ok to kill the X-server).

This is just what I thought. Some confirmation is always nice :-)
(sorry 68k people, you are now in jeopardy of losing your X server
when someone forks off a memory bomb)

| Linux: - LinuxHQ MM-patches page | Scouting webmaster |
| - kswapd ask-him & complain-to guy | Vries cubscout leader |
| | <> |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to