From owner-cvs-src@FreeBSD.ORG Fri Feb 11 20:08:19 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C14116A4D9; Fri, 11 Feb 2005 20:08:19 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C774343D2D; Fri, 11 Feb 2005 20:08:18 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 28C6546B0C; Fri, 11 Feb 2005 15:08:18 -0500 (EST) Date: Fri, 11 Feb 2005 20:07:08 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <200502111402.j1BE2gFE084807@repoman.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_prot.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2005 20:08:19 -0000 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