Transcript of Launch Chat

<nicole> Robin, would you like to begin with the first question?

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

<roblimo> 1st question: For Brian Hatch - You've written several books on hardening L inux. How do you view the current state of Linux Security?

<roblimo> 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?

<Brian_Hatch> Linux security, as it shall ever be, is a work in progress.

<Brian_Hatch> (Are we looking to all take turns, or should we write offline and post when complete?)

<roblimo> **I'll let Qs overlap a little to allow typing time but still keep things m oving**

<JayBeale> yes, Brian's question.

<Brian_Hatch> Linux security continues to be something we all need to strive for, and will never actually achieve.

<roblimo> (So JayBeale - work on your Q while Brian_Hatch replies)

<roblimo> Etc.

<Brian_Hatch> There are many things in the linux kernel that are making great strides forward to enabling better security models for Linux.

<Brian_Hatch> For example, the number of advanced Linux security patches and models, such as SELinux, grsecurity, are very encouraging.

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

<Brian_Hatch> IN that respect Linux kernel security has a boatload of possibilities t hat it didn't a few years ago.

<Brian_Hatch> Linux *machines*, which is the sum of the kernel and the applications ( mostly open source, certainly from your distribitution of choice)

<Brian_Hatch> will always be vulnerable to misconfigurations, bugs in your software, and plain human error.

<Brian_Hatch> You'll never achive a 100% secure linux box. Just like you'll never ha ve a 100% secure windows, mac, etc.

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

<Brian_Hatch> Linux security just gets better and better.

<Brian_Hatch> (over.)

<nicole> Thoughts from any others as well?

<JayBeale> sure.

<roblimo> Let's do the person-specific Qs first.

<roblimo> Jay?

<roblimo> 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?

<JayBeale> ok, my specific.

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

<JayBeale> (them == security vulnerabilities)

<JayBeale> in terms of easier to fix, open source is very, very powerful that way.

<dave> Security is all about tradeoffs. As our experiences grow, so do the level of d ifficulty of attacks that have to be prevented.

<JayBeale> I remember back when the ping-of-death vulnerability was first announced

<JayBeale> that the Linux people had a fix out in something like 4 or 7 hours.

<JayBeale> The strength is that anyone can create a patch.

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

<JayBeale> reduce their window of vulnerability massively.

<JayBeale> Shops that don't can still get a patch sooner, if they've got someone capa ble of compiling software

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

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

<roblimo> 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?

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

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

<roblimo> lance is up next...

<roblimo> 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?

<JayBeale> I can take that until Lance finishes.

<roblimo> Go ahead, JayBeale

<JayBeale> I was trying to address that. Shops that have a programmer on staff or a sysadmin with the skills can generally vet

<vix> 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 open source 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?

<JayBeale> the patch well enough.

<JayBeale> vix: they are easy to patch.

<JayBeale> vix: the vendors all have automated patch tools,

<JayBeale> vix: most of which will allow you to download-only and then patch, or even patch without any human involvement.

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

<vix> 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?

<Brian_Hatch> apt-get install cron-apt <-- installs a cron job that downloads and em ails you the updated versions of your software, ready for you to apply as you believe is appropriate .

<Brian_Hatch> Damned near every Linux distro has this functionality nowadays, and it' s really effective.

<roblimo> Let's move on. For the whole panel... Is intrusion detection just a fad, or is it here to stay and provide real value?

<JayBeale> wrt rogue patches -- the safest thoing is always to wait for your vendor. But if you've got someone on staff with the necessary skills, you can either vett the community-sup plied one. If your shop is at least capable of compiling code, your people might even beat your ven dor to compiling in the program maintainer/author's patch.

<dave> There also exists a great deal of flexibility in older versions of Linux that can extend the life expectancy of the server, or keep it secure until such time to replace it with m ore modern versions of the software.

<dave> ie, packet filtering, auditing/logging, service management...

<Brian_Hatch> Rogue patches require a bit of social engineering, often which should p rovide some warning bells. For example, a fifty line patch to fix a buffer overflow that you get on an unmoderated mailing list is probably something malicious instead.

<roblimo> 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? The challenge you run into with honeypots is that most organizations consider them a dark technology, few publicly discuss if/how they are using them

<dave> Brian, yes, but there have also been incidents where the source itself has bee n modified, and that is certainly going to continue.

<JayBeale> well, that's a tough one

<JayBeale> that we all have to deal with (the original source repository or download site being compromised)

<JayBeale> Bad guys will continue to compromise Microsoft, as well as

<dave> Yes, and rely on the fact that the checksum information itself hasn't been com promised.

<vix> that happened to vms once. dec's central engineering had to go back six months in backup tapes and audit every change. ick. it also nearly happened to netbsd once, when somebod y guessed my password. cvs is a good friend in times like those.

<JayBeale> every other software vendor large and small, hoping to get rogue code into our machines. And I don't think

<JayBeale> that there's much chance of being 100% sure that it doesn't happen. Sourc e availability helps, but this stuff can be

<JayBeale> very subtle. At one point, someone tried to put a backdoor into the Linux kernel and nearly

<roblimo> My question is how do you think Mono (an open source implementat ion of .Net) will affect security in linux? (.Net not having a sandbox-like enviornment like Java d oes for example) (To my knowledge) (And the existence of thousands of viruses written in VisualBasic .

<JayBeale> got away with it. The backdoor involved a 1-character change. One cha racter!

<Brian_Hatch> Absolutely. Sadly. THese things happen. But they also do tend to get noticed quickly. If you download something today, and don't get around to installing it until frid ay, you'll probably read about the compromise on slashdot and know that you shouldn't install that c opy. For a real-time package download you don't have that luxury, at least not as easily.

<dave> Yeah, and you might even hear about that from linuxsecurity.com, too :-)

<Brian_Hatch> Ahh, but I have linuxsecurity.com go straight to my email, so I don't n eed to *go* anywhere for that. ;-)

<Brian_Hatch> (WWW::Mechanize is a wonderful thing.)

<roblimo> Repeat... My question is how do you think Mono (an open source implementation of .Net) will affect security in linux? (.Net not having a sandbox-like enviornment like Java does for example) (To my knowledge) (And the existence of thousands of viruses written in VisualBasic.

<Brian_Hatch> Mono: was that directed to anyone in particular?

<roblimo> To all...

<roblimo> (To all unless specified)

<dave> I believe that its exposure will be limited to that which the application has privileges. IOW, like any other application, it won't be able to access or compromise something othe r than which it has permission.

<roblimo> - Have any of you had any experience using biometric devices on a

<roblimo> Linux platform?

<lance> On the honeypot question, most organizations consider honeypots a 'dark' tech nology, so few publicly discuss them

<vix> dave, the problem is the lack of a sandbox. a java applet can't send network t raffic to anywhere but the server it was downloaded from -- a .net "applet" can do anything it wants . i predict an even vaster drone army as .net becomes better understood by the script-kiddie commun ity. and maybe some linux boxes will be along for the ride. especially if microsoft releases MSIE for linux :-)..

<Brian_Hatch> What I worry about, and this is not limited to Mono, is that security i s best achieved when you follow the Unix model: lots of little things that do one thing and do it w ell, all communicating through simple interfaces. WHen you start building huge interconnected creat ions, you can't think of all the ways a system could be attacked.

<roblimo> FOR LANCE: (Followup) Last year on the Honeypot list ther was a lot of disc ussion about "HoneyTokens" ... has any work been done in this realm? Has it been put to practice?"

<dave> Ah, that's bad news. However, unless it has the Unix ability to bind to privil eged ports, for example, then it should conceivably be limited in scope, no?

<Brian_Hatch> Biometrics: I haven't had any *good* experiences with it. I've seen a few products that were rather abysmal eitherbecause they were easily fooled, or because they had lo usy linux support. This was about a year ago, so hopefully there are better products on the market now.

<dave> We have worked with biometrics insofar as USB key devices that can be used to provide the "something you have" component of security, and it's worked quite well.

<lance> rob: Once again, the organizations that are using them aren't very public ab out it, I know of several .gov and financial organizations using them

<vix> ah, no. a ddos victim is just as congested-right-off-the-net whether the conne ctions it's not answering come from priv ports or unpriv ports. the .net people failed to understan d the java security model when they did their basic design.

<Brian_Hatch> Biometrics: was the USB device the 'thing you have' or was it a real b iometric, ie the USB device scanned your fingerprint for example?

<dave> vix: yes, too true

<roblimo> ALL: Do you think linux desktop users will need antivirus softw are in the near future, or a strict security policy would be enough?

<dave> brian: no, it really fell more into the general token-based security, but stor ed on it could be any piece of information, including unique signatures.

<roblimo> and... I'd like to build on that question () and ask (d irected to all), "What do you should be put in place for newbie desktop users (who are becoming more prevalent), and what are distros doing to make it easier for these users to be secure?"

<JayBeale> antivirus: yes, I think we might need it in the future.

<lance> For newbies? Less choices :)

