HLFS Future ?

Steve Thomas steve at a530.co.uk
Wed Jan 25 15:52:11 PST 2017


Insightful thoughts for sure, thanks. I still believe there is a case 
for HLFS, let me explain why I think so.

There is still no other linux system out there that allows you to setup 
a system from the ground up, in the same way that HLFS does. Gentoo and 
no doubt a few others have the optional hardened packages and thats ok 
for some. The issue I take with them is that you have no option but to 
start with a whole bunch of pre-selected packages that the developer 
thinks you need. Im hesitant to use the term bloatware here, however, I 
potentially end up with what a group of total strangers think I may 
need.  It becomes so generic; they don't know me, they don't know the 
intended use for the build, it becomes difficult if not impossible to 
know each individual package in the build. The options I am left with at 
that point are to use it as-is, or start stripping out unwanted packages 
at my peril. It is almost self-defeating in a way; yes you have a 
choice, but to come anywhere near to an optimal well hardened build, you 
have to start reversing what other people have chosen for you already, 
hope the system continues to work and hope there is nothing left behind 
that compromises the build or its security.  I'm not saying that overall 
approach does not have its place, it absolutely provides a good starting 
point to customize a standard desktop system.

In my mind, the hardened build needs to completely turn the above 
approach on its head. The 'less-is-more' strategy is absolutely the 
right way to go about things here and it provides a far more suitable 
build. I don't then run the risk of having near invisible packages that 
may be presenting security flaws by default, just because they are 
installed by someone who thinks I might need them.  With a HLFS build, I 
know every single package thats is installed, period. I know they were 
built with the hardened toolchain and I know they were configured for a 
higher level of security/hardening at the time of building.  If I want 
to add certain functionalty, I simply add the minimal packages required 
to support that, and configure each one in turn to match the exact 
requirement.  The end result is a build that is lean, minimalistic and 
secured from the ground up. Just as importantly, I know every single 
aspect of the build; nothing can be hiding away deep in the bowels of 
the system without my knowing about it.  That simply could not be said 
of a Gentoo hardened build or some other security enhanced build, unless 
it too was built by the end user from the ground up.  Sure you could 
start with one of those systems and then sit tweaking, rebuilding, 
hardening, adding and removing packages, configuring etc.  Eventually 
you could get to the same end result.  But for those looking to custom 
build a hardened, minimalistic system, would they likely want to use 
that approach or start from zero and build from the ground up ? I know 
what my preferred choice would be.

Let me be clear, I'm not dismissing what Gentoo and others offer; far 
from it. I used Gentoo myself for a long time (Many moons ago) and it 
was a very capable system.  What I am talking about here though is the 
purist approach to building a hardened and security enabled desktop or 
server.  A pre-packaged linux, no matter how good it is, simply does not 
offer the approach I would prefer to use.  We can eventually reach the 
same end result from either of the approaches above, but which would 
provide the highest level of confidence in the finished product and most 
intimate knowledge of the built system ?  To me, the HLFS approach, 
hands down, wins every time.

I totally agree with what you mention about a book or section that goes 
into hardening options and defaults in more detail.  It could even give 
the user several choices for each option i.e choose option x,y,z if the 
intended system will be a server, otherwise choose options x,y for a 
hardened desktop.

In relation to LFS, I think the 2 books are too far apart for HLFS to 
not have its own place, as you briefly touch on.

HLFS was always a great way to learn about and build a hardened and 
secure system that could be used in a production environment; I only 
hope that could continue.

