Date: Tue, 27 Jun 2006 12:04:24 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: phk@phk.freebsd.dk Cc: gurney_j@resnet.uoregon.edu, pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. Message-ID: <20060627.120424.-1625880159.imp@bsdimp.com> In-Reply-To: <62122.1151427182@critter.freebsd.dk> References: <20060627.103343.-432837786.imp@bsdimp.com> <62122.1151427182@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <62122.1151427182@critter.freebsd.dk>
"Poul-Henning Kamp" <phk@phk.freebsd.dk> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060627.120424.-1625880159.imp>