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
+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