Date: Sun, 13 Feb 2005 19:16:59 GMT From: Maxim Sobolev <sobomax@FreeBSD.org> To: avg@icyb.net.ua, sobomax@FreeBSD.org, emulation@FreeBSD.org Subject: Re: kern/72922: linux emulation: suid/sgid threaded applications hang Message-ID: <200502131916.j1DJGxSV047118@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
Synopsis: linux emulation: suid/sgid threaded applications hang State-Changed-From-To: closed->open State-Changed-By: sobomax State-Changed-When: Sun Feb 13 19:12:42 GMT 2005 State-Changed-Why: Sorry, but the solution is not that simple as it appeares. The following explains the complexity: 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 On Sun, 13 Feb 2005, Maxim Sobolev wrote: >> 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. I agree that the problem needs fixing, but I think this was entirely the wrong solution. Even if Linux processes expect the signal to have one set of semantics on the target, changing how it affects all processes isn't the right solution. Disabling a broad range of protections wasn't even necessary to accomplish this fix. I think enough information is present to do this check properly, and we should therefore do it properly. I would be happy to help review further patches to correct this problem. I also object to the name pedantic: we're not the only operating system to enforce these protections, and there have been specific vulnerabilities in the past of precisely this sort of protection are intended to address. Robert N M Watson On Sun, 13 Feb 2005, Maxim Sobolev wrote: >> Split out kill(2) syscall service routine into user-level and kernel part, the >> former is callable from user space and the latter from the kernel one. Make >> kernel version take additional argument which tells if the respective call >> should check for additional restrictions for sending signals to suid/sugid >> applications or not. Read: allow emulated binaries to bypass security checks. >> Make all emulation layers using non-checked version, since signal numbers in >> emulation layers can have different meaning that in native mode and such >> protection can cause misbehaviour. This is inaccurate. You've not only bypassed a broad range of desired security checks for linux processes against other linux processes, but you've also bypassed security checks from linux processes to any native FreeBSD process, essentially disabling the checks. I.e., if a machine is running with the linux ABI code, you've entirely disabled the checks for the system since an attacker will simply attack using the linux ABI if they want to attack using these signals. >> As a result remove LIBTHR from the signals allowed to be delivered to a >> suid/sugid application. s/LIBTHR/SIGTHR/ >> Requested (sorta) by: rwatson Not requested by: rwatson Was there a problem with the suggestion I made of adding an additional check in p_cansignal() beside the same check that says "if this is the same process, allow the signal" that understands linux thread leaders, that would permit the SIGTHR signal if two processes are in the linux thread group? The difference between p_cansignal() and cr_cansignal() is that cr_cansignal() authorized solely based on the subject credential, so can be used with cached subjects, and that p_cansignal() takes into account additional subject process and thread state to allow "special" signal cases permitted by virtue of that state. I.e., "processes can always signal themselves" and "SIGCONT is always permitted in the same session". Using this model you could specifically authorize use for linuxthreads and also threaded linux binaries, and avoid the remaining issues entirely. Please back out this change. Robert N M Watson http://www.freebsd.org/cgi/query-pr.cgi?pr=72922
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502131916.j1DJGxSV047118>