Messages in this thread | | | Date | Thu, 21 May 1998 18:12:20 +0200 | From | Alexander Kjeldaas <> | Subject | Re: PATCH: signals security |
| |
On Wed, May 20, 1998 at 02:35:32PM +0200, Rik van Riel wrote: > > Let me summarize: > - you want to disallow SIGKILL to processes which do raw I/O > - so you check for the suid() bit. > > This is obviously _not_ correct, since: > - raw I/O will be a capability CAP_RAW_IO > - root may have some raw-I/O programs that are _not_ suid, > since root is the only one who is allowed to use the program > > You are probably better off using some of the code in > my Out-Of-Memory killer. It checks: > - whether the x86 I/O bitmap has been set up > - whether the process has raw I/O capability (CAP_RAW_IO) > > Now we probably want to modify the ioperm() and iopl() > syscalls to set CAP_RAW_IO, so we can do an easy arch > independant check. > (the capability itself is in the allowed bitmap and > it should only be set in the current bitmap when it's > actually used)
I'm not sure I understand. Capabilities shouldn't just be set. We already have the PF_SUPERPRIV flag which is set whenever a process _uses_ root privileges. It would be more natural to define a PF_RAWIO flag similar to PF_SUPERPRIV (or if needed, a complete set of 'have used CAP_xxx' flags). In the PF_RAWIO case, you probably want to make sure that you handle inherited open file-descriptors as well. Remember, you can have rawio access without having CAP_RAW_IO if you inherit a file descriptor. Actually, all normal svgalib-application have rawio access without having CAP_RAW_IO since they normally do a setuid() after a short initialization sequence.
Another point, a bit unrelated to the discussion is that a capability called CAP_SIGMASK exists in the draft standard. It allows a program to mask unmaskable signals. It isn't in the vanilla kernel yet.
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |