Re: SLFS book

A basic security policy states "All which is not expressly permited is 
prohibited". Enforcing that can be a goal. Beta releases would fullfill parts 
of the agenda. I suggest the following in the guts of the book, and as part 
of the roadmap.

Proccess accounting and profiling of an LFS build. This can be helpfull with 
filesystem access controls, resource limits, enviroment variable 
restrictions, and intrusion detection. Strace, and I don't know what else is 
available.

In the networking branch: Is iptables the best choice? User id filtering can 
be used by default for syslogd, whatever is in chroot, and I think x11 too. 
Default deny the rest, comment examples so the package_user can do ftp, http, 
and cvs fetching.

Does anyone want to write some hints on dropping syslogd root privs?

The package_user, I'm thinking user lfs is a good choice. They can live in a 
live in the /tools chroot. Either have instructions for taring binary 
packages and cleaning after, and/or maybe hardlink (or remount) 
from /usr/local/bin to /tools/usr/local/bin. To use this best the build 
procedure needs to be remapped, some packages would need to be built one 
extra time, and it would be more complicated. But on a finished system /tools 
could be detached (even a network filesystem), and only applications would be 
left. Auditing the system without the compilers is a good place to start for 
the auditors. There must be some security gain from only allowing one user to 
compile anything on one partition. And the rest of the system will remain 
less fragemented.

For legal reasons none of the LFS or BLFS book can be duplicated. The SLFS 
book needs to be original work. Shell commands, like make, cannot be 
copywritted, so they can be reused.



-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page