Stay Ahead With Linux Security News

open sourcesecurity toolsauthentication

Insights From Linux Security Experts On Patching And Security Practices

To celebrate the launch of the new LinuxSecurity.com, we hosted a community chat event. It was held yesterday (December 1st 2004) at 4:00pm, and featured several prominent visionaries from the open source community including Jay Beale, Brian Hatch, Paul Vixie, Lance Spitzner, and Dave Wreski. The topics discussed ranged from authentication, patch management, honeypots, virtues of open source, SELinux, as well as others. We are planning another event to held in January; please send us your ideas! . Robin, would you like to begin with the first question? Good Morning/Afternoon/Evening/Night, ladies and boys, gentlemen and girls. .. Welcome to Linux Jeopardy, the game where we *prevent* Linux Jeopardy! Let's launch right in with questions for our esteemed guests... 1st question: For Brian Hatch - You've written several books on hardening L inux. How do you view the current state of Linux Security? For Jay Beale: Jay, do you believe the open source nature of Linux provides a superior vehicale to making security vulnerabilities easier to spot and fix? Linux security, as it shall ever be, is a work in progress. (Are we looking to all take turns, or should we write offline and post when complete?) **I'll let Qs overlap a little to allow typing time but still keep things m oving** yes, Brian's question. Linux security continues to be something we all need to strive for, and will never actually achieve. (So JayBeale - work on your Q while Brian_Hatch replies) Etc. There are many things in the linux kernel that are making great strides forward to enabling better security models for Linux. For example, the number of advanced Linux security patches and models, such as SELinux, grsecurity, are very encouraging. LSM, the common framework (for those authors who wish to support it) ma kes creating a machine that has these handened non-standand unix security setups much easier. IN that respect Linux kernel security has a boatloadof possibilities t hat it didn't a few years ago. Linux *machines*, which is the sum of the kernel and the applications ( mostly open source, certainly from your distribitution of choice) will always be vulnerable to misconfigurations, bugs in your software, and plain human error. You'll never achive a 100% secure linux box. Just like you'll never ha ve a 100% secure windows, mac, etc. But things we didn't have before, such as advanced file ACLs, make it p ossible for us to go further with our security models, to support better tailoring of privilages, fo r example. Linux security just gets better and better. (over.) Thoughts from any others as well? sure. Let's do the person-specific Qs first. Jay? And while Jay types, the next Q = For Paul Vixie: Paul, how important is st rong authentication? What have you done to improve standard Linux authentication mechanisms? ok, my specific. in terms of easier to find, it's clear that open source makes them somewha t easier to find, but black box vulnerability-hunting has become much easier with tools like IDA Pro . There's a lot you can do from the black box perspective. Halvar Flake, for example, reverse engi neers Windows patches to find the vulnerabilities they fix. (them == security vulnerabilities) in terms of easier to fix, open source is very, very powerful that way. Security is all about tradeoffs. As our experiences grow, so do the level of d ifficulty of attacks that have to be prevented. I remember back when the ping-of-death vulnerability was first announced that the Linux people had a fix out in something like 4 or 7 hours. The strength is that anyone can create a patch. They can do it on a weekend, they can do it at night. Shops that have som eone on staff capable of vetting that patch can reduce their window of vulnerability massively. Shops that don't can still get a patch sooner, if they've got someone capa ble of compilingsoftware as that person can get the patch from the code maintainer, which tends to be released before the distros are able to finish packaging and testing. re: strong authentication q. it's important to distinguish between anonymity ( which is a necessary property of some parts of digital society) and non-accountability (which is eit her not important, or important to prevent, depending.) i would like to know that there's "recourse " between myself and an agent (host, service, person, whatever) before i agree to spend any resource s (including my time) communicating with that agent. i don't need to know its ident For Lance Spitzner: Lance, I loved your book on honeypots. Do you know of, or can you tell us about any large corporations who have adopted honeypots as a technique for intrus ion detection? I'd just have to second JayBeale's comment on the power you have in hav ing the source code: when a bug is found, you - the end user - are capable of applying it (perhaps even a single line change is all that's required) and compile the bug-free version. That's somethin g that you can never match if you are not the one who has control of the source code. It also provides you with the ability to make an educated choice about the ris ks involved in using the software, free of spin from a specific vendor lance is up next... meanwhile, can prepare to answer this follow-up... Follow up: Any one can create a patch, lots of people then blindly install them without checking sources, what is the risk of getting a trojan through rouge patch? Have you heard of any examples? I can take that until Lance finishes. Go ahead, JayBeale I was trying to address that. Shops that have a programmer on staff or a sysadmin with the skills can generally vet wrt human involvement in creating and applying/accepting patches... the ping of death vulnerability is still present in a lot of machines that have had no other reason to upgrade. i feel the opensource force strongly. but i also fear that someday linux and bsd will be contrib uting their fair share of drones to the armies who mass and launch ddos attacks. humans are great, but let's make it easier to be patched than not, ok? the patch well enough. vix: they are easy to patch. vix: the vendors all have automated patch tools, vix: most of which will allow you to download-only and then patch, or even patch without any human involvement. vix: My Red Hat system tells me when it's low on patches. My Unix-based Ap ple also checks on its own for missing patches. i dunno. a bunch of redhat clients at my son's middle school were running code old enough to not have a patch mechanism enabled by default at installation time, and the teachers there didn't know what they weren't getting. modern redhat and suse is pretty much better in this r egard but there are a lot of distros making up the rest of the market. who defends those? who will defend us against those? apt-get install cron-apt

Dec 02, 2004 • Brittany Day Organizations/Events