From owner-freebsd-arch@FreeBSD.ORG Wed May 8 16:26:45 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2A72CABF; Wed, 8 May 2013 16:26:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0798AD9C; Wed, 8 May 2013 16:26:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 689E1B960; Wed, 8 May 2013 12:26:44 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: Extending MADV_PROTECT Date: Wed, 8 May 2013 12:05:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <201305071539.24900.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305081205.20910.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 May 2013 12:26:44 -0400 (EDT) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 16:26:45 -0000 On Tuesday, May 07, 2013 5:29:30 pm Adrian Chadd wrote: > On 7 May 2013 12:39, John Baldwin wrote: > > > Well, only root can do it. Even now MADV_PROTECT is a similar foot shooting > > device (though not quite as easy to do). You can also get yourself into a heap > > of trouble with other things like rtprio, etc., so I sort of think that is up to > > the user/administrator to manage. I do think that the more fine-grained priority > > approach may be a good way to mitigate that if it really becomes an issue at some > > point. > > This is the kind of thing that begs for a capability. And I'm > surprised Robert hasn't chimed in and said just that. There is an existing PRIV_* already that this still respects. > However, I think we still lack the ability to do useful capability > work from user-space. God I'd like to be wrong on this one. You should talk to Robert. I think you can write a MAC module that hooks into priv_check() and can establish arbitrary rules for granting privileges. -- John Baldwin