Interview with Brian Hatch, author of "Hacking Exposed Linux"
by Mirko Zorz - Monday, 30 June 2003.
Bookmark and Share
No "ok" button, just an empty text field. The user has a chance to provide a correct and applicable response, such as "The server's certificate is signed by my company's CA, not a global CA. I have verified the CA's information, including fingerprint, against the signed laminated card provided personally by my company's system administrator and they match, so I am reasonably sure that there is no chance of a man-in-the-middle attack."

Perhaps I should call this 'security through bullying the user into not accepting insecure modes of operation.'

Some believe the best security model is to have highly audited and secure code. Others believe that you should employ kernel modifications that go beyond the standard Unix security model. What are your thoughts?

The bare minimum standard for any secure system would be that the code itself is secure. Code auditing is one of the central tenants of OpenBSD, for example, and they've had bragging rights for many years by being able to point to internal code audits that fixed bugs before they were found to be exploitable, often years before. Unfortunately, in the Linux community there are less folks taking on this task of proactive code auditing. The Linux distro with the greatest emphasis on code audits is Openwall GNU/*/Linux, aka Owl. The OpenWall folks, which include such experts as Solar Designer, have stressed code audits, to the point that their code produces no warnings, even trivial ones, when compiled with 'gcc -Wall'.


Having secure, audited code, is a must. However I still prefer to use kernel security patches when possible. Audited code helps keep the bad guys off of the machine. However advanced kernel patches can both prevent them from getting in, and prevent them from doing damage if they do find a way in. Even if the software on your machine is completely locked down, a malicious cracker can find some avenue to get onto your system. For example if one of the administrator's desktop machines is broken into, and they access the secured server, the cracker can get in.

An advanced security kernel patch can protect your machines more than the traditional Unix model. If the cracker, even if they can get in as root, can not remount the partitions in read-write mode, cannot stop or start your daemons, cannot bind any network sockets or make outbound connections, cannot read protected files even as root, they'll probably move onto easier pickings.

How long did it take you to write "Hacking Exposed Linux" and what was it like? Any major difficulties?

Well, first of all, I still call it "Hacking Linux Exposed", and you can read my rant on the topic if you want...

Spotlight

Is it time to professionalize information security?

Posted on 23 May 2013.  |  The issue of whether or not information security professionals should be licensed to practice has already been the topic of many a passionate debate.


Daily digest

By subscribing to our early morning news update, you will receive a daily digest of the latest security news published on Help Net Security.
  

Weekly newsletter

With over 500 issues so far, reading our newsletter every Monday morning will keep you up-to-date with security risks out there.
  

 
DON'T
MISS

Fri, May 24th
    COPYRIGHT 1998-2013 BY HELP NET SECURITY.   // READ OUR PRIVACY POLICY // ABOUT US // ADVERTISE //