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
