cvs commit: src/sys/kern kern_prot.c

[Robert Watson]

On Fri, 11 Feb 2005, Maxim Sobolev wrote:

>   Add SIGTHR (32) into list of signals permitted to be delivered to the
>   suid application. The problem is that Linux applications using old Linux
>   threads (pre-NPTL) use signal 32 (linux SIGRTMIN) for communication between
>   thread-processes. If such an linux application is installed suid or sgid
>   and security.bsd.conservative_signals=1 (default), then permission will be
>   denied to send such a signal and the application will freeze.
>   
>   I believe the same will be true for native applications that use libthr,
>   since libthr uses SIGTHR for implementing conditional variables.

I don't think this is the case -- libthr threading still uses a single
process, and delivers the signal to a thread in the same process bypassing
inter-process access control checks.  With libthr, it's not an operation
by one process on another, but by one thread on another thread in the same
process. 

Bypassing the SIGTHR checks for setuid processes, just seems like a bad
idea -- that's precisely the sort of internal process functionality that
shouldn't be exposed to potentially malicious attackers.  Maybe what's
needed is some new logic that says it's OK for SIGTHR to be used between
processes if they have the same process linux thread leader? 

Robert N M Watson