A PRIV_* flag for /dev/mem?
Konstantin Belousov
kostikbel at gmail.com
Sat May 18 11:44:02 UTC 2013
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 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20130518/3fa9613f/attachment.sig>
More information about the freebsd-current
mailing list