From owner-freebsd-current Mon Nov 18 23:31:11 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 197B937B401 for ; Mon, 18 Nov 2002 23:31:09 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id F179A43E88 for ; Mon, 18 Nov 2002 23:31:06 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA24248; Tue, 19 Nov 2002 18:31:00 +1100 Date: Tue, 19 Nov 2002 18:43:52 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kris Kennaway Cc: current@FreeBSD.ORG Subject: Re: Device permissions with DEVFS In-Reply-To: <20021119050304.GA2608@rot13.obsecurity.org> Message-ID: <20021119181343.Y29882-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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