>> > 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: Apache2,PHP5,MySQL5,libpcap,libnet,libdnet,pcre,libxml2,modsecurity2, mod_proxy_html,snort,mydns,tripwire,bridge-utils,clamav,curl,ebtables,fcron, gradm2,iptables,labrea,logrotate,ntp,ossec-hids,popt,shorewall,wget, 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 things > 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 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. > 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
smime.p7s
Description: S/MIME Cryptographic Signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
