-unstable 20070327

Jan Dvořák mordae at thirdcms.org
Tue Mar 27 10:09:25 PDT 2007

Robert Connolly wrote:
> 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.
Great job. Maybe render html and upload?

> Finish adding Blowfish to Shadow
-1; I still don't like the way it is... It should not be that hard to 
emulate these with our own libcrypt.so linked with openssl and act like 
we don't know anything about MD5s, DESes, fishes etc.;

FUNC    WEAK   DEFAULT   12 crypt_gensalt_ra
FUNC    WEAK   DEFAULT   12 fcrypt
FUNC    GLOBAL DEFAULT   12 setkey
FUNC    WEAK   DEFAULT   12 crypt_rn
FUNC    WEAK   DEFAULT   12 crypt_r
FUNC    WEAK   DEFAULT   12 encrypt_r
FUNC    WEAK   DEFAULT   12 crypt_ra
FUNC    WEAK   DEFAULT   12 crypt
FUNC    GLOBAL DEFAULT   12 encrypt
FUNC    WEAK   DEFAULT   12 crypt_gensalt
FUNC    WEAK   DEFAULT   12 crypt_gensalt_rn
FUNC    WEAK   DEFAULT   12 setkey_r

> 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.
+1; Until then, see my recent e-mail.

> 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.
+1; doing this anyway because of package management requirements...

> 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).
What about unionfs overlay? I've build whole system with it (and I do 
write an e-mail in tbird using it) with UnionFS. Seems stable enough to 
me. Still working on it. Basically, you overlay /, mount --bind /proc, 
/sys, /dev and /tmp, build package in /tmp and install. Then merge the 
stuff to the system.

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

> Put erandom back, maybe arc4random too. These are still ideal for ssp and 
> mktemp.
+1; I missed them.

>  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".
Not sure about this. Maybe get some tested safe code that can check 
single user's password for the screensaver, but giving out whole file?

> 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.
-1; I don't like this. passwd and shadow files are pretty standard as 
they are and this would only be confusing. And it makes some of the 
passwords readable, which may also be a risk.

More information about the hlfs-dev mailing list