Hlfs iso?

Dagmar d'Surreal dagmar.wants at nospam.com
Wed Mar 10 06:06:08 PST 2004

On Mon, 2004-03-08 at 04:40, Robert Connolly wrote:
> On March 8, 2004 05:10 am, Kendrick wrote:
> > > Therefore, a HLFS ISO would either need to be as basic as
> > >possible (i.e. only provide a hardened LFS system) which would be
> > >largely useless (in a prod. env.), or provide hardened versions of every
> > >package in BLFS,
> >
> > I am wondering if it was ment ..   have either a hardend lfs bootable
> > disk to build hlfs localy to any computer with/or wo os-  a known good
> > base..  ie rh 7.3 wouldent work because of mods to glibc yet 7.2 would
> > for lfs 4.0  the other though would be  a hfls automated profile sitting
> > on a boot cd.
> I dont see why the CD cant do all of those things at the same time. A bootable 
> CD with a few blfs packages (iptables, pam, openssh, maybe tripwire, etc), 
> with a nalfs profile included. So it could be used to build from an existing 
> system, by hand or with nalfs, or it could boot itself and install by hand or 
> nalfs.

You can't harden a system until you know what it's supposed to do,
therefore a "hardened" ISO is a bit of a contradiction.

> There is still a problem with binutils I haven't fully fixed yet. When the 
> testsuite compiles with -pie several tests fail because they get unexpected 
> results. Most of these can be fixed. Pax_flags also gives unexpected results 
> and fails another test, this one I dont know how to fix because I dont see 
> how the Expect scripts work. This needs to be fixed before there's an iso 
> made. All the other testsuites should pass.
> And binutils-2.15 should release soon (with -pie), making flex, bison, and m4 
> unnessesary in chap5. Previous discussions sounded like the majority of you 
> wanted to keep m4, flex and bison in chap5 even if they are not nessesary.
> I haven't tested it, but the bootcd should be able to build with all but one 
> PaX kernel option enabled. This might not be a great idea for the bootdisc 
> kernel though. Unless you expect to be attacked while running the HLFS 
> install it would only add unessesary overhead and increase SBU times.

If you were suicidally stupid and installed over a hostile network, this
might be an issue.  On general principle no machine should be exposed to
a hostile network until it's been brought up to date and ready to defend
itself, so to speak.

> For 
> bootstrap and testing reasons we might want to build with all security 
> options enabled. This could use some discussion. Might also want to include a 
> Grsec patch in the iso, so its available if users prefer it to 
> PaX-standalone.

If you can get all the build tools and the source tarballs onto media,
go for it, but the majority of the real work you're not going to be able
to script.

The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at jabber.org

More information about the hlfs-dev mailing list