On 25/01/2017 19:30, robert baker wrote:
> There have been other developments along the way that could change or 
> impact the mission of HLFS if it were to continue.
>
> The smashing stack protector is on in GCC by default in version 4.8.3 
> and later. Fortify source is integrated into GCC these days. I'm not 
> sure it is on by default in the GCC default spec, but many distros 
> turn it on. The difference between the HLFS toolchain and the 
> mainstream distros is narrowing.
>
> The other side of the issue 5 years on is what the public has learned 
> in this time. With hardware interdiction and government sanctioned 
> hardware weaknesses in mass manufactured hardware I can't say whether 
> a project like this is more important, or moot.
>
> The mission could come down to a book that instructs users on enabling 
> more hardened defaults. Perhaps even instructions on managing RBAC 
> policies or other advanced topics would fit. I tend to side with the 
> argument that the project still makes sense in its niche in as much as 
> it differs from LFS mainline.
>
> Robert
>
> On Wed, Jan 25, 2017 at 1:05 AM, Steve Thomas <steve at a530.co.uk 
> <mailto:steve at a530.co.uk>> wrote:
>
>     Joining those dots a little, HLFS stated that its aim was to
>     produce a hardened system suitable for use in a production
>     environment; it used the stable branch of grsec.
>
>     Grsec stable is now commercial. Grsec state the test branch should
>     not be used on production systems. Gentoo uses the test branch for
>     exactly that purpose.
>
>     In the spirit of how HLFS operated, should we be trusting the test
>     branch ?
>
>     I don't see anything on the grsec website regarding end users
>     having the option to pay for the stable branch if they want to; it
>     seems more geared towards commercial organisations/companies.
>
>     If everything is true regarding those embedded linux companies
>     taking advantage of grsec's work and violating the GPL, thats
>     pretty disaapointing since they have spoilt it for the rest of us.
>
>     Where does this leave us going forward in respect of hardening
>     options ?
>
>     From my own perspective, I never used or applied HLFS in any
>     commercial setting; I used it for personal use to learn about the
>     process of building from the ground up, knowing every package that
>     was installed and building a small but very capable server that
>     was used to securely store mass data. It never failed me once, and
>     the learning experience was both fun and educational.
>
>
>     On 25/01/2017 02:29, robert baker wrote:
>>     I would be interesting in reviving the project as well.
>>
>>     I am familiar both with how the book is built, and approximately
>>     where we left off.
>>
>>     There have been at least one notable change that will have an
>>     effect on the project. Stable Grsecurity patches are for paying
>>     customers only now.
>>     https://grsecurity.net/announce.php
>>     <https://grsecurity.net/announce.php>
>>
>>     To my knowledge Gentoo uses the test version of the grsec patch.
>>
>>     I'm not sure who exactly to reach out to about an svn account but
>>     I can drop a line on one of the other LFS lists.
>>
>>     On Tue, Jan 24, 2017 at 1:20 PM, Jason Stevens
>>     <jastev at alumni.rice.edu <mailto:jastev at alumni.rice.edu>> wrote:
>>
>>         Agree.  I have time to donate, but I'll need help coming up
>>         to speed on the specific technical chops.
>>
>>         -jps
>>
>>         On Jan 24, 2017, at 10:00 AM, Steve Thomas <steve at a530.co.uk
>>         <mailto:steve at a530.co.uk>> wrote:
>>
>>>         I would sure like to see this project get some life again. I
>>>         don't have the technical knowledge to test packages and hunt
>>>         down errors and bugs though, so can only offer end user
>>>         testing in respect of the processes in the book.
>>>
>>>         I have a small server sat here that is just begging for a
>>>         decent and secure OS, which I would like to be linux. I
>>>         would run HLFS on this in a heartbeat if it was up to date.
>>>
>>>         The changes I have seen in the last few years with other
>>>         mainstream OSes don't give me much confidence.  Knowing and
>>>         building the system from the ground up would be perfect and
>>>         why I originally got started with HLFS.
>>>
>>>         I hope some consideration can be given to breathing life
>>>         back into HLFS.
>>>
>>>         On 24/01/2017 00:43, robert baker wrote:
>>>>         The last person who worked on the project to my knowledge
>>>>         was Robert Connolly. Perhaps he is still subscribed to the
>>>>         list.
>>>>
>>>>         I once tried to contribute myself, but I didn't get to
>>>>         devote a great deal of time and I believe my SVN account
>>>>         has since been disabled.
>>>>
>>>>         It should be reasonable to bring things in the book up to
>>>>         date borrowing from a modern hardened Gentoo.
>>>>
>>>>         Robert
>>>>
>>>>         On Mon, Jan 23, 2017 at 6:22 PM, Steve Thomas
>>>>         <steve at a530.co.uk <mailto:steve at a530.co.uk>>wrote:
>>>>
>>>>             Its now well over 5 years since any update.
>>>>
>>>>             Are we to assume this project is now officially abandoned ?
>>>>
>>>>             Thanks.
>>>>             -- 
>>>>             http://lists.linuxfromscratch.org/listinfo/hlfs-dev
>>>>             <http://lists.linuxfromscratch.org/listinfo/hlfs-dev>
>>>>             FAQ: http://www.linuxfromscratch.org/blfs/faq.html
>>>>             <http://www.linuxfromscratch.org/blfs/faq.html>
>>>>             Unsubscribe: See the above information page
>>>>
>>>>
>>>>
>>>>
>>>
>>>         -- 
>>>         http://lists.linuxfromscratch.org/listinfo/hlfs-dev
>>>         <http://lists.linuxfromscratch.org/listinfo/hlfs-dev>
>>>         FAQ: http://www.linuxfromscratch.org/blfs/faq.html
>>>         <http://www.linuxfromscratch.org/blfs/faq.html>
>>>         Unsubscribe: See the above information page
>>
>>         --
>>         http://lists.linuxfromscratch.org/listinfo/hlfs-dev
>>         <http://lists.linuxfromscratch.org/listinfo/hlfs-dev>
>>         FAQ: http://www.linuxfromscratch.org/blfs/faq.html
>>         <http://www.linuxfromscratch.org/blfs/faq.html>
>>         Unsubscribe: See the above information page
>>
>>
>>
>>
>
>
>     --
>     http://lists.linuxfromscratch.org/listinfo/hlfs-dev
>     <http://lists.linuxfromscratch.org/listinfo/hlfs-dev>
>     FAQ: http://www.linuxfromscratch.org/blfs/faq.html
>     <http://www.linuxfromscratch.org/blfs/faq.html>
>     Unsubscribe: See the above information page
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20170125/ad154912/attachment.html>


More information about the hlfs-dev mailing list