cendres at videotron.ca
Wed Jan 21 05:37:59 PST 2004
On January 20, 2004 07:19 pm, Archaic wrote:
> On Tue, Jan 20, 2004 at 07:06:20PM -0500, Robert Connolly wrote:
> > The selinux stuff doesn't belong in chapter 5 unless its being built from
> > an selinux system. Adding m4, bison and flex shouldn't destabilize
> > /tools. But et_dyn is going to touch chap5, aswell as stuff we haven't
> > found yet (point guard). I don't think there is a way to avoid adding to
> > chap5.
> Do you mean adding as tacking packages on to chap5 or as modifying
> chap5? Will it really matter if we double build glibc in chap5 or chap6?
> If not, I say leave it for the sake of keeping the LFS chap5 intact
> (though likely to be adding packages to it later).
> Perhaps I need a tentative rundown on what must happen to the toolchain
> to add et_dyn, including any double building, if necessary. I hate to
> see us having to start all over from scratch, but if that's the only
> logical way, we can still insist that the build is only tested on
> vanilla LFS-<whatever version>. Though if we can just modify, that would
> IMO be rather useful.
et_dyn is almost the same problem as with propolice (until glibc 2.3.3
releases). To build glibc with et_dyn, you'll need crt1S.o either on the host
(from glibc-2.3.3) or in chap5. And crt1S.o can only be used by a binutils
that understands -pie. The rest affects hgcc.sh. et_dyn isn't stabilized yet.
chpax is needed on a real system to disable et_dyn on some binaries. At least
one of the glibc programs uses an executable stack, so glibc needs a patch,
xfree86 is also affected. Since there are enough other things to do, I would
prefer to develop the stable technologies first, and leave et_dyn for later.
gcc-3.4's -pie will be superior to what they have now, and FSF binutils
should release with -pie by the time gcc-3.4 releases. However much of the
work for et_dyn has already been done by gentoo, and it would be very easy to
add it to hlfs. Enforcing non-executable stack would be a bit extra work and
Today I'm looking at installing su in /tools so root can su down to uid1. I
think it would be safe to allow uid1 to own everything except /boot and /etc.
Sudo is a vulnerability in itself. Any school of thought in unix says we
should not be using root to do everything, like we do in chap6. This will
prevent coreutils su from installing in chap6, it will keep anything from
becoming suid root automaticly on install, and will keep packages from
unpacking to /, or installing to /etc automaticly. Unlike microsoft and
redhat, I do not think packages should autoconfigure themselves on install. I
realize its safer to have root own system binaries. This is an experiment to
see if some of root's trust can come off on uid1. I can't think of any
serious disadvantage to this, but I am curious as why no distros do it. This
is more secure because it uses the least possible privileges to complete a
task. User daemon(uid6) could be a sister to bin(uid1), running maintence
tasks that don't need root, or a special user.
More information about the hlfs-dev