From nobody@FreeBSD.org  Wed Oct 20 12:03:10 2004
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 9707816A4CF
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 20 Oct 2004 12:03:10 +0000 (GMT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8A41543D62
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 20 Oct 2004 12:03:10 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i9KC3APs096509
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 20 Oct 2004 12:03:10 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.11/8.12.11/Submit) id i9KC3Aff096506;
	Wed, 20 Oct 2004 12:03:10 GMT
	(envelope-from nobody)
Message-Id: <200410201203.i9KC3Aff096506@www.freebsd.org>
Date: Wed, 20 Oct 2004 12:03:10 GMT
From: Andriy Gapon <avg@icyb.net.ua>
To: freebsd-gnats-submit@FreeBSD.org
Subject: linux emulation: suid/sgid threaded applications hang
X-Send-Pr-Version: www-2.3

>Number:         72922
>Category:       kern
>Synopsis:       linux emulation: suid/sgid threaded applications hang
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    emulation
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Oct 20 12:10:31 GMT 2004
>Closed-Date:    Sun Mar 06 22:06:09 GMT 2005
>Last-Modified:  Fri Mar 18 09:50:02 GMT 2005
>Originator:     Andriy Gapon
>Release:        5.2.1-RELEASE-p11
>Organization:
>Environment:
5.2.1-RELEASE-p11 i386
linux_base-7.1_7
linux_devtools-7.1_3
>Description:
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.
Please see
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13492+0+archive/2004/freebsd-emulation/20041017.freebsd-emulation
for an example and detailed investigation of such case.
>How-To-Repeat:
using the same environment as mine 
1. make any threaded linux application suid
2. run it so that it really changes privileges
3. see it freeze
>Fix:
1. either add signal 32 (linux SIGRTMIN) to list of "common signals" in cr_cansignal()
2. or detect the described situation in cr_cansignal() and produce a 
warning message explaining the situation and suggesting setting 
security.bsd.conservative_signals=0
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->emulation 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sun Oct 24 00:46:06 GMT 2004 
Responsible-Changed-Why:  
Over to mailing list. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=72922 
State-Changed-From-To: open->closed 
State-Changed-By: sobomax 
State-Changed-When: Fri Feb 11 14:03:14 GMT 2005 
State-Changed-Why:  
Fix comitted, thank you for reporting! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=72922 
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: 



From: Maxim Sobolev <sobomax@portaone.com>
To: freebsd-gnats-submit@FreeBSD.org, avg@icyb.net.ua
Cc:  
Subject: Re: kern/72922: linux emulation: suid/sgid threaded applications
 hang
Date: Sun, 20 Feb 2005 19:21:28 +0200

 Andriy,
 
 Can you please test the following patch and let me know if it help or not.
 
 http://www.pbxpress.com/~sobomax/72922.diff
 
 -Maxim
State-Changed-From-To: open->closed 
State-Changed-By: sobomax 
State-Changed-When: Sun Mar 6 22:05:43 GMT 2005 
State-Changed-Why:  
Should be fixed in the recent -current. Please test and let me know if the 
problem persists. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=72922 

From: Andriy Gapon <avg@icyb.net.ua>
To: Maxim Sobolev <sobomax@portaone.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/72922: linux emulation: suid/sgid threaded applications
 hang
Date: Wed, 09 Mar 2005 11:40:54 +0200

 on 20.02.2005 19:21 Maxim Sobolev said the following:
 > Andriy,
 > 
 > Can you please test the following patch and let me know if it help or not.
 > 
 > http://www.pbxpress.com/~sobomax/72922.diff
 
 Maxim,
 sorry that it took me so long to try this patch, I could do reboot only
  on the past weekend and, ufortunately, this patch didn't fix the
 problem with MQ, strmqm command still hangs if conservative_signals=1. I
 am not sure if you commited exactly this patch or something different in
 current (unfortunately I am not able to test current), but this patch
 apparently does not work in this particular case. I am not sure if I
 will be able to help you with debugging kernel stuff (linux kld - most
 probably yes, kernel - most propbably not), but I can definitely provide
 you information about this particular program, strmqm, if you need it
 and if you tell me what to check for.
 
 -- 
 Andriy Gapon

