From owner-freebsd-hackers Wed Oct 6 23:20:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 258C214CAC for ; Wed, 6 Oct 1999 23:20:05 -0700 (PDT) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA53423; Wed, 6 Oct 1999 23:20:00 -0700 (PDT) Date: Wed, 6 Oct 1999 23:19:53 -0700 (PDT) From: Julian Elischer X-Sender: julian@home.elischer.org To: Alban Hertroys Cc: wsanchez@apple.com, Pat Dirks , FreeBSD Hackers Subject: Re: Apple's planned appoach to permissions on movable filesystems In-Reply-To: <19991007060251.6D1A71DD0@wit401310.student.utwente.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 7 Oct 1999, Alban Hertroys wrote: > 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). > > 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? you could hash the superblocks and private key encrypt the hash. it still doesn't guarantee that the data hasn't been replaced 'in place'. for that you'd have to has the entire disk.... > > My .001 cts. > > -- > Alban Hertroys. > http://wit401310.student.utwente.nl > --- > If I had a sig it would be fun. > The quest for the Holy Sig has begun. > I have not yet a clue, > What will you see next issue? > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message