[gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.

[gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.

[basile]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Hi,

It was suggested to me that I write this list about backporting
something to gentoo from Tin Hat which is a distro derived from
hardened gentoo.

First a bit of history: Last year a group of us decided to put
together a linux distribution which aimed at the ideal that physical
access to a box (at least when powered down) meant the attacker could
get *no* information whatsover about the running system.  (We
concerned ourselves with issues like hard drive encryption hides the
data, but some implementations like cryptsetup put down a header which
would reveal to the attacker that there plausibly *is* encrypted data
present.  So we chose implementations in which the attacker would not
be able to tell if he/she were looking at an encrypted drive or just
random bits.  Real toil foil hat stuff.)  We also wanted a system that
would be useful as a desktop and secure from all the usual suspects
when running.

We decided to use hardened gentoo as a base, but had to branch because
1) we had to restrict the choice of profile/USE flags, 2) we had to do
unspeakably nasty things to the kernel, like compiling it
monolithically for a wide range of hardware,  3) we had to build our
own customized busybox, initramfs image and boot scripts up to
/sbin/init and 4) we put the entire OS in RAM.  Literally *everything*
is done in RAM in tmpfs: updates pulled down with portage, compiling
kernels, building ISO images for releases, etc, all done purely in
RAM.  Just using Tin Hat requires 4GB of RAM, while
developing/building new releases requires 6GB-8GB.  These number are
no longer out of the range of reasonably priced computers.

Point 4 is what I think would be useful to Gentoo mainstream.  The
speed one gets from RAM totally beats a LiveCD using unionfs which has
to periodically return to the slow cdrom.   I've tried building custom
LiveCDs for courses that I've taught but the students (=users) hated
them.  In contrast I am now teaching an embedded systems course and I
put all the needed utilities (eg. crosscompilers, qemu, etc) into a
"ramified" system which the students love because of the speed.  So I
think many Gentoo users might like this feature and we could
simultaneously develop the scripts for both Gentoo and its derivative
Tin Hat.

We have written a series of scripts to "ramify" a system.  There are
two versions: A) take an OS bound to the hard drive and build an ISO
image which will boot and put the system totally into tmpfs, B) take a
system which is already "ramified" and build an ISO which will again
boot purely into RAM, ie build a snapshot.   A user could use scprits
A to ramify a custom built system and maintain it in ram with scripts
B.  Also, Gentoo "releases" could be distributed already ramified.

To port this back, I would have to modify the scripts to deal with a
modular kernel and the way initramfs is built using genkernel.  I
would also need to write the ebuild.  No problem, but I would like
some feed back from the list regarding whether this is something worth
trying and any advice on how to proceed, eg. should we write our own
portage overlay?

The Tin Hat homepage is at

    http://opensource.dyc.edu/tinhat

The repository is at

    http://opensource.dyc.edu/pub/TinHat


- --

Anthony G. Basile, Ph.D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
USA

(716) 829-8197

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmEbHoACgkQl5yvQNBFVTW61wCdFZHuxi8dtNCOfQh7VEYwv1q8
/zkAoKbanGQaCC6X1Nm7xKnSuNKUmXvw
=k0KG
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hiya Anthony,
	First off, it certainly sounds interesting and making it more
accessible (simple ebuild setup and so on) seems like a good plan even
if it doesn't get picked up officially.  The best way to start
development would probably be an overlay, which will make it easy to
bring into the tree if/when a developer wants to pick it up officially.
	You might also want to look into integrating your "ramification"
process into catalyst the gentoo release building tool (the release
engineering team can probably tell you more about that than I can).
	Also, reading the TinHat front page and mention of ram dumping, you
might be interested in [2].  It suggests not leaving the key in RAM when
it's not necessary, but shoving it into the CPU cache...
	Mike  5:)

[1] http://www.gentoo.org/proj/en/releng/catalyst/
[2] http://frozencache.blogspot.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmEcQgACgkQu7rWomwgFXp+3ACghLB+686vqMLqcEm9Ye3gM1JN
KKQAoJ4R3dyx5KcVeg6+9OugRsCA0nha
=MCQf
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.

[Andrew Gaffney]

basile wrote:
> Point 4 is what I think would be useful to Gentoo mainstream.  The
> speed one gets from RAM totally beats a LiveCD using unionfs which has
> to periodically return to the slow cdrom.

This is already possible. With current genkernel (genkernel-9999 or
genkernel-3.4.10.903), you can boot with 'docache unionfs', which will copy the
squashfs to tmpfs, mount it, and then use unionfs-fuse to create a union with
another tmpfs.

Genkernel has offered the 'docache' option for quite a while, which has mostly
the safe effect, but without the unionfs, it uses nasty tricks like copying some
stuff to a tmpfs and then doing lots of symlinks into the squashfs.

Either way, it's entirely memory based after initial boot.

-- 
Andrew Gaffney                                 http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer            Catalyst/Genkernel + Release Engineering Lead

Re: [gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On 10:21 Sat 31 Jan     , basile wrote:
> We have written a series of scripts to "ramify" a system.  There are
> two versions: A) take an OS bound to the hard drive and build an ISO
> image which will boot and put the system totally into tmpfs, B) take a
> system which is already "ramified" and build an ISO which will again
> boot purely into RAM, ie build a snapshot.   A user could use scprits
> A to ramify a custom built system and maintain it in ram with scripts
> B.  Also, Gentoo "releases" could be distributed already ramified.

Great to hear from you! Have you seen the 'docache' kernel parameter? It 
used to stick the LiveCD into RAM -- I haven't used it lately but I 
assume it's still around. I'd think it would be straightforward to apply 
the same feature to an installed Gentoo system.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]