From owner-freebsd-arch@FreeBSD.ORG Tue May 21 19:02:11 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 B607A463; Tue, 21 May 2013 19:02:11 +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 8AAD46E0; Tue, 21 May 2013 19:02:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AB295B965; Tue, 21 May 2013 15:02:10 -0400 (EDT) From: John Baldwin To: Jilles Tjoelker Subject: Re: Extending MADV_PROTECT Date: Tue, 21 May 2013 12:22:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <5192AE7C.10105@FreeBSD.org> <20130520222825.GB43407@stack.nl> In-Reply-To: <20130520222825.GB43407@stack.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305211222.11236.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 May 2013 15:02:10 -0400 (EDT) Cc: Konstantin Belousov , arch@freebsd.org, Robert Watson 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: Tue, 21 May 2013 19:02:11 -0000 On Monday, May 20, 2013 6:28:26 pm Jilles Tjoelker wrote: > On Tue, May 14, 2013 at 05:37:00PM -0400, John Baldwin wrote: > > On 5/14/13 3:21 PM, Jilles Tjoelker wrote: > > > All this is not very important for process protection because it > > > requires root privileges anyway but future procctl commands may well be > > > accessible to normal users (I'm thinking of avoiding proliferation of > > > pd* calls in particular). > > > I originally used that approach in pprotect() since that is what ktrace > > uses. I did it this way in procctl() to err on the side of reporting > > errors vs not, but I can easily change it. This is something I wasn't > > sure of and very much appreciate feedback on. > > > Do you have any thoughts on having this be more ioctl-like ("automatic" > > copyin/out and size encoded in cmd) vs ptrace-like (explicit sizes and > > in/out keyed off of command)? > > If it is ioctl-like, it is possible to redirect ioctl() on a process > descriptor to procctl and use cap_ioctls_limit() infrastructure. I'm not > sure Capsicum people actually like that, though. > > In either case, it is possible to have a P_PROCDESC to affect a process > by process descriptor. Capsicum may then need more CAP_*. I talked to Robert about this in person at BSDCan and he indeed does not prefer general purpose multiplexers for system calls. In particular it does make auditing and access control for such things a lot harder to do. My impression from my discussion with him is that he would actually prefer much more narrowly focused system calls (so pprotect() in this case rather than a generic procctl()). -- John Baldwin