From owner-freebsd-arch Wed Nov 28 8:52:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id F29E937B41A for ; Wed, 28 Nov 2001 08:52:10 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fASGpei40508; Wed, 28 Nov 2001 11:51:41 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 28 Nov 2001 11:51:39 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matthew Jacob Cc: Peter Wemm , Dima Dorfman , arch@FreeBSD.ORG Subject: Re: Anybody working on devd? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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