<JayBeale> Linux has been a less attractive target, both in that it's slightly harder and

<Brian_Hatch> Newbies: less choices - may have been said in jest, but really less ch oice does make security easier.

<dave> I don't doubt there will be a day when AV will be necessary for Linux desktops , but it would only be to protect against applications that abuse the standard Unix model. At least any damage done would specifically be restricted to the level of permissions granted to the individu al user, and not compromise the whole server.

<JayBeale> that it won't get you on CNN yet,

<JayBeale> but it'll find its share. We've had 2 worms on Linux already -- they just don't make as big a splash yet.

<Brian_Hatch> AV: I think that eventually Linux will be a big enough target that ther e will be a market for virus/worm prevention products.

<Brian_Hatch> AV: While the effect is my account (not the machine as a whole) is affe cted, you still don't want your account to turn into a Spam 'bot, for example.

<JayBeale> I did a column on this topic in Information Security Magazine, btw. Avail able at: https://www.techtarget.com/searchsecurity/

<dave> newbies: I think it's important to have at least a moderate understand of secu rity, including what you have to risk. IOW, if your PC is directly connected to your cable modem, it 's worthwhile to read the Security HOWTO and other docs to get a glimpse of the types of risks to yo ur information.

<Brian_Hatch> AV: But compared to Windows, where a compromise of your local account u sually means system-wide compromise, Linux machines are not suseptible to the same level of damage.

<vix> i don't need any privileges at all to turn your box into a spambot. any unpriv buffer overflow is enough.

<roblimo> dave, and how many newbies will read those HOWTOs, regardless of OS choice?

<Brian_Hatch> AV: Your account shouldn't be able to modify the system software, re-wr ite the /etc/inittab, etc. IT'd be limited to things you can do.

