From owner-cvs-src@FreeBSD.ORG Fri Feb 11 21:59:57 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 2283616A4CE; Fri, 11 Feb 2005 21:59:57 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28D0443D3F; Fri, 11 Feb 2005 21:59:56 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.26] (SIRIUS-ats227-UTC.ukrtel.net [195.5.25.154]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j1BLBkiC033509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Feb 2005 22:11:47 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <420D1F8D.3010103@portaone.com> Date: Fri, 11 Feb 2005 23:11:41 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/685/Wed Jan 26 10:08:24 2005 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean 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 21:59:57 -0000 Robert Watson wrote: > 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? 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? -Maxim