From owner-cvs-all@FreeBSD.ORG Sun Sep 14 08:40:46 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A059816A4BF; Sun, 14 Sep 2003 08:40:46 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E84543FF2; Sun, 14 Sep 2003 08:40:45 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h8EFdUrO019112; Sun, 14 Sep 2003 11:39:31 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h8EFdUmU019109; Sun, 14 Sep 2003 11:39:30 -0400 (EDT) Date: Sun, 14 Sep 2003 11:39:30 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20030914073819.GV15671@elvis.mu.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-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2003 15:40:46 -0000 On Sun, 14 Sep 2003, Alfred Perlstein wrote: > * Robert Watson [030914 00:23] wrote: > > rwatson 2003/09/14 00:22:39 PDT > > > > FreeBSD src repository > > > > Modified files: > > sys/kern kern_prot.c > > Log: > > > > Also, add SIGALRM to the set of signals permitted to be delivered to > > setugid processes by unprivileged subjects. > > why? Because of a specific report of breakage: in this case, for the Diablo news server. The details of the report are that Diablo starts running as root, and then changes to another after binding ports, etc. That pool of worker processes will signal itself using SIGALRM -- however, each process also has P_SETUGID set on it because it has undergone a credential downgrade (and therefore may be able to leak information or capabilities acquired when running with elevated privilege). I thought about this one for quite a while, because I thought it was a pretty hard call to make. When I introduced the signal delivery limitations in the context of P_SETUGID, I walked the list of signals to attempt to separate them into a list of signals used for IPC, vs a list of signals used to raise exception conditions in the application. In that initial list, I assigned SIGARLM to the exception case, since it is usually generated as a result of a system service, alarm() or setitimer(). However, it was then brought to my attention that SIGALRM is a common choice for an overflow IPC signal when SIGUSR1 and SIGUSR2 are already assigned. It's worth noting that, in my research on the issue, I discovered that Theo had made a similar change to the OpenBSD signal check code in June, 2002. A reference to the Diablo thread in question is here: http://www.mail-archive.com/freebsd-current@freebsd.org/msg60727.html I'm still a little uncomfortable with the outcome, but I also recognize that the narrowing down of signal delivery I performed has the potential to negatively impact application operation. The other alternative, FYI, is for us to work more closely with application developers to discourage this approach to IPC. Diablo is the first case I've come across where these limits have negatively affected normal application operation -- usually, bizarre use of signals is limited to the operator in controlling a process, not used between processes that have downgraded credentials. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories