hlfs test suite & gradm2, logging

Robert Connolly robert at linuxfromscratch.org
Sat Sep 1 03:09:13 PDT 2007


When something explicitly links to libz.a, find the Makefile and exchange it 
with '-lz'. This should also work:

find . -type f -exec sed -e 's/libz.a/libz.so/g' -i {} \;

The only exception is when a program is statically linked.

On Saturday September 1 2007 05:49:53 am goodoldmarty at gmail.com wrote:
> (I had to rebuild zlib and manually install a copy of libz.a for mydns)
> Other than that had absolutely no problems. 

I think I know what you're asking, but unless a package has a bug there isn't 
really a way to verify it's protected.. other than very finely debugging, or 
decompiling, each program. The tests in the chapter 6 toolchain page verify 
that gcc is hardening packages by default.

> I expected compile problems 
> but got none with anything; funny reason for concern, but it all seemed
> too darn easy to me... I got worried. Now how do I know my applications
> and their libraries inherited the intended hardening features? Is there
> some generic way we can validate all the system executables in one
> session( AKA certified HLFS )?
>
> By the way, I can break an anvil...this build is stable like a rock!
>
> > There was a bit of discussion a long time ago about adding a cron daemon.
> > We could use it right away for rotating logs, and maybe a couple other
>
> things
>
> > like tripwire.

I've been wanting to add a very simple way to track which files belong to 
which package, and have a checksum for the file, so everything is accounted 
for and can be verified. But it hasn't been done yet.

> hlfs definately needs to look into this matter. The hints have a blurb
> on fcron and logwatch but the configuration still needs tweaking to
> accommodate things like apache restarts, etc. I made it all work right.
> I maintain my tripwire database off the machine on CD where it cannot
> possibly be altered and I only run that program manually/monthly. I use
> OSSEC-hids for the day to day checks. It is way easier to use and works
> fine.
>
> >> > RE: grsec; I am curious as to why the void regarding gradm2?
> >> > This seems like an important component for security configuration.
> >> > Is there a problem I have not yet discovered?
> >
> > It's not added yet because nothing depends on it. I would like to add
> > gradm rules for each package, so there are a lot of examples.

I've tried the learning mode, and it's not optimized. You can end up with a 
100MB rules file after a few days. The learning mode works best for a small 
number of programs, not the whole system.

> gradm2 should be made known and available in chapter 7, but (IMHO) a
> default role based config is a liability way outside the philosophy of
> hlfs. If anything, a simple how-to would be more appropriate.
> As I understand, the gradm utility has some intelligence for learning...
> Running this on a system will automatically create templates for
> everything accessed leaving you to set the access rights as you choose
> after a learning session is done. This should be fine for HLFS users.
>
> Skunks are affectionate and playfull. I have had wild ones for pets...
>
> Marty B


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20070901/ee2d0652/attachment.sig>


More information about the hlfs-dev mailing list