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. +1 > 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. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
