From owner-freebsd-hackers Thu Oct 7 11: 4:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3E9A415396 for ; Thu, 7 Oct 1999 11:04:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA95956; Thu, 7 Oct 1999 11:04:40 -0700 (PDT) (envelope-from dillon) Date: Thu, 7 Oct 1999 11:04:40 -0700 (PDT) From: Matthew Dillon Message-Id: <199910071804.LAA95956@apollo.backplane.com> To: wsanchez@apple.com, Pat Dirks , Alban Hertroys Cc: FreeBSD Hackers Subject: Re: Apple's planned appoach to permissions on movable filesystems References: <19991007060251.6D1A71DD0@wit401310.student.utwente.nl> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On 6 Oct, Wilfredo Sanchez wrote: :> | I would rather brand the filesystem with the ID of the host. The :> | starting situation is an "unmarked" filesystem. If a host detects the :> | mounting of an "unmarked" filesystem, it will brand it with it's ID. If :> | it detects a filesystem that has an ID that differs from the host's ID, :> | it is a foreign filesystem. Seems quite simple to me... :> :> But then you have to put that information on the disk, and you're :> back to trusting the disk. "Um, yeah, I'm local. Trust me." : :Hmmm... But you can also fake the filesystem ID to be one that was :previously known by the system. Just make the filesystem local, put :some horrible executables on it, and write back the original idea (if :that's at all necessary, I'm still not sure it gets changed in between). Ignoring the security issues for the moment, I think putting the FQDN (fully qualified domain name) of the 'owner' of the disk volume could prove extremely useful in the new internet age. As machines get better connected, such information could eventually be used by the operating system to translate user id's on the fly by using the domain name in the label to contact the host in question in order to obtain the translation. Something similar to MX DNS records (i.e. a hierarchically specified 'user translation' service) would glue it all together. Baring the availability of a domain name, some sort of unique ID could potentially serve the same function, but without the ability to look it up on the internet. Perhaps the real solution is to allow sites to distribute and maintain unique id's based on their domain name, e.g. FU123BAC@. These sites could also offer the uid translation service to its customers. :The problem is that you write a "unique" ID on the disk. You can read :the disk, so you can store that ID and write it back if you do want to :harm somebody. Is public key encryption, or something like that, a :solution? Or is this not necessary? : :My .001 cts. : :-- :Alban Hertroys. :http://wit401310.student.utwente.nl Revisiting security now... A provision for public-key encryption of the data held on the disk (as well as the id itself) would be useful. Just encrypting the ID alone would not be useful. The distinction would then shift away from whether the media is removable or not (it would no longer matter as much) and instead assume that no unencrypted data can ever be trusted and encrypted data can be trusted insofar as the ID can be trusted. Methinks this could result in a very useful project - an 'encrypted' UFS filesystem implementation plus domain based services to translate uid's on the fly. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message