hlfs team

Miguel Bazdresch lfs-01 at thewizardstower.org
Sun Jan 11 04:41:36 PST 2004


* Robert Connolly <cendres at videotron.ca> [04-0109 12:55]:
> Achievable short term goals would be:
> 
> An introduction.
> Getting the propolice bugs worked out and an hgcc script made.
> Read only root filesystem on first boot.
> If I remember right glibc or gcc make install attempts to send mail to gnu 
> after a successfull build. This is a privacy problem and should be broken, if 
> it actualy works.

I don't think that's the case. I spent some time looking at the gcc
docs and makefiles and I don't see any evidence of it. I've installed
it many times and it's never tried to send anything by email.

> Coreutils
> -Replace /bin/false and /bin/true.

Why? I know you think those two programs are dangerous because they
accept --version and --help. IMHO it's a waste of time to replace
those, unless we can identify why they're dangerous.

If we start by replacing the most trivial of programs, where are we going
to stop?

> -Disable some suid stuff. mount and umount for sure.

Again, why? I'm not saying we shouldn't do it, but I think we'd be
better off by starting from the top and going down, and not from the
bottom up.

I'll explain. The decision to remove or not remove suid from mount
should come as a natural consequence of a security policy that each
user will create for himself and his circumstances. If we start by
removing suids, we're creating a default policy without thinking first
what it is we want.

> -If su is going to be used, sgid might be better.
> Findutils
> -Move /usr/var/locatedb to /var so /usr could posibly be read only. Also if 
> this database is owned by another user (bin) updatedb doesn't need to run as 
> root.
> 
> Sound like enough for a v0.1? hlfs could realy use an editor if someone could 
> volunteer their time.
> 
> Comments..?

I think we should start with the big picture and everything will
trickle down from that.

-- 
Miguel Bazdresch
http://thewizardstower.org/



More information about the hlfs-dev mailing list