Onward branch development

Robert Baker RBaker at newpark.com
Tue Feb 3 18:40:48 PST 2009

I just checked out what you have in svn so far. I will try to find some time to compile a temp system, and look at making it bootable. The clfs boot scripts look like they would work. The only difference between the final system, and the temporary one is the $PATH is changed from "/bin:/usr/bin:/sbin:/usr/sbin" to "/tools/bin:/tools/sbin:/bin:/sbin" inside the functions file. The scripts themselves from what I have looked at so far are relying on $PATH exclusively. The read only root shouldn't be too tricky either. I converted one of my hlfs boxes to a read only root using symbolic links. I did have to adapt some of the init scripts, but no drastic changes were necessary. I will try to tackle some of this throughout the week if you would like. 

From: hlfs-dev-bounces at linuxfromscratch.org on behalf of Robert Connolly
Sent: Tue 2/3/2009 6:43 PM
To: Hardened LFS Development List
Subject: Re: Onward branch development

> Is there any part of the project with which you could use any extra
> help?
> --Joey

I need help getting the temporary system to reboot. It will need modified boot
scripts. I don't know if the boot scripts from CLFS's temporary system will
work for us, but if they work then it's less for us to maintain.

I would like packages in /tools to use /tools exclusively, so no symbolic
links from /tools/bin to /bin are needed to boot. CLFS does not do this...
they install some packages to /mnt/clfs/, so this might be a problem if the
boot scripts use full path names for /sbin/udevd (for example).

It would be usefull if this temporary system reboot is compatible with a cdrom
boot, with a read-only file system, but it's not necessary right away. I
would like this even when booting from writable media, because it sets a good
example for minimizing privileges. If I remember correctly, from the
readonly_rootfs, glibc can be configured to use a different path
for /etc/mtab, so that /etc can be read-only, or a symbolic link might work.

The main goal for rebooting is to minimize host kernel dependencies, so we
reboot to a new host which supports extended attributes, so we can setup suid
programs, and so we have ideal expectations from Glibc's test suite because
we booted a kernel with all the drivers Glibc's test need. A secondary goal
is to build from a trusted system/host, one that is hardened to the farthest
extreme that our final system will be.

There's also plans for add-ons for the reboot, for things like networking or
braille. This is not only add-ons for the temporary system, but also bhlfs.
This would include firewalling, network tunneling, encrypted filesystems,
intrusion detection, and is a huge animal I have never had time for. I do
most of this stuff on my desktop at home, but documenting it is different.

There are a lot of other details to add, to harden the temporary system, but
rebooting is the first thing.

There are also a lot of packages to upgrade, but I prefer to do that myself.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5398 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20090203/621b1d5d/attachment.bin>

More information about the hlfs-dev mailing list