Date: Fri, 11 Feb 2005 23:13:07 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Maxim Sobolev <sobomax@portaone.com> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_prot.c Message-ID: <Pine.NEB.3.96L.1050211230255.12792A-100000@fledge.watson.org> In-Reply-To: <420D1F8D.3010103@portaone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050211230255.12792A-100000>