From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 18:05:49 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF67916A40B; Tue, 27 Jun 2006 18:05:49 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCFD44A15; Tue, 27 Jun 2006 18:05:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5RI4KsK023917; Tue, 27 Jun 2006 12:04:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jun 2006 12:04:24 -0600 (MDT) Message-Id: <20060627.120424.-1625880159.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <62122.1151427182@critter.freebsd.dk> References: <20060627.103343.-432837786.imp@bsdimp.com> <62122.1151427182@critter.freebsd.dk> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gurney_j@resnet.uoregon.edu, pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 18:05:50 -0000 In message: <62122.1151427182@critter.freebsd.dk> "Poul-Henning Kamp" writes: : >True, but somewhat irrelvant. This does not go to the question that I : >asked. What problems does having fully enumerated devices cause? : : There is no problem with fully enumerated devices, as long as : they don't cause an explosion in the number of devices. That's my view as well! We agree! : >devfs does allow directory listings, therefore absent some compelling : >reason to the contrary these listings should be complete. This is an : >enumeration of the available devices, which closely mirrors the : >available hardware. : : The problem is that it exactly doesn't do that, and can't possibly : do that, because hardware is not seen by devfs until the driver : is loaded. : : I realize that this sounds a bit Clintonesque, but it all comes : down to what your definition of "available" is. : : For instance, the crypt-hw support has one joint device node in /dev : but can cover up 16 cards, without ever disclosing to you what : they are or what they can do, until you open the joint device and : ask with the right ioctls. Don't be silly here. I'm arguing that available be defined as those devices that are physically persent in the system, and have their device driver loaded for them. Twisting "available" in that Clintonesque way isn't what I'm talking about. I'm talking about plain, ordinary meaning of available here: those things the kernel has direct knowledge of. : >While it is a magic place, that magic place exists in : >the context of a file system, and file systems aren't supposed to : >randomly open files. : : You lost me there... Filesystems generally give the ability to enumerate names at a given level of the file system (ls /usr should be no different than ls /dev), plus the ability to open files that appear in ls listings. magic filenames make an end run around this by being able to open files that you cannot list. Listing here includes discoving meta data such as ownership, permissions, acls, etc. [[ I'm ignoring the 'x' bit semantics, because sufficiently privileged users can override that. With magic files there's no such privilege that can override that. ]] : >It is also a security concern. If I wanted to have non-default : >permissions on these magic nodes, at the very least I'd have no way to : >audit them. I'm unclear if doing the normal unix operations on the : >magic nodes would suffice. : : We have the devfs(8) rules for that. And no way to audit them. The basic problem that I'd have in this specific case (serial numbers ala some variation of /dev/ad/ABCDEFG) is that the system administrator cannot set and verify the permissions of the filename. If there's a typo in devfs with 'normal' devices, then a simple ls will show that something is wrong. With magic devices that don't appear in ls, there's no way to know if it was created correctly, or if something went wrong. : >My question is more specific. What is wrong with having : >entries in devfs of files you can actually open, when we know the : >universe that is possible given the current knowledge of the kernel? : : We generally have that. : : The only exceptions I'm aware of right now are pseudo devices, for : which precreation doesn't make sense at all. Yes. Those make sense. Since we create ptys, for example, on demand, having only those ptys that are in the system right now makes good sense. : >My big problem with magic files and hiding them is that it becomes : >difficult or impossible to diagnose and troubleshoot. : : I have a very big problem with magic files as well. : : Currently g_label doesn't impose any restrictions on the label : strings of the device, which means that you can include '/', '..' : and ';' in labels. I don't need to tell you what that means : for shell scripts etc. Put a g_label on an USB key and trick : the admin into to doing something stupid and you're all set: : : just type : mount -t msdos /dev/da0* : I can't remember which slice it is... A simple fix to this would be to have a sysctl that says to filter or allow magic characters in the label name. Shell characters like ';' aren't expanded into the shell command, so if there were '; sh' in the label, the above command wouldn't be affected by it. No root shell would be created. I'll concede that one can construct scenarios where this does present a problem, but they are difficult. The command would have to be something more like: mount -t msdos /dev/da0s? /dos to avoid false positives, and even then it fails with disks that have multiple slices. : The reason why I am advocating using "on-demand" names for : what Pawel is proposing is that way the names only exist : if people ask for them, and only the names they ask for exists. Making them on-demand makes it impossible to audit. Right now, if I'm owrried abotu disk security, I can do: % ls -l /dev/ad* crw-r----- 1 root operator 0, 61 Jun 27 10:19 /dev//ad0 crw-r----- 1 root operator 0, 62 Jun 27 10:19 /dev/ad0s1 crw-r----- 1 root operator 0, 63 Jun 27 10:19 /dev/ad0s2 crw-r----- 1 root operator 0, 64 Jun 27 10:19 /dev/ad0s3 crw-r----- 1 root operator 0, 65 Jun 27 10:19 /dev/ad0s4 crw-r----- 1 root operator 0, 66 Jun 27 04:19 /dev/ad0s4a crw-r----- 1 root operator 0, 67 Jun 27 10:19 /dev/ad0s4b crw-r----- 1 root operator 0, 68 Jun 27 10:19 /dev/ad0s4c crw-r----- 1 root operator 0, 69 Jun 27 04:19 /dev/ad0s4d crw-r----- 1 root operator 0, 70 Jun 27 04:19 /dev/ad0s4e crw-r----- 1 root operator 0, 71 Jun 27 04:19 /dev/ad0s4f crw-r----- 1 root operator 0, 72 Jun 27 04:19 /dev/ad0s4g As can clearly be shown, absent any unknown security bugs, only root can write to these devices, while those in group operator can read. A better way to control their creation is by either the presence or absense of the module, or by a sysctl in the module to control their creation. : In addition to avoiding a wanton doubling of the geom mesh : size (because he does it at the very bottom) that also : adds significant flexibilty and security to the table. I understand the doubling argument. This can be a good argument if the number of entries is very large (I've not seen even large systems have more than 100 entries, and if this is off by default, then there's no damage). However, I'm not sure I understand the flexibility and security side of things. Properly written and implemented, I'm not sure how it affects security. Warner