Date: Tue, 19 Nov 2002 00:16:49 -0800 (PST) From: Kip Macy <kip_macy@yahoo.com> To: Bruce Evans <bde@zeta.org.au>, Kris Kennaway <kris@obsecurity.org> Cc: current@FreeBSD.ORG Subject: Re: Device permissions with DEVFS Message-ID: <20021119081649.13088.qmail@web14008.mail.yahoo.com> In-Reply-To: <20021119181343.Y29882-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry, if I'm repeating something already said, but the tone of your mail would indicate that I'm not. This doesn't sound like an intrinsic limitation of devfs, just an issue with how it is structured now. There should just be a central file for all the devices which devfs sucks in at build (or maybe boot) time specifying the appropriate permissions and any other configuration information. --- Bruce Evans <bde@zeta.org.au> wrote: > On Mon, 18 Nov 2002, Kris Kennaway wrote: > > > Something that needs to be addressed before 5.0 is > the insecure > > default permissions on many devices. For example, > on my system, the > > following devices have insecure permissions on 5.0 > (but not on 4.x > > with the default MAKEDEV settings): > > > > crw-r--r-- 1 root operator 117, 0 Nov 18 > 14:49 acd0 > > Hrmph. I have been dropping hints about this for a > couple of years. > > > crw-rw-rw- 1 root wheel 21, 1 Nov 18 > 14:49 psm0 > > Another problem is that it is hard to check for > errors if you don't > have the hardware, since devfs only creates nodes > for existing devices > (MAKEDEV doesn't create everything either, but > MAKEDEV all gets closer; > it's also easier to scan through MAKDEV than through > hundreds of device > drivers). > > > crw-rw-rw- 1 root wheel 30, 3 Nov 14 > 21:30 dsp0.0 > > crw-rw-rw- 1 root wheel 30, 0x00010003 Nov > 8 23:38 dsp0.1 > > crw-rw-rw- 1 root wheel 30, 5 Nov 8 > 23:38 dspW0.0 > > crw-rw-rw- 1 root wheel 30, 0x00010005 Nov > 8 23:38 dspW0.1 > > crw-rw-rw- 1 root wheel 30, 11 Nov 8 > 23:38 dspr0.0 > > > > These have the same permissions on 4.x, but > they're still insecure > > (unprivileged users can read from a microphone). > > I dropped a hint about this 7.5 years in MAKEDEV > rev.1.87 > (snd_security_hole). I might have fixed this if I > had any sound devices. > > > > I'm sure there are others I have missed. Could > everyone please check > > their /dev (better, check the kernel source)? > > I have noticed the following: > > acd track devices have the same permissions bugs as > ordinary acd devices, > and ownership bugs too. > > The cuaa devices for the rp driver have bogus > ownerships and permissions > in both MAKEDEV and devfs. IIRC, the permissions > are 600 in MAKDEV and > 666 in devfs, but should be 660; the ownership is > root:wheel in both > but should be uucp:dialer. (If MAKEDEV or devfs > created an instance of > each type of device, then bugs like this would be > easier to see using > "ls -l /dev/cua*"; all cua devices should have the > same default ownerships > and permissions. Similarly for disk devices except > there is no simple > pattern like cua* for them.) > > lpctl* doesn't even have the correct name in devfs, > so its one user > (lptcontrol(8)) can't find it. > > ata has bogus group operator in devfs (it has mode > 600 so it can't be > accessed by group operator). MAKEDEV has a few > nonsense groups like > this too. In general, control devices should not be > accessible by > group operator since access generally gives > write-like access. > > mdctl uses a hard-coded magic minor number in both > MAKEDEV and devfs. > The dkminor() function in MAKDEV and dk[make]minor() > functions in the > kernel exist to reduce such magic. > > Bruce > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of > the message > > __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021119081649.13088.qmail>