coreutils su

Robert Connolly 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 
patches.

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 mailing list