cvs commit: src/sys/kern kern_prot.c

[Robert Watson]

On Sun, 14 Sep 2003, Alfred Perlstein wrote:

> * Robert Watson <rwatson at FreeBSD.org> [030914 00:23] wrote:
> > rwatson     2003/09/14 00:22:39 PDT
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     sys/kern             kern_prot.c 
> >   Log:
> >   
> >   Also, add SIGALRM to the set of signals permitted to be delivered to
> >   setugid processes by unprivileged subjects.
> 
> why? 

Because of a specific report of breakage: in this case, for the Diablo
news server.  The details of the report are that Diablo starts running as
root, and then changes to another after binding ports, etc.  That pool of
worker processes will signal itself using SIGALRM -- however, each process
also has P_SETUGID set on it because it has undergone a credential
downgrade (and therefore may be able to leak information or capabilities
acquired when running with elevated privilege).

I thought about this one for quite a while, because I thought it was a
pretty hard call to make. When I introduced the signal delivery
limitations in the context of P_SETUGID, I walked the list of signals to
attempt to separate them into a list of signals used for IPC, vs a list of
signals used to raise exception conditions in the application.  In that
initial list, I assigned SIGARLM to the exception case, since it is
usually generated as a result of a system service, alarm() or setitimer().
However, it was then brought to my attention that SIGALRM is a common
choice for an overflow IPC signal when SIGUSR1 and SIGUSR2 are already
assigned.  It's worth noting that, in my research on the issue, I
discovered that Theo had made a similar change to the OpenBSD signal check
code in June, 2002.

A reference to the Diablo thread in question is here: 

  http://www.mail-archive.com/freebsd-current@freebsd.org/msg60727.html

I'm still a little uncomfortable with the outcome, but I also recognize
that the narrowing down of signal delivery I performed has the potential
to negatively impact application operation.  The other alternative, FYI,
is for us to work more closely with application developers to discourage
this approach to IPC.  Diablo is the first case I've come across where
these limits have negatively affected normal application operation --
usually, bizarre use of signals is limited to the operator in controlling
a process, not used between processes that have downgraded credentials.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories