Date: Wed, 28 Nov 2001 11:51:39 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Matthew Jacob <mjacob@feral.com> Cc: Peter Wemm <peter@wemm.org>, Dima Dorfman <dima@trit.org>, arch@FreeBSD.ORG Subject: Re: Anybody working on devd? Message-ID: <Pine.NEB.3.96L.1011128113543.37721K-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0111261459170.60524-100000@beppo>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Nov 2001, Matthew Jacob wrote:
> > It would also be a place where a program could be called to respond to new
> > nodes appearing in /dev for adjusting any permissions needed according
> > to some sort of template system or something. (But it would be a mistake
> > to mix the two things up at this point, as the permissions setter is prime
> > bikeshed material. IMHO, provide the hooks first, then once we have the
> > framework, then revisit the permissions).
>
> It seems to me wrong to do 'adjustments'. Either you have a model that
> trusts drivers to do the right thing when the call make_dev, or you
> don't.
There are a couple of reasons why it would be desirable to allow devd (or
devfsd, if you will) manage permissions. They include:
(1) Avoid having device drivers and the kernel aware of specific userland
uid assignments.
(2) Avoid having device drivers know the system policy for accessing
devices, such as cdrom drives, where you can imagine a variety of
models.
(3) Avoid having device drivers be aware of a "console policy", which
allocates rights to a device based on login sessions.
(4) Avoid having to modify drivers to learn about new security models
(mandatory access control, et al) or make use of privilege calls (such
as suser) on device open.
Generally speaking, it seems desirable the devices would appear in /dev
with conservative permissions, and then userland policy might adjust those
permissions to be more liberal based on files in /etc, and so on.
Encapsulating that policy in each device driver seems undesirable. It's
not a question of trusting device drivers to do the right thing, it's a
question of whether a device driver author can even have enough
information about where the device is being used to make that decision.
For example, you as a device driver shouldn't need to know that my
workstation runs with a Biba hierarchal integrity policy, which prohibits
access to /dev/pass* by the root user when the root user is running with a
low integrity level, but that the root user at low integrity can access
one of my scsi disks. That's something that can be addressed by using
0600 in make_dev, having the kernel assign a default label as part of
instantiating the node, and that devfsd can then fix up by assigning
appropriate labels on picking up the event from devfs. Ideally, devfsd
would export a socket in /dev that would notify consumers of the arrival
of devices *after* it was done processing, meaning you might want
/dev/devfsctl # generated by kernel, read only by devfsd
/dev/devfsevent # generated by devfsd, read by other consumers
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011128113543.37721K-100000>