<Brian_Hatch> AV: (and hopefully you don't have passwordless sudo access from your ac count, or then it could cause system-wide mahem.)

<bdthomas> Linux Security HowTos/FAQ --> n,com_weblinks/catid,155/Itemid,134/

<JayBeale> vix is right. we don't need root anymore. A box is plenty useful to atta ckers without root.

<vix> AV: the bad thing about privilege separation, from a script kiddie's point of v iew, is that they'll lack the power to prevent others from also infecting the machine, and thus they will have to share it. there's no other effect i've seen, wrt spambots.

<dave> roblimo: Often times it's only read after they've been attacked, but increasin gly we're seeing a greater understanding that security is a necessary component to being online. The vendors are doing a better job, but the security protection is also the first thing to go (be turne d off) when there's a problem.

<lance> dave: I disagree, just getting people to realize they are a target is half th e battle

<roblimo> SO -- and this was an emailed Q -- What will it take to make vendors and us ers more security conscience?

<dave> lance: are you saying that you're not seeing an increase in the amount of peop le that believe security is important?

<JayBeale> Vendors are getting more security-conscious, if slowly.

<JayBeale> The number of default listening network ports on systems is going way down .

<dave> Vendors need to stop developing software that tries to be all things to all pe ople.

<roblimo> I have nevere met anyone who bought a burglar alarm system before they or a neighbor had a break-in...

<JayBeale> We've got firewalls by default, configured at install time.

<Brian_Hatch> Security Concious: Never have an 'OK' box. Instead pop up a page that really details the problem in question, and ask them to summarize it before they can choose to allow the bad action.

<vix> security consciousness follows personal experience. if someone gets attacked o r they know someone who got attacked, they will worry about it. until then it's all very abstract a nd no time or money will be spent on it, by users or by vendors. human nature's a real pain in the a** sometimes.

<JayBeale> Vendors are even incorporating hardening tools. Debian and HP-UX use Bast ille Linux. Solaris uses JASS.

<lance> Alot of your homeusers think its the organizations that are targeted and that they should consider security is important

<JayBeale> Mandrakesoft incorporates their own tool.

<roblimo> New Q: My question is: In regards to kernel-level security, which is the better system to use, SELinux or RSBAC?

<dave> Debian, at least, should be hardening the software by default. Again, I believ e the difficulty is in that the vendors are trying to appeal to the largest audience, and in doing s o have to make tradeoffs with security.

<Brian_Hatch> A default firewall should be both ingress *and* egress filtering, in my opinion. A way to trigger "your machine is trying to connect out to port 25 on some.random.box.exa mple.com" and let you choose if this is OK would be wonderful. Ingress filtering prevents your netw ork ports from being touched directly, but if you do get compromised (say a client vulnerability) th en it may want to talk to the outside world, and having that blocked is very importa

<roblimo> Related to new Q:

<roblimo> - What is Mandatory Access Control, should a normal system admin be

<roblimo> interested in it?

<JayBeale> Brian_Hatch: you're right.

<JayBeale> Brian_Hatch: but egress filtering is very hard.

<lance> keep in mind, alot of the attacks now are not technology based (i.e. exploits ) but social engineering (i.e. click on our link)

<Brian_Hatch> egress filtering: damned hard. I can dream, can't I?

<dave> To an extent, yes, everyone should be interested in it, but implementing it at the desktop level is difficult, and subject to misconfiguration.

<JayBeale> Brian_Hatch: you can dream. but the thing we've learned with automation ( hardening and firewalling)

<JayBeale> Brian_Hatch: is that if you go too far with security measures and leave th e user with the idea that something is "broken," they won't hunt down the one thing that broke thing s. They'll remove the entire security solution.

<Brian_Hatch> SELinux vs RSBAC: the better tool is the one you're better able to supp ort, and offers you the features you require.

<dave> There's a great interview with the creator of RSBAC from some time ago on linu xsecurity.com.

<JayBeale> Brian_Hatch: That's how many users and even organizations threw out their firewall when they first tried it. One tiny thing broke and they ripped the entire thing out.

<Brian_Hatch> SELinux/RSBAC: Since SELinux is shipping with some distributions, it's going to be a lot more accessible than RSBAC for someone who doesn't feel comfortable with compiling a kernel, but just wants to start locking down a machine.

<dave> Jay: Yes, and all too often the "business case" wins out over common-sense-sec urity

<vix> ALL: i've got to make an exit, to prep for my next meeting. any last requests?

<roblimo> Thx, vix

<dave> vix, nice to chat with you again.

<roblimo> I'd say $1 million for each participant is the last request -- that you'll let us make. :)

<Brian_Hatch> vix: good chatting.

<JayBeale> dave: yes. but an organization that proceeds more carefully doens't often have the same problem, at least if they've got competent staff. A well-configured firewall that's been implemented very carefully doesn't "break" things.

<vix> groovy. this was fun, folks. hope to do it again sometimg. OO

<JayBeale> vix: thank you!

<roblimo> Take care, vix

<Brian_Hatch> good chatting, everyone.

