book

Dagmar d'Surreal dagmar.wants at nospam.com
Tue Apr 13 00:09:33 PDT 2004


On Tue, 2004-04-13 at 00:09, Robert Connolly wrote:
> On April 12, 2004 11:16 pm, Dagmar d'Surreal wrote:
> > On Fri, 2004-04-09 at 22:58, Robert Connolly wrote:
> > > On April 10, 2004 01:24 am, Kendrick wrote:
> > > > Robert Connolly wrote:
> > > There are plans to have a blfs section part of the hlfs book. Mail
> > > service could use its own subdirectory since it has so many ways of being
> > > used. I can think of a million ways of going nuts with securing services,
> > > and how they relate to eachother. Scenarios would need to be written I
> > > suppose.
> >
> > That's almost a certainty.  I never found a really decent way of
> > explaining hardening without just showing someone the most restrictive
> > way of configuring things for specific tasks.
> 
> We still going with the 'every security option turned on' theme? The clock 
> script can come out of the boot scripts, there's a grsec option that would 
> prevent it from working. Since everyone rebuilds the kernel as part of a 
> standard install, I think its reasonable for people to just hardcode their 
> timezone (if bios isn't GMT). Do we want to maintain the ash compliance for 
> bootscripts?

Well, for one, the BIOS _should_ be set to GMT because GMT is not
affected by regional timezone differences and can not be adversely
affected by unexpected power loss.

...and it's not a matter of "every security option turned on" so much as
it is "everything not absolutely necessary is disabled".  The majority
of these security features merely remove functionality that is not
explicitly allowed.  (Why on earth would we explicitly allow executeable
stacks, when we know the mechanism to be routinely exploited and we
don't need it for anything else?)  I know that strictly speaking we
should create a new kernel and operating system from the ground up to
accomplish this, but that's not particularly realistic, so we've gotta
go through the grunt-work of hardening that is essentially uncovering
the things that are currently allowed, and turning them off, one after
the other.

I don't see much sense in maintaining ash compliance, since LFS is using
bash as the administrative shell.  Those who wish to use ash should
merely have to recode parts of the scripts for their own use (this isn't
all that hard).  The only people who would want to use ash are likely
those attempting to boot off ridiculously tiny ro media (like a single
floppy) and should be considered the minority case, IMHO. 
-- 
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