Re: PATCH: signals security
Alexander Kjeldaas (astor@guardian.no)
Fri, 22 May 1998 01:41:05 +0200
On Fri, May 22, 1998 at 01:17:05AM +0200, Rik van Riel wrote:
> 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_RAW_IO.
> >
> > 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...
I just realized that it would be wrong to export cap_dirty through
/proc since it makes it possible to get information you shouldn't have
access to about other processes (such as what capabilities init has
used).
So cap_dirty should only be used internally by the kernel. If the
kernel bothers, and it is possible for a given capability, it can
"untaint" cap_dirty during exec (or at any other time for that matter
- close() for example). The "washing" would be the "other kind of
check" you mention.
However, I'm not sure whether this cap_dirty thing is generally
useful, or whether all that is needed is a special-case for
CAP_RAW_IO. Generalizing it through cap_dirty, however is probably as
simple as a patch implementing a single PF_RAWIO flag.
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