From owner-cvs-src@FreeBSD.ORG Fri Feb 11 23:14:17 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 E804D16A4CF; Fri, 11 Feb 2005 23:14:17 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FF3F43D2D; Fri, 11 Feb 2005 23:14:17 +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 1FD2546B2E; Fri, 11 Feb 2005 18:14:17 -0500 (EST) Date: Fri, 11 Feb 2005 23:13:07 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <420D1F8D.3010103@portaone.com> 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 23:14:18 -0000 On Fri, 11 Feb 2005, Maxim Sobolev wrote: > > 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