Pushing forward with Onward.

Robert Connolly robert at linuxfromscratch.org
Wed Jun 17 13:59:29 PDT 2009

On Wednesday June 17 2009 02:43:07 pm robert baker wrote:
> I am all for staying current so long as there are no breakages. I
> would be more than willing to do a test build with an upgraded GCC
> this next run through. Are you talking about moving up to GCC-4.4.0 or
> do you have another release in mind?

I'm not sure. I don't even know the differences between gcc42 and gcc44, but 
in general newer gcc versions produce healthier systems, as long as the other 
packages are using compatible source code.

Many distributions have patches to fix compiler warnings. After confirming the 
warning, I like to compare these with the package's cvs, and submit it a bug 
report if it's not in upstream, and observe the feedback. If it's in upstream 
then it's considered an upstream fix. Don't use these patches blindly, 
remember what happened with debian and ssl.

> Would you be interested in outlining any goals that you would like to
> see set for the "stable" revision of the book? I am absolutely
> interested in lending a hand wherever I can.

Just pretty much enough to get the user on their feet.

Replace suid-root with capabilities, giving enough examples and debugging tips 
so the user knows what to do with blfs packages. Same with grsecurity rules, 
have enough examples and debugging tips so blfs packages aren't a problem. 

Use the blfs wiki pages to add help on a per package basis, and mention in 
hlfs book that users should check the blfs wiki for every package. If the 
tips are very hlfs specific, maybe just add a link to the blfs wiki for the 
hlfs wiki, to keep the blfs wiki cleaner.

Add iptables to the rebooted system, and sshd, for users doing a remote build.

The package/file management system discussed before. It needs to be simple so 
that using it is easy and second nature.

Adding fcron to the final system is a good idea. This can do log rotations, 
reseed /dev/erandom, clean /tmp, with /etc/daily and /etc/weekly scripts. 
Nothing crazy.

With posix capabilities daemons don't need privilege separation anymore. I 
haven't looked into this though. Debian has a 'runas' program that is 
basically like 'su -c foo bar' but it cleans the environment too. 'env -i 
su -c /usr/sbin/sshd sshd' might work. Daemon program files with capabilities 
need to be readable only by owner and group, not other, with the daemon user 
in the group.

Grsecurity could use a little more tightening, by adding a networking group 
and only allowing that group to open sockets. Trusted path execution might 
become unusable with the file management user owning every system file and 
directory, but there may be a way to workaround or fix it.

A while ago I tried to get libcap added to BLFS, but libcap was not maintained 
at that time, and needed a lot of patches to build, so BLFS decided against 
it. Libcap2 is maintained now, and I think BLFS would add it. They have 
enough to do without libcap, so we should maintain this for them. Almost 
every daemon in BLFS can use capabilities to drop root. After the initial 
patch, the maintenance should be as simple as upgrading the libcap2 package, 
and adding it to new blfs daemon's from time to time. The initial patch will 
be a major pain, involving installing every single blfs package with 
suid-root programs and root daemons. This is all of gnome, kde, and pretty 
much everything else. After a few of us do this, and confirm it works, I 
think we'd have a stable hlfs candidate.

--warn-shared-textrel --fatal-warnings causes a build failure if mktemp() or 
tmpnam() are used. This affects a few blfs packages. I have patches for the 
packages I found. Hopefully blfs will accept these patches, otherwise they go 
to blfs wiki.

I don't think we've come this far to slap a "stable" sticker on whatever we 
have and promote it. Everything needs to be checked ten times, then continue 
to the next task, until everything is done, then check it again. Then use 
the "we did it" sticker.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20090617/c4a43ce2/attachment.sig>

More information about the hlfs-dev mailing list