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-boun...@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. robert
<<winmail.dat>>
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
