Driver developers! As you probably know by now, Poul-Henning has enabled DEVFS in the GENERIC kernel on FreeBSD 5.0-CURRENT. This is a strong feature and it's great to see it getting brought back to life. However! Many of consumers of make_dev() have chosen their default permissions somewhat sloppily, and the results have to be thought through a little. On my workstation, I found the following: crw-r--r-- 1 root operator 117, 0 Dec 31 1969 acd0a crw-r--r-- 1 root operator 117, 2 Dec 31 1969 acd0c .. crw-rw-rw- 1 root wheel 30, 20 Dec 31 1969 audio1.0 crw-rw-rw- 1 root wheel 30, 0x00010014 Dec 31 1969 audio1.1 .. crw-rw-rw- 1 root wheel 21, 0 Dec 31 1969 bpsm0 .. crw-rw-rw- 1 root wheel 30, 19 Dec 31 1969 dsp1.0 crw-rw-rw- 1 root wheel 30, 0x00010013 Dec 31 1969 dsp1.1 crw-rw-rw- 1 root wheel 30, 21 Dec 31 1969 dspW1.0 crw-rw-rw- 1 root wheel 30, 0x00010015 Dec 31 1969 dspW1.1 .. crw-rw-rw- 1 root wheel 30, 16 Dec 31 1969 mixer1 .. crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci .. cr--r--r-- 1 root wheel 30, 6 Dec 31 1969 sndstat .. crw-r--r-- 1 root operator 108, 255 Dec 31 1969 usb crw-r--r-- 1 root operator 108, 0 Dec 31 1969 usb0 I've done a brief grep through src/sys/dev/* and noticed a lot of other potential problems. I realize the permissions on a sound device seem a bit trivial, but consider the following scenario: Due to a bug in fingerd, a set of workstations in a mail/phone order center is compromised. The attacker uses the bug in fingerd to gain read access to /dev/audio or /dev/dsp, and streams recordings of all conversations in the room to a remote site where he types in credit card numbers and personal information as he sees fit. Or maybe he exploits the same bugs to listen to administrator conversations in a NOC and pick up router passwords. Some of the permissions above are probably fine, as they're for getting status on busses, etc, but generally speaking, excessively liberal permissions can be a serious problem in /dev. Allow direct read access from CDROM media can give them access to keying material or password crypts for CDROM-booted workstations, or access to 1-time pad data stored on the CD. Or to licensed commercial software or intellectual property. I'm not familiar with the fbtab mechanism, but it may be that we should be adding support for the audiot devices (etc) to it, or making this part of an eventual devd. In any case, the default devfs permissions should be intended to be closed, and then opened as needed by privileged software, rather than open and then closed. Otherwise you introduce race conditions, and unintended consequences. Also, I realize that we have constants in kernel for the wheel and operator groups, but ideally, I'd like to see those be purely userland concepts. The kernel security model generally recognizes one uid, the superuser, as having special privileges over others. Hardcoding other user or group id's into the kernel pushes userland concepts (/etc/passwd, /etc/group, /usr/sbin/login) into the kernel. Setting additional rights for specific groups (operator, tty, etc) can be done as part of a userland boot or login process. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