<roblimo> follow up for Brian_Hatch: you say "some distributions", but I'm o nly aware of Red Hat/Fedora, whereas RSBAC comes with Adamantix... for a distro looking to incorpora te one or the other, which of the two is better? Ie. I hear that there are some concerns with LSM, y et SELinux takes advantage of it and RSBAC (according to the devs), never will..

<Brian_Hatch> I separated Fedora and Red Hat as distributions, which is somewhat of a cheat, I'll admit. There may be others that support it, but certainly it's going to be available i n more places since it's better integrated with the mainline kernel sources.

<Brian_Hatch> If you were a distro, then you need to have the kernel-foo to be able t o support whichever you like best.

<roblimo> Brian_Hatch Do you have any examples of good programs for egress se curity on LINUX? OSX has little snitch, Windows has Zonealarm.

<Brian_Hatch> Personally, I've use RSBAC more than SELinux,

<Brian_Hatch> and because I used RSBAC earlier, I'm more familiar with it. That said , I use LIDS too because it was the first I used to great extend. My lids.sh is rather huge and ver y very tailored to achive features similar to the other kernel patches you can use.

<Brian_Hatch> Good egress programs: I have been using Linux long enough that I'm comf ortable doing the kernel ACLs myself (iptables/etc) and don't keep up on tools enough. This is a sh ame, really.

<JayBeale> I think that Immunix is pretty cool, though commercial.

<roblimo> anyone else?

<Brian_Hatch> Anyone know of good egress filtering tools? Locking it down 100% is wh at I generally start with, then enable outbound packets that are RELATED to existing connections, et c.

<JayBeale> But the other one that doesn't get as much press is grsecurity, which look s pretty nice.

<JayBeale> egress filtering -- Mason!

<lance> jay: and simple

<bewmIES> (I'm not supposed to be talking, but Shorewall ;))

<JayBeale> Mason is Bill Stearn's firewall builder that literally builds a firewall b y watching how you use the system during a learning period and then building rules based on that.

<roblimo> Essentially a Bayesian firewall?

<JayBeale> segwaying, that same learning process is undertaken by grsecurity and Immu nix's subdomain.

<JayBeale> roblimo: not bayesian, not that complicated. but, yes, the same spirit.

<Brian_Hatch> But there's no tool that does egress filtering the way I have in my dre ams - warning you that something's trying to get out, and asking you if it's OK. I can't even think of how the notification mechanism would work - after all, how do I know which user/tty/etc to ask?

<JayBeale> Brian_Hatch: zone alarm style?

<JayBeale> Brian_Hatch: you could make it an X-windows tool.

<Brian_Hatch> One thing favouring SELinux over other alternatives is that it has a wi der developer base, and is thus more likely to be maintained longer.

<JayBeale> Brian_Hatch: I was thinking about this back in 2000 -- it's surprised me t hat no one has made it yet.

<JayBeale> this --> zone alarm-style firewall for linux.

<Brian_Hatch> Zone alarm style: yes, would be great for new users.

<JayBeale> Brian_Hatch: it can be done and it's not too hard.

<roblimo> dave, perhaps you could get Guardian Digital interested in this project? :)

<dave> Yes, we'd be more than interested in receiving input and pursuing the options. ..

<roblimo> Anyone else on the panel have something to say? running out of time...

<Brian_Hatch> JayBeale: Ok, put your code where your mouth is. ;-)

<JayBeale> Brian_Hatch: Maybe I will!!!

<Brian_Hatch> I'd be up for it, in my limited spare time. Maybe I can get the twins to test it out.

<JayBeale> Brian_Hatch: if I build it, we'll put it on Bastille.

<dave> Jay, yes, that would be interesting. I'd like to listen to your thoughts.

<Brian_Hatch> I'm going to need to sign off as well.

<roblimo> Okay... I think it's time to cut off the "formal" chat, open the channel ba ck up. Please feel free to stick around if you can. Otherwise, Brian_Hatch and others, thanks so muc h for joining us.