From: Maxim Sobolev <sobomax@portaone.com>
To: Andriy Gapon <avg@icyb.net.ua>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/72922: linux emulation: suid/sgid threaded applications
 hang
Date: Wed, 09 Mar 2005 11:59:48 +0200

 Andriy Gapon wrote:
 > on 20.02.2005 19:21 Maxim Sobolev said the following:
 > 
 >>Andriy,
 >>
 >>Can you please test the following patch and let me know if it help or not.
 >>
 >>http://www.pbxpress.com/~sobomax/72922.diff
 > 
 > 
 > Maxim,
 > sorry that it took me so long to try this patch, I could do reboot only
 >  on the past weekend and, ufortunately, this patch didn't fix the
 > problem with MQ, strmqm command still hangs if conservative_signals=1. I
 > am not sure if you commited exactly this patch or something different in
 > current (unfortunately I am not able to test current), but this patch
 > apparently does not work in this particular case. I am not sure if I
 > will be able to help you with debugging kernel stuff (linux kld - most
 > probably yes, kernel - most propbably not), but I can definitely provide
 > you information about this particular program, strmqm, if you need it
 > and if you tell me what to check for.
 
 Hmm, that's pretty strange. Can you please fetch the following Linux 
 binary, make it suid root and try to run as ordinary user on your 
 system? I've used it to verify that my patch is in fact works - after 
 the change has been made it stopped hanging at my system.
 
 http://www.pbxpress.com/~sobomax/aqueue_linux
 
 It will make sense to execute that strmqm program under ktrace(8) with 
 -i flag (use ports/devel/linux_kdump to decode resulting trace) and send 
 me the output of linux_kdump. Maybe your version of linuxthreads uses 
 some different set of flags in linux_clone(), so that my heuristics fails.
 
 -Maxim

From: Andriy Gapon <avg@icyb.net.ua>
To: Maxim Sobolev <sobomax@portaone.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/72922: linux emulation: suid/sgid threaded applications
 hang
