Re: Accessing disks via their serial numbers.

In message <20060627.120424.-1625880159.imp@xxxxxxxxxx>, "M. Warner Losh" write
s:
In message: <62122.1151427182@xxxxxxxxxxxxxxxxxx>
"Poul-Henning Kamp" <phk@xxxxxxxxxxxxxx> writes:

: 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!

Well, not quite, but lets leave the deep UNIX philosophy questions
behind for a moment.

: 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.

My take on this is different than yours.

I don't think we should allow names that are not "under control",
and by not "under control" I mean device names which the device
driver writer doesn't control or at the very least sanitize.

For instance, if you want to create names that match random
strings, like the tape labels in your robot, the sensible and
security concious device driver writer makes sure the names
have a unique prefix:

/dev/tape/$label

or similar, so that devfs(8) rules can be written in a surefire way.


A simple fix to this would be to have a sysctl that says to filter or
allow magic characters in the label name.

I really don't think it should be optional. A vis(3) in some
form should always happen.

: 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:

That is why I'm not terribly keen on any kind of user-controlled
/dev filenames.

: 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.

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.

With an on-demand scheme, the scalability issue disappears,
so we can add hard labels, soft labels, physical position
(bus:id:lun), OEM labels, anything you can think off.

With a fully enumerated scheme, the scalability bites hard.

The only way to collapse these two views would be to allow
drivers to register directories in DEVFS, so that they get
to enumerate the issue when necessary, but without allocating
cdevs for all the unnessesary nodes.

That is heading straight down the Linux procfs path.

If we want to go that way: fine, personally I think it leads
to madness.


And please remember: This entire thing only comes up because
Pawel doesn't want to solve the problem correctly for g_label,
this is the fall-back "quick&dirty" solution.

The correct solution is to give the users a reliable tool for
stealing the necessary labelsector from the end of a filesystem.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@xxxxxxxxxxx | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • [NEWS] HelixPlayer Based Players Format String
    ... Get your security news from a reliable source. ... media player for Linux, Solaris (versions for other operating systems are ... between 0x0822** - 0x082f** and with control of one pointer at a time ... $ An open security advisory #13 - RealPlayer and Helix Player Remote ...
    (Securiteam)
  • Re: why microsoft choose mfc rather than wtl?
    ... to lower security settings, etc. ... For a client to get ... the particular AX control is never accessed, shown, or downloaded. ... unethical to deliver an automobile to customers because it is possible ...
    (microsoft.public.vc.mfc)
  • Re: Linux security
    ... that is in Windows NT-based systems out of the box. ... Why do you want that fine level of control? ... level of control over security?" ... a file system is a different beast altogether. ...
    (Ubuntu)
  • Re: Homeland security suggests Real ID (and now it gets worse!)
    ... Torture Bracelet To Control Dissenting Americans? ... Homeland Security, weapons company express desire to use "Security Bracelet" in law enforcement, crowd control ... Why the terrorists wouldn't just remove the bracelet as soon as they boarded the plane isn't explained, but the perceived fallibility of the device isn't the issue - the heart of the matter is the fact that the Department of Homeland Security has publicly expressed an interest and is seeking funding to utilize the device against the "criminal element". ...
    (alt.support.chronic-pain)
  • Techniques for handling mobile code and other OS access control i ssues
    ... Techniques for handling mobile code and other OS access control i ... Security OS Design Issues and Thoughts ... control add-in for unix, to be based on the notion of having system ... One will also note that the bundle of functions in the Safety package ...
    (SecProg)