From owner-freebsd-hackers Tue Mar 12 10:35:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id C76BB37B421; Tue, 12 Mar 2002 10:35:21 -0800 (PST) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id VAA24405; Tue, 12 Mar 2002 21:42:44 +0300 (MSK) Message-Id: <200203121842.VAA24405@aaz.links.ru> Subject: Re: cryptography implications (privacy) of FreeBSD jail ? In-Reply-To: <3C8DBD5E.7055B080@mindspring.com> from "Terry Lambert" at "Mar 12, 2 00:33:34 am" To: tlambert2@mindspring.com (Terry Lambert) Date: Tue, 12 Mar 2002 21:42:44 +0300 (MSK) Cc: cjc@FreeBSD.ORG, root@utility.clubscholarship.com, freebsd-hackers@FreeBSD.ORG, freebsd-emulation@FreeBSD.ORG From: "."@babolo.ru MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert writes: > "Crist J. Clark" wrote: > > On Mon, Mar 11, 2002 at 04:13:16PM -0800, Patrick Thomas wrote: > > > Let's say I am running in a jail, and say 5 other people are running in > > > other, seperate jails on the same machine. > > > > > > Now lets say I start up pgp, and generate my keys, and generally use pgp > > > through the command line in my jail. Or, instead of pgp I do other crypto > > > related sensitive activities... > > > > > > what is my risk here ? Can someone either on the host machine or in one > > > of the other jails watch memory on the machine and discern things like my > > > keys or passphrases or have very easy access to the data I am decrypting ? > > > > As always, root on the host ownz you. root in your jail probably does > > too. If the jails are set up "promiscuously," I can think of ways > > users in other jails could get information, but if they are set up > > well, I don't see any straightforward attacks. But I haven't done > > exhaustive research. > > Enable devfs. Disable direct use of specfs, so that user > created device nodes are no good. Mount the devfs in the > jail, which will create a local instance from the template. Last time I try devfs on CURRENT it was buggy. Now I use this trik: /dev/ad2s1f /jail ufs rw,nodev 2 2 /full /jail/xf3/dev null ro,noexec 0 0 /null /jail/qmail/o/dev null ro,noexec 0 0 /null /jail/qmail/i/dev null ro,noexec 0 0 /null /jail/pop/ck/dev null ro,noexec 0 0 /null /jail/pop/in/dev null ro,noexec 0 0 .... where /full and /null have some restricted sets of devices. > Now delete /dev/io, /dev/mem, /dev/kmem out of the devfs. > > Voila'... it's now as safe as it's possible to be, and the > reading of memory other than that mapped into your process > address space is not possible, since you can't use /dec/mem > or /dev/kmem to map the memory, and you can't use /dev/io to > hack the bits on the disk, the hard (and dangerous) way. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message