This document gives details on how data encrypted within the root 
filesystem can be plausibly denied. It is accurate for the following 
JayOS releases:

	20061108 (x86 and iMac)


1) The easiest way to build your own root filesystem with hidden
encrypted data is to first build JayOS from source (see /lfs/build.sh
and JayOS-Building.txt), modify a Makefile to activate "addons", then
re-run make to rebuild the root filesystem.  This section will show what 
needs to change within /lfs/usr/src/Makefile.

Three variables control the building of a root filesystem with "addons", 
and the location of data to be inserted into the root filesystem.

	ADDONS=0
	ADDFS=myaddons.tbz
	ADDFSDIR=/lfs/usr/src

If ADDONS=0, the build process will complete without attempting to create
addons. Setting ADDONS=1 and leaving the other two variables alone will
build a root filesystem loaded with the the default data within myaddons.tbz.

The target stanzas that handle this are addons and root-generic.


2) Once you have created your own ADDFS tarball (or use the default), 
set ADDONS=1, change directories to /lfs/usr/src, and run:

	make isox86

The isox86 target does the following:

	builds a kernel using the x86 kernel config,
	builds a root filesystem,
	builds an initial ramdisk,
	creates a bootable ISO image containing the above, plus 
		the usr filesystem (created with "make usr" earlier)

During the build of the root filesystem, you will be prompted twice
to enter a password. Don't fat finger it--the build will keep right on
going if the passwords don't match. Be careful not to use too large of an
ADDFS tarball compared to the size of the root filesystem. Five megabytes
of data for a 68 megabyte filesystem seems comfortable from my tests,
but you can also adjust ROOTSIZE= upwards if you need to.


3) Testing the ISO

Might as well use QEMU. Try the following command:

	qemu -m 256 -cdrom /lfs/build/jlfs-x86.iso -localtime \
		-net tap -net nic

When you reach the boot prompt, enter "qemu addons". QEMU will continue
to boot until the screen goes blank and it appears to hang. At this point,
it is waiting for you to enter a password. Under a native boot, the prompt
is shown, but something about QEMU emulation blanks the screen. You can
either enter the password there and hit enter, or press ctrl-alt-3 and
log into the getty running on tty3 as root (the password is not root's,
who has none, but the one set earlier). After logging into tty3, swap back
over to tty1 with ctrl-alt-1 and hit enter. 

It's much more straight-forward when booting natively :)




3) The hooks

Among other things, the tarball myaddons.tbz contains /addonsrc, an executable 
script that is launched by /root/.bash_profile.

The following code found within /root/.bash_profile will, upon finding
"addons" on the boot command line, extract the encrypted myaddons.tbz
from the root filestem and prompt for a password.

#
# from /root/.bash_profile
#
if [ ! -f $ADDFLAG ]; then
    for i in `cat /proc/cmdline`; do
        case $i in
            addons)
                /initrd/bin/busybox rune /dev/ram1| \
                    /usr/bin/aespipe -d -e aes128| \ 
                    tar jxvf - -C / >/dev/null 2>&1

                if [ $? -eq 0 ]; then
                    /addonsrc 2>/dev/null
                    rm -f /addonsrc
                    touch $ADDFLAG
                fi
                ;;
        esac
    done
fi
#
#
#

If a null or incorrect password is given, nothing happens. Otherwise,
/addonsrc is executed and then removed from RAM.

The sample /addonsrc within myaddons.tbz modifies /root/.xinitrc to print
a custom banner during X11 startup. Of course it could do anything else
you want it to, this is only an example.


4) Customization

The first thing I would do is change the name of the kernel
parameter "addons".  It is referenced only in /root/.bash_profile
(/lfs/usr/src/skel//root/.bash_profile). Can't have everyone walking
around with the same trigger, can we?

Next, it is fairly easy to alter the code above so that the code itself
is removed from /root/.bash_profile after its first execution. This would
allow one to deny knowledge of any triggers that prompt for passwords,
because only the presence of the trigger as a boot prompt will activate
the code and the code is erased by the time the boot has completed,
leaving no evidence.

Don't forget that the loaded root filesystem sits unencrypted on disk, so
I would go one step further and either encrypt all of the root filesystem, 
or encrypt the real /root/.bash_profile within the initial ramdisk for
manual access. Both methods are detailed within JayOS-Encryption-HOWTO.txt.

(Note that a fully encrypted root filesystem is incompatible with "addons"
for reasons unknown. Whenever I've tried, the filesystem gets so corrupted
it won't even boot, but YMMV).