-unstable 20070327

Robert Connolly robert at linuxfromscratch.org
Tue Mar 27 02:07:05 PDT 2007


LFS-unstable-glibc isn't as broken anymore. Kernel compiles, 
with -D_FORTIFY_SOURCE=2 too but it takes longer. All the packages and 
patches are up to date, the conflicting patches were worked out, etc.

I have plenty of ideas on how to destabilize it some more...

My TODO list:

The gcc-4.1.1-DW_CFA_val.patch adds a backport, from gcc-4.2 I think, which 
adds a feature which helps a Glibc test pass.

gcc-4.1.1-fast-math-i386-Os-workaround.patch fixes the issue with -Os and 
uClibc, although this is probably a good idea to fix even with Glibc.

I noticed Debian has a gccbug patch for posix compliance.

Add Autogen to chapter 5, maybe 6 too, because the gcc (fixinc) test suite 
wants it.

Add Autoconf and Automake to chapter 5 to add robustness... the Gawk config 
bug could be fixed better with this. These depend on a full installation of 
Perl.

Add BC to chapter 5 for the OpenSSL test suite.

Adding Valgrind to chapter 5 is still an idea because several packages support 
it for regression tests... I've noticed that in general test suites test for 
expected results, not for unexpected results like Valgrind will. Having 
Valgrind would let us test packages in much more depth, and would also help 
test packages which do not have test suites. Testing GCC with Valgrind is 
pretty nuts, I've never completed it but I'm estimating something like 1000 
SBU's and maybe more (I give up when my CPU increases my room temperature 10 
degrees after three days of 100% load), but other packages like Grep aren't 
so heavy.

Finish adding Blowfish to Shadow and Sysvinit.

Make -viol-abort the default behavior for libmudflap. syslog suid 0 aborts.

The unused return value warnings from fortify_source are really best fixed 
upstream because each sanerio is different. I'm going to start sending bug 
reports on them. I've noticed on Google that many developers are fixing these 
warnings recently.

Chapter 5 Coreutils 'su' is needed for chapter 6 Bash's test suite because it 
likes to run as non-root, there might be a security reason for this too. With 
a /tools/bin/su this opens up the possibility of building and testing _all_ 
packages as a regular user, to help maintain the security of the host system.

It'd be nice to catalog new files as each package is installed, with a find(1) 
script or something similar, and maybe toss in md5sum too. So if two packages 
install the same file we know about it.. so we know 
whether /usr/share/man/man1/su.1 is from Coreutils, Util-linux, Shadow, or 
something else. It'd also be usefull for tripwire-like setups, and a 
foundation for package management (automated or otherwise).

Integrate the eswap hint (optionally) for encrypted swap space, maybe some 
pointers on encrypting cdroms and /home directories.

Add Owl's Sysklogd chroot/privdrop patches.

Add libsafe (optionally).

Put erandom back, maybe arc4random too. These are still ideal for ssp and 
mktemp.

Overhaul Shadow-utils:

 Configure /etc/login.defs better, like with SU_WHEEL_ONLY and DEFAULT_HOME, 
or at least mention it on the Shadow page.

 I can't get recent versions of Shadow to run with mudflap. 4.0.4.1 partially 
does... src/ can link programs to libmudflap, but not lib/ or libmisc/. This 
may not be such a bad thing because the older versions of Shadow have 
received more real world testing by distributions and are still working well.

 According to doc/README.linux, libshadow is a private/internal library.. only 
Shadow-utils should be using it since shadow functions are in Glibc and 
uClibc. So there's no reason it needs to be installed. The README says if 
another package tries to link to libshadow then just remove the -lshadow and 
it should get what it wants from libc.

 The Shadow-Password Linux Howto suggests making /etc/shadow group readable by 
group "shadow", so that programs like screensavers can authenticate passwords 
without having write, or root, permission to /etc/shadow... by installing the 
screensaver program sgid "shadow".

 Owl's TCB doesn't appear to depend on PAM, while it does support PAM, but the 
README says it does depend on crypt_blowfish in Glibc. TCB, if I'm 
understanding it properly, has each user owning their own shadow password 
file so that they can change password/age/comments without root privileges, 
with group read permissions for other programs like screensavers, and of 
course root can still read them for login.

 This should leave Cracklib and PAM optional and in the BLFS book, with links 
on the top of the TCB page (which would come before the Shadow page) in the 
HLFS book, for anyone who wants to use them.

 An S/key howto link would be nice too, since Shadow supports it.

There's more, but this is enough for now.

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


More information about the hlfs-dev mailing list