Subject: Re: cgd root [was Re: enabling cgd by default]
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 08/09/2007 10:50:26
--LmeqhziFqEm+Ep0k
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 08, 2007 at 04:48:19AM -0400, der Mouse wrote:
> > As for root on cgd, are you aware of the init.root sysctl?
>=20
> Um...no?  I couldn't find it in the 3.1 manpages, so I went poking
> around in the -current source tree.  I can't find it in usr/src/sys/sys
> or usr/src/sys/kern, nor in usr/src/sbin/sysctl/sysctl.8.  What is it
> and where is it documented?  (And why isn't the answer "sysctl(8)"? :)

> > This is intended to achieve essentially the same thing.  It's a
> > feature of init
>=20
> A feature of...init??  Has sysctl been `improved' to the point that a
> userland process can serve a sysctl tree?

No, no. Sysctl is used as a convenient place to store and pass state,
with permissions, while there may be no r/w filesystem mounted.

> > If you combine this with a kernel that has the "real" root on an
> > md(4), with the image embedded in the kernel, you have something
> > essentially indistinguishable in practice from what you're after.
>=20
> Well, once cgd grows the prompt-from-kernel - see below.

I'm not clear that there's a concrete difference between
prompt-from-kernel and cgdconfig(8)-linked-into-kernel-image.

I can certainly understand that it can *seem* different, and that it
can take some time to become comfortable that the differences aren't
at all significant in practice.

> > The threat and trust model for the bootblocks and kernel is the same,
> > just with a slightly larger kernel.  Put these on on a usb flash
> > stick that you carry on your keyring separately,
>=20
> That's not the sort of use I have in mind, actually; the use I have in
> mind is for my laptop.  I don't like the idea of carrying data around
> in the clear. (I don't really *like* having even the bootblocks and
> kernel in the clear, but *something* has to be.)

That's exactly what everyone else using this has in mind, too. The
disk is entirely encrypted, apart from boot and kernels just as you
describe, if your kernels contain a tiny md root as I describe.

If your laptop supports booting off convenient removable media (tiny
usb keyring flash), you can at least keep the bootblocks and kernel
separate and subject to different protections (though they still have
to be in the clear).

> I dunno.  I don't like that sort of "boot a minimalist root and run
> some userland, then switch to the _real_ root" setup, but I haven't
> managed to pin down a basis for my dislike enough to say anything
> useful about it.  It's certainly better from a "mechanism, not policy"
> point of view, so I'm not sure what I dislike about it.  I'll have to
> think about this.

I know, I felt very similarly at one point.  It turns out to be
remarkably nice, especially if your 'real' root has a few other
/rescue-type tools. Note that init runs in a loop around the sysctl,
so you can start up and shutdown entire userland copies from the
internal root - very handy for testing and rolling back upgrades, as
just one example.

--
Dan.

--LmeqhziFqEm+Ep0k
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFGumTSEAVxvV4N66cRAsC5AJ4g7VNMFkpGrtvQaUvs+QvtDjYpJQCg9lm2
/mvgD6fcm5b6XAcTCot9t18=
=u5eJ
-----END PGP SIGNATURE-----

--LmeqhziFqEm+Ep0k--