Date: Sun, 13 Feb 2005 17:17:06 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/ibcs2 ibcs2_signal.c src/sys/kern kern_prot.c kern_sig.c src/sys/compat/linux linux_signal.c src/sys/compat/svr4 svr4_signal.c src/sys/sys proc.h syscallsubr.h src/sys/alpha/osf1 osf1_signal.c Message-ID: <Pine.NEB.3.96L.1050213171046.48471C-100000@fledge.watson.org> In-Reply-To: <200502131642.j1DGg8iP007697@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050213171046.48471C-100000>