cvs commit: src/sys/kern kern_prot.c

[Maxim Sobolev]

Robert Watson wrote:
> 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? 

Isn't SIGTHR(32) just ignored by any usual process out there? So that it 
should't create any new problems, unless process actualy knowingly uses 
this signal in which case it should know what it does. Am I missing 
something?

-Maxim