Date: Sun, 13 Feb 2005 18:49:34 +0200 From: Maxim Sobolev <sobomax@portaone.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_prot.c Message-ID: <420F851E.2090108@portaone.com> In-Reply-To: <Pine.NEB.3.96L.1050211230255.12792A-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1050211230255.12792A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?420F851E.2090108>