Date: Fri, 11 Feb 2005 20:07:08 +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/kern kern_prot.c Message-ID: <Pine.NEB.3.96L.1050211200443.8908A-100000@fledge.watson.org> In-Reply-To: <200502111402.j1BE2gFE084807@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Feb 2005, Maxim Sobolev wrote: > Add SIGTHR (32) into list of signals permitted to be delivered to the > suid application. The problem is that 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. > > I believe the same will be true for native applications that use libthr, > since libthr uses SIGTHR for implementing conditional variables. I don't think this is the case -- libthr threading still uses a single process, and delivers the signal to a thread in the same process bypassing inter-process access control checks. With libthr, it's not an operation by one process on another, but by one thread on another thread in the same process. 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? 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.1050211200443.8908A-100000>