Date: Tue, 12 Mar 2002 21:42:44 +0300 (MSK) From: "."@babolo.ru To: tlambert2@mindspring.com (Terry Lambert) Cc: cjc@FreeBSD.ORG, root@utility.clubscholarship.com, freebsd-hackers@FreeBSD.ORG, freebsd-emulation@FreeBSD.ORG Subject: Re: cryptography implications (privacy) of FreeBSD jail ? Message-ID: <200203121842.VAA24405@aaz.links.ru> In-Reply-To: <3C8DBD5E.7055B080@mindspring.com> from "Terry Lambert" at "Mar 12, 2 00:33:34 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203121842.VAA24405>