Date: Thu, 7 Oct 1999 11:04:40 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: wsanchez@apple.com, Pat Dirks <pwd@apple.com>, Alban Hertroys <dalroi@wit401310.student.utwente.nl> Cc: FreeBSD Hackers <FreeBSD-Hackers@FreeBSD.ORG> Subject: Re: Apple's planned appoach to permissions on movable filesystems Message-ID: <199910071804.LAA95956@apollo.backplane.com> References: <19991007060251.6D1A71DD0@wit401310.student.utwente.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
: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@<domain>. 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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910071804.LAA95956>