Extending MADV_PROTECT

[John Baldwin]

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