From owner-cvs-src@FreeBSD.ORG  Sun Feb 13 17:22:56 2005
Return-Path: <owner-cvs-src@FreeBSD.ORG>
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 7A7A616A4CE; Sun, 13 Feb 2005 17:22:56 +0000 (GMT)
Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 4321443D3F; Sun, 13 Feb 2005 17:22:56 +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 F185346B04;
	Sun, 13 Feb 2005 12:22:55 -0500 (EST)
Date: Sun, 13 Feb 2005 17:21:41 +0000 (GMT)
From: Robert Watson <rwatson@FreeBSD.org>
X-Sender: robert@fledge.watson.org
To: Maxim Sobolev <sobomax@portaone.com>
In-Reply-To: <420F851E.2090108@portaone.com>
Message-ID: <Pine.NEB.3.96L.1050213171721.48471D-100000@fledge.watson.org>
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 <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Feb 2005 17:22:56 -0000


On Sun, 13 Feb 2005, Maxim Sobolev wrote:

> I see. I've just committed a change which solves this problem by
> allowing emulation layers to bypass FreeBSD-specific security checks
> during signal delivery. This makes sense since emulation layers can have
> different meanings for signals and/or different security restrictions. 

I agree that the problem needs fixing, but I think this was entirely the
wrong solution.  Even if Linux processes expect the signal to have one set
of semantics on the target, changing how it affects all processes isn't
the right solution.  Disabling a broad range of protections wasn't even
necessary to accomplish this fix.  I think enough information is present
to do this check properly, and we should therefore do it properly.  I
would be happy to help review further patches to correct this problem.

I also object to the name pedantic: we're not the only operating system to
enforce these protections, and there have been specific vulnerabilities in
the past of precisely this sort of protection are intended to address.

Robert N M Watson