On Fri, May 17, 2013 at 01:14:23PM -0600, Jamie Gritton wrote: > I'm considering Alexander Leidinger's patch to make X11 work inside a > jail (http://leidinger.net/FreeBSD/current-patches/0_jail.diff). It > allows a jail to optionally have access to /dev/io and DRI (provided the > requisite device files are visible in the devfs ruleset). > > I'm planning on putting this under a single jail permission, which would > group those two together as device access that allows messing with > kernel memory. It seems more complete to put /dev/mem under that same > umbrella, with the side benefit of letting me call it "allow.dev_mem". > > Currently, access is controlled only by device file permission and a > securelevel check. Jail access is allowed as long as the /dev/mem is in > the jail's ruleset (it isn't by default). Adding a prison_priv_check() > call would allow some finer control over this. Something like: > > int > memopen(struct cdev *dev __unused, int flags, int fmt __unused, > struct thread *td) > { > int error; > > error = priv_check(td, PRIV_FOO); > if (error != 0 && (flags & FWRITE)) > error = securelevel_gt(td->td_ucred, 0); > > return (error); > } > > The main question I'm coming up with here is, what PRIV_* flag should I > use. Does PRIV_IO make sense? PRIV_DRIVER? Something new like > PRIV_KMEM? Also, I'd appreciate if anyone familiar with this interface > can tell me if memopen() is the right/only place to make this change. Why do we need the PRIV check there at all, esp. for DRM ? Why the devfs rulesets are not enough ?
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:37 UTC