Date: Wed, 28 Nov 2001 12:55:41 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: mjacob@feral.com, 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.1011128124824.40174A-100000@fledge.watson.org> In-Reply-To: <36655.1006969510@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Nov 2001, Poul-Henning Kamp wrote: > In message <Pine.BSF.4.21.0111280940210.28332-100000@beppo>, Matthew Jacob writes: > >> 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. > > > >I think that if this is the case, there's no point in device drivers knowing > >about permissions at all, and shouldn't be even *allowed* to set them. > > Well, true in the theoretical sense, but it makes a lot of sense for > picobsd like systems that they do. > > As long as the default policy is (ie: becomes) configurable (see my > other email), it is not harmful that the drivers gives a first stab at > mode/owner/group. I'm not opposed to a 'first stab', but in the case of picobsd, I suspect 0/0 0600 would be just fine. I think that this "conservative policy" viewpoint actually makes a fair amount of sense: we start up init with a high level of privilege, and start up devices protected tightly, but accessible via privilege (which init has). The boot process can open up protections, as can devd, as it sees fit. What I would like to avoid is kernel code knowing much about non-0 uids and gids. When dealing with NFS and multiple platforms, you almost immediately run into different use of those other uids and gids. In general, with the exception of device owner initialization, the kernel knows nothing about uids except for 0 and VNONVAL. In the device code, we find a lot of #define's that teach device drivers things that are usually defined in the password file. One thing that might be worth considering, if we adopted this approach, would be having rc.devfs (or just devfsd) set up initial permissions for a variety of objects in a nice configurable way: chown root:kmem /dev/kmem /dev/mem chmod 0640 /dev/kmem /dev/mem chmod 0666 /dev/null ... Regarding the multiple instantiation--it does raise an interesting question. Should the protections be on the device "objects" or on the file system representations? While my leaning is towards "objects", I can see arguments that might suggest other possibilities. Might depend a little on what you want to protect: I personally don't mind having all devices listed in all jails, as long as protections on jails are "done right". But the ability to use purely namespace to restrict access to devices in jail is a cute (and useful) trick, involving low cost and high benefit. 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.1011128124824.40174A-100000>