Hlfs iso?

Dagmar d'Surreal dagmar.wants at nospam.com
Wed Mar 10 11:17:43 PST 2004

On Wed, 2004-03-10 at 09:27, Robert Connolly wrote:
> On March 10, 2004 09:06 am, Dagmar d'Surreal wrote:
> > On Mon, 2004-03-08 at 04:40, Robert Connolly wrote:
> > > 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.
> Others have been developing this kind of stuff (rbac,aslr,pie) for several 
> years. In general none of them use it to its full potential out of the box 
> because it has taken this much time to mature. XFree86 apps don't work very 
> well with pax, so security options are disabled for these applications by 
> most vendors. For our purposes I felt it was better to break xfree86 support 
> (for now) and keep security options enforced globaly without exceptions for 
> wild apps. The only condition is the system needs to be able to rebuild 
> itself. It should be able to do it, with all the testsuites passing, to show 
> our base source is stable with the kernel security turned on. The point is, 
> you need a trusted system to build a trusted system, and you shouldn't need 
> to disable security in order to build or upgrade (if you do it should be 
> intentional not indirectly).

You don't appear to get it.  "Security" is not just a arbitrary value
level that you can raise up or down depending on effort expended or pour
on like maple syrup.  While it's a nice feature, our "trusted" system
doesn't need to be able to replicate itself because that's a feature of
a developers platform.  It should be perfectly reasonable to accept a
known stable system to develop from.  With respect to security, a
self-validating toolchain is about useful as C2 certification to a
webserver.  Unless the security measures taken reflect the computing
environment and requirements, the result is going to be half-assed.

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