cvs commit: src/sys/kern kern_prot.c

[Maxim Sobolev]

Robert Watson wrote:
> On Fri, 11 Feb 2005, Maxim Sobolev wrote:
> 
> 
>>>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? 
> 
> 
> Signals are used in four kinds of ways: 
> 
> - Notification of exceptional error conditions in thread instruction flow,
>   such as divide by zero, floating point problems, illegal
>   instruction, page fault, etc.
> - Notification of thread/process events for the management of process
>   state, such as asynchronous signals for I/O, timers, pipe errors, thread
>   events.
> - Notification of system conditions and events, such as exceeding CPU
>   quotas, death of child process, tty state changes, etc.
> - Inter-process communication, such as SIGQUIT, SIGUSR1, and so on.
> 
> In general, the first two categories of signals are ones that programs
> have semantic expectations for -- they're signals they may catch in order
> to perform error processing, instruction cleanup, user space paging,
> wakeups, I/O callbacks, etc.  And they're ones where you typically don't
> want them getting delivered in ways that violate program assumptions, as
> it can result in security vulnerabilities.  I.e., it's a odd property of
> the UNIX signal semantics that they can be delivered from other processes,
> and they're often handled poorly.  The additional protection is provided
> so that in the event that the implementation of handling the signals is
> poor when the "signals should never be generated", we try to avoid
> privilege escalation.  SIGTHR is definitely in this category -- if you
> have a threaded setuid app, you don't want external unprivileged
> applications messing with its thread state, right?  This is the theory
> under which the other signals are also blocked for setuid processes: you
> don't want attacking processes to frob the I/O state, and so on.

I see. I've just committed a change which solves this problem by 
allowing emulation layers to bypass FreeBSD-specific security checks 
during signal delivery. This makes sense since emulation layers can have 
different meanings for signals and/or different security restrictions.

-Maxim