conathan at conet.dyndns.org
Tue Apr 13 00:49:38 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
>> > > used. I can think of a million ways of going nuts with securing
>> > > and how they relate to eachother. Scenarios would need to be written
>> > > 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
>> script can come out of the boot scripts, there's a grsec option that
>> prevent it from working. Since everyone rebuilds the kernel as part of a
>> standard install, I think its reasonable for people to just hardcode
>> timezone (if bios isn't GMT). Do we want to maintain the ash compliance
> 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.
What kind of changes were you making to the bootscripts anyway? Would be
nice if we can keep the 2 tree's close together.
More information about the hlfs-dev