hlfs test suite & gradm2, logging

goodoldmarty at gmail.com goodoldmarty at gmail.com
Sat Sep 1 02:49:53 PDT 2007

>> > RE: HLFS test suite; During the build, tests are very important. After a
>> > build is finished and booting, testing is even more important. A
>> > comprehensive test suite is needed to validate the final product.
> The paxtest tests in the paxctl package has many tests, but some of them 
> depend on you running a grsecurity kernel.
I built mine by the book, skipping nothing and adding my own hacks along
the way, of course.  But I wonder if my applications are really being
compiled with all those great features.  I built, installed, configured,
and currently run the following applications on my SVN-20070820 2.6
glibc x86 build:
and the grsec patched kernel with all netfilter modules, bridging and
bonding in use.
(I had to rebuild zlib and manually install a copy of libz.a for mydns)
Other than that had absolutely no problems. 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
> like tripwire.

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

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


|\  /|  Visit http://www.goodoldmarty.com today!
| \/ |  ==============================================
|    |  "Opportunity often comes dressed in overalls
******   and disguised as work." Thomas Edison

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3651 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20070901/29ef0c79/attachment.bin>

More information about the hlfs-dev mailing list