Date: Wed, 09 Mar 2005 12:57:49 +0200

 on 09.03.2005 11:59 Maxim Sobolev said the following:
 > Hmm, that's pretty strange. Can you please fetch the following Linux
 > binary, make it suid root and try to run as ordinary user on your
 > system? I've used it to verify that my patch is in fact works - after
 > the change has been made it stopped hanging at my system.
 > 
 > http://www.pbxpress.com/~sobomax/aqueue_linux
 > 
 > It will make sense to execute that strmqm program under ktrace(8) with
 > -i flag (use ports/devel/linux_kdump to decode resulting trace) and send
 > me the output of linux_kdump. Maybe your version of linuxthreads uses
 > some different set of flags in linux_clone(), so that my heuristics fails.
 
 Maxim,
 
 1. I've tried to follow your advice, but a new strange thing happened
 (or maybe it is not strange, but I never payed attention before): "-i"
 in "ktrace -i" doesn't work on suid/sgid applications, when run as
 normal user:
 
 # chmod 6550 ~/tmp/aqueue_linux
 # ls -l ~/tmp/aqueue_linux
 -r-sr-s---  1 avg  topspin  16804  9  13:47 /home/avg/tmp/aqueue_linux
 
 
 $ ktrace -i ~avg/tmp/aqueue_linux -n 100
 pusher started
 poper started
 $ linux_kdump > kdump.out
 $ cat kdump.out
  16103 ktrace   RET   linux_brk 0
  16103 ktrace   CALL  linux_olduname(0xbfbfea4e,0xbfbfe95c,0xbfbfe96c)
  16103 ktrace   NAMI  "/home/avg/tmp/aqueue_linux"
  16103 ktrace   NAMI  "/compat/linux/lib/ld-linux.so.2"
 
 If I set permission back to normal executable, "-i" works again.
 
 
 2. "ktrace -i" works if executed as super-user and strmqm still hangs.
 Here's some relevant info, whcih makes things quite obvious:
 
 # egrep 'fork|exec|clone|kill|signal' kdump.out
  79953 strmqm   CALL  linux_clone(0xf00,0x8099370)
  79953 strmqm   RET   linux_clone 79954/0x13852
  79954 strmqm   RET   linux_fork 0
  79954 strmqm   CALL  linux_clone(0xf21,0xbf3ffbd0)
  79954 strmqm   RET   linux_clone 79955/0x13853
  79955 strmqm   RET   linux_fork 0
  79954 strmqm   CALL  linux_kill(0x13851,0x20)
  79954 strmqm   RET   linux_kill 0
  79955 strmqm   CALL  linux_kill(0x13851,0x20)
  79955 strmqm   RET   linux_kill 0
  79955 strmqm   CALL  linux_kill(0x13851,0x20)
  79955 strmqm   RET   linux_kill 0
  79955 strmqm   CALL  linux_kill(0x13851,0x20)
  79955 strmqm   RET   linux_kill 0
         uucp:*:66:66:UUCP
 pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
  79954 strmqm   CALL  linux_clone(0xf21,0xbf1ffbd0)
  79954 strmqm   RET   linux_clone 79956/0x13854
  79956 strmqm   RET   linux_fork 0
  79954 strmqm   CALL  linux_kill(0x13851,0x20)
  79954 strmqm   RET   linux_kill 0
  79956 strmqm   CALL  linux_kill(0x13851,0x20)
  79956 strmqm   RET   linux_kill 0
  79953 strmqm   CALL  linux_kill(0x13854,0x20)
  79953 strmqm   RET   linux_kill 0
  79956 strmqm   CALL  linux_kill(0x13851,0x20)
  79956 strmqm   RET   linux_kill 0
  79956 strmqm   CALL  linux_kill(0x13851,0x20)
  79956 strmqm   RET   linux_kill 0
  79953 strmqm   CALL  linux_kill(0x13853,0x1c)
  79953 strmqm   RET   linux_kill RESTART
         permitted' from pthread_kill.)
         |   ('1 - Operation not permitted' from pthread_kill.)
               | "
        "| Comment1          :- '1 - Operation not permitted' from
 pthread_kill.       |
  79954 strmqm   CALL  linux_kill(0x13854,0x21)
  79954 strmqm   RET   linux_kill RESTART
  79954 strmqm   CALL  linux_kill(0x13853,0x21)
  79954 strmqm   RET   linux_kill RESTART
 
 Looks like signal 32 is OK, but there are 28 and 33 in addition to it.
 33 seems to be another Linux real-time signal and is probably used with
 linux threads for some purpose. Here's what I read in signal(7) Linux
 man page:
 <<<
 Linux supports real-time signals as originally defined in the POSIX.4
 real-time extensions (and now included in POSIX 1003.1-2001). Linux
 supports 32 real-time signals, numbered from 32 (SIGRTMIN) to 63
 (SIGRTMAX). (Programs should always refer to real-time signals using
 notation SIGRTMIN+n, since the range of real-time signal numbers varies
 across Unices.)
 
 Unlike standard signals, real-time signals have no predefined meanings:
 the entire set of real-time signals can be used for application-defined
 purposes.
 
 (Note, however, that the LinuxThreads implementation uses the first
 three real-time signals.)
 >>>>
 So probably 32,33,34 should be subject to your patch.
 
 I am not sure what signal 28 (SIGWINCH?) is used for (in this case), but
 most probably it is not thread-related and not application critical,
 because execution continues after that signal, but an error message is
 logged.
 
 -- 
 Andriy Gapon

From: Maxim Sobolev <sobomax@portaone.com>
To: Andriy Gapon <avg@icyb.net.ua>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/72922: linux emulation: suid/sgid threaded applications
 hang
Date: Thu, 10 Mar 2005 14:56:41 +0200

 I see. Try to replace the following line in kern_prot.c:
 
   if (signum == SIGTHR && td->td_proc->p_leader != NULL &&
 
 with the following:
 
   if (signum >= SIGTHR && td->td_proc->p_leader != NULL &&
 
 And let me know if it helps.
 
 BTW, would be be interested in getting FreeBSD commit bit, so that you 
 can do the work by yourself? ;-)
 
 -Maxim
 
 Andriy Gapon wrote:
 > on 09.03.2005 11:59 Maxim Sobolev said the following:
 > 
 >>Hmm, that's pretty strange. Can you please fetch the following Linux
 >>binary, make it suid root and try to run as ordinary user on your
 >>system? I've used it to verify that my patch is in fact works - after
 >>the change has been made it stopped hanging at my system.
 >>
 >>http://www.pbxpress.com/~sobomax/aqueue_linux
 >>
 >>It will make sense to execute that strmqm program under ktrace(8) with
 >>-i flag (use ports/devel/linux_kdump to decode resulting trace) and send
 >>me the output of linux_kdump. Maybe your version of linuxthreads uses
 >>some different set of flags in linux_clone(), so that my heuristics fails.
 > 
 > 
 > Maxim,
 > 
 > 1. I've tried to follow your advice, but a new strange thing happened
 > (or maybe it is not strange, but I never payed attention before): "-i"
 > in "ktrace -i" doesn't work on suid/sgid applications, when run as
 > normal user:
 > 
 > # chmod 6550 ~/tmp/aqueue_linux
 > # ls -l ~/tmp/aqueue_linux
 > -r-sr-s---  1 avg  topspin  16804  9  13:47 /home/avg/tmp/aqueue_linux
 > 
 > 
 > $ ktrace -i ~avg/tmp/aqueue_linux -n 100
 > pusher started
 > poper started
 > $ linux_kdump > kdump.out
 > $ cat kdump.out
 >  16103 ktrace   RET   linux_brk 0
 >  16103 ktrace   CALL  linux_olduname(0xbfbfea4e,0xbfbfe95c,0xbfbfe96c)
 >  16103 ktrace   NAMI  "/home/avg/tmp/aqueue_linux"
 >  16103 ktrace   NAMI  "/compat/linux/lib/ld-linux.so.2"
 > 
 > If I set permission back to normal executable, "-i" works again.
 > 
 > 
 > 2. "ktrace -i" works if executed as super-user and strmqm still hangs.
 > Here's some relevant info, whcih makes things quite obvious:
 > 
 > # egrep 'fork|exec|clone|kill|signal' kdump.out
 >  79953 strmqm   CALL  linux_clone(0xf00,0x8099370)
 >  79953 strmqm   RET   linux_clone 79954/0x13852
 >  79954 strmqm   RET   linux_fork 0
 >  79954 strmqm   CALL  linux_clone(0xf21,0xbf3ffbd0)
 >  79954 strmqm   RET   linux_clone 79955/0x13853
 >  79955 strmqm   RET   linux_fork 0
 >  79954 strmqm   CALL  linux_kill(0x13851,0x20)
 >  79954 strmqm   RET   linux_kill 0
 >  79955 strmqm   CALL  linux_kill(0x13851,0x20)
 >  79955 strmqm   RET   linux_kill 0
 >  79955 strmqm   CALL  linux_kill(0x13851,0x20)
 >  79955 strmqm   RET   linux_kill 0
 >  79955 strmqm   CALL  linux_kill(0x13851,0x20)
 >  79955 strmqm   RET   linux_kill 0
 >         uucp:*:66:66:UUCP
 > pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
 >  79954 strmqm   CALL  linux_clone(0xf21,0xbf1ffbd0)
 >  79954 strmqm   RET   linux_clone 79956/0x13854
 >  79956 strmqm   RET   linux_fork 0
 >  79954 strmqm   CALL  linux_kill(0x13851,0x20)
 >  79954 strmqm   RET   linux_kill 0
 >  79956 strmqm   CALL  linux_kill(0x13851,0x20)
 >  79956 strmqm   RET   linux_kill 0
 >  79953 strmqm   CALL  linux_kill(0x13854,0x20)
 >  79953 strmqm   RET   linux_kill 0
 >  79956 strmqm   CALL  linux_kill(0x13851,0x20)
 >  79956 strmqm   RET   linux_kill 0
 >  79956 strmqm   CALL  linux_kill(0x13851,0x20)
 >  79956 strmqm   RET   linux_kill 0
 >  79953 strmqm   CALL  linux_kill(0x13853,0x1c)
 >  79953 strmqm   RET   linux_kill RESTART
 >         permitted' from pthread_kill.)
 >         |   ('1 - Operation not permitted' from pthread_kill.)
 >               | "
 >        "| Comment1          :- '1 - Operation not permitted' from
 > pthread_kill.       |
 >  79954 strmqm   CALL  linux_kill(0x13854,0x21)
 >  79954 strmqm   RET   linux_kill RESTART
 >  79954 strmqm   CALL  linux_kill(0x13853,0x21)
 >  79954 strmqm   RET   linux_kill RESTART
 > 
 > Looks like signal 32 is OK, but there are 28 and 33 in addition to it.
 > 33 seems to be another Linux real-time signal and is probably used with
 > linux threads for some purpose. Here's what I read in signal(7) Linux
 > man page:
 > <<<
 > Linux supports real-time signals as originally defined in the POSIX.4
 > real-time extensions (and now included in POSIX 1003.1-2001). Linux
 > supports 32 real-time signals, numbered from 32 (SIGRTMIN) to 63
 > (SIGRTMAX). (Programs should always refer to real-time signals using
 > notation SIGRTMIN+n, since the range of real-time signal numbers varies
 > across Unices.)
 > 
 > Unlike standard signals, real-time signals have no predefined meanings:
 > the entire set of real-time signals can be used for application-defined
 > purposes.
 > 
 > (Note, however, that the LinuxThreads implementation uses the first
 > three real-time signals.)
 > 
 > So probably 32,33,34 should be subject to your patch.
 > 
 > I am not sure what signal 28 (SIGWINCH?) is used for (in this case), but
 > most probably it is not thread-related and not application critical,
 > because execution continues after that signal, but an error message is
 > logged.
 > 
 

From: Andriy Gapon <avg@icyb.net.ua>
To: Maxim Sobolev <sobomax@portaone.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/72922: linux emulation: suid/sgid threaded applications
 hang
Date: Thu, 10 Mar 2005 15:10:13 +0200

 on 10.03.2005 14:56 Maxim Sobolev said the following:
 > I see. Try to replace the following line in kern_prot.c:
 > 
 >  if (signum == SIGTHR && td->td_proc->p_leader != NULL &&
 > 
 > with the following:
 > 
 >  if (signum >= SIGTHR && td->td_proc->p_leader != NULL &&
 > 
 > And let me know if it helps.
 
 that's what came to my mind too, but unfortunately I will only be able
 to try it in a week or two.
 
 > BTW, would be be interested in getting FreeBSD commit bit, so that you
 > can do the work by yourself? ;-)
 
 I have always dreamt about it, but I feel like it is more responsibility
 than I can take now. Unfortunately, I am also too short of capabilities
 to test kernel changes. Thank you, maybe later.
 
 -- 
 Andriy Gapon

From: Andriy Gapon <avg@icyb.net.ua>
To: Maxim Sobolev <sobomax@portaone.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/72922: linux emulation: suid/sgid threaded applications
 hang
Date: Fri, 18 Mar 2005 11:44:00 +0200

 on 10.03.2005 14:56 Maxim Sobolev said the following:
 > I see. Try to replace the following line in kern_prot.c:
 > 
 >  if (signum == SIGTHR && td->td_proc->p_leader != NULL &&
 > 
 > with the following:
 > 
 >  if (signum >= SIGTHR && td->td_proc->p_leader != NULL &&
 > 
 > And let me know if it helps.
 > 
 
 Maxim,
 
 this has fixed the problem completely, thank you.
 As to your other question, I need to gather my thoughts on it :-)
 
 -- 
 Andriy Gapon
>Unformatted:
 >>> > 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 
