Re: SLFS book

On Wed, Dec 24, 2003 at 05:19:34PM -0500, ashes wrote:
> 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.

Absolutely.

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

This will take awhile, but definately needs to be a long term goal.

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

I have sent an email with the patch. The patch also patches the manpage
where the extra switches are explained. Very self-explanatory.

> The package_user, I'm thinking user lfs is a good choice. They can live in a 
> live in the /tools chroot.

I don't know if package users is a good idea for the book, though I
personally use them. It is quite a deviation from standard practices and
could cause some things to break. In the course of testing other
security modifications, what exactly is borked may become rather
difficult to tell. I assume that most people who have or do use the hint
would advocate it, so I ask that people who are unfamiliar with it read
it. Don't worry about building it (unless you want to), just read it,
get the gist and some idea of the requirements neccessary to implement
and provide feedback if you would, please. Tushar has modified his build
scripts and when he gets back he's going to audit his methods again, so
he will be well prepared to drop the instructions in if it's agreed that
we go with it.

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

I adamantly agree that there should be no compilers or any development
tools left on finished system. However, I think there are easier ways to
overcome this. My preferred method was to burn a CD with an e2fs
filesystem on it. I then just mounted that CD whenever something needed
compiled. Worked quite well, but adds the requirement of a CD-ROM, and
that's something a production server may very well not have.

-- 
Archaic

"The power to tax involves the power to destroy;...the power to destroy
may defeat and render useless the power to create...."

- Chief Justice John Marshall, 1819.

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