Slashdot Mirror

Ian Lamont writes "Google has begun to scan the streets of Paris as part of its Street View service, but the company may be hindered from publishing them unedited. The reason? French privacy laws. Google may be forced to blur faces or use low-resolution versions of the photographs. The Embassy of France in the US has a page devoted to French privacy laws, that says the laws are needed to 'avoid infringing the individual's right to privacy and right to his or her picture (photograph or drawing), both of them rights of personality.'"

You asked, they answer. Jon Lasser and Jay Beale decided to kick their answers back and forth a few times in the style of Crossfire -- at least if Crossfire guests were security-obsessed, literate hackers with a knack for finding gaps in Linux and Unix security. And don't forget the book creds: Jon wrote the excellent Think Unix (want to buy it, huh?), and Jay is plugging away at (and just plain plugging) his upcoming tome from Addison-Wesley,Securing Linux the Bastille Way.

Jay Beale: Before we get to the questions, let me make an announcement. I've just recently been hired by MandrakeSoft (makers of Linux Mandrake) as their Security Team Director. They're sponsoring my work on Bastille and I'm working to better their distribution's general security. SecurityPortal.com interviewed me about this specifically.

Now, the questions:

1) Target audience
by DreamerFi

Bastille is a great project, but ultimately it targets people who sort-of know what they are doing. How do you feel about projects like the NetBSD/i386 Firewall Project who (whilst having all sources available) targets people who have no clue other than "I need security" by giving them a firewall that has an install that's about as simple as one can make it? Is this just a matter of defining the target audience different?

Jay: Really, it's not entirely targetted away from newbies. In fact, I sorta thought it was newbie-friendly. In designing the Bastille Linux hardening script, we originally sought to make a basic script, that would simply go through the sytem making changes. It could shut down unneeded programs/daemons, tighten up permissions and deactive bad protocols like telnet. At some point, we realized that this would leave many people believing we'd broken something... So, we decided we'd make the script interactive, asking the user before turning off telnet. Unfortunately, this meant that many of the target boxes never got hardened much. Since people didn't know why telnet was bad, they'd leave it on. So, I became a writer! Bastille carries a large number of explanations, targeted to the new user/sysadmin. By the way, the reasoning on deactivating telnet goes like this:

• Telnet is cleartext, allowing third parties to sniff passwords
• Telnet sessions can be intercepted and taken over by a man in the middle, using a simple tool like hunt.
• Finally, telnet can be replaced easily by the much safer Secure SHell, ssh.

Jon: Setting up a firewall for people with no clue is an interesting problem. It requires that the person do pretty much nothing nonstandard: once you need to punch a hole in the firewall, all of a sudden you need to know a lot of stuff again. Alternatively, you could leave the firewall pretty much wide-open and just block a couple of things, which is much easier to do but doesn't add all that much security. Setting up a firewall properly is hard work, and requires specialized skills to do it right: I'm not comfortable setting up a firewall for a company to protect secret stuff, and I tend to recommend hiring a (qualified, competent, specialized) consultant for the job.

For Bastille, we try to fulfill both of those possibilities with a single piece of software. We try to both make it simple to use (lots of defaults that won't break stuff) but make it possible to lock the system down tightly. In either case, user education is key.

Of course, most people don't read documentation, so it's all in the script. You can lead a horse to water, etc., so we try to do that. Bastille seems (to me, anyway) friendly to newbies who read carefully and take the time to understand. I'm not sure how to really help the others anyway.

2) Breaking out the cluestick ...
by mosch

Given the world's largest cluestick with which you could assault every single SysAd on the planet, what clues would you distribute, other than the use of bastille, and the knowledge that there's life outside computers?

Jay: I'd have one major clue that I think supersedes most: Educate yourself! In terms of security, there's few solutions that can beat a clueful sysadmin. On the other hand, any solution you choose for security usually turns to mush when a clueless admin makes the wrong mistake with it. For instance, you might have incredible encryption on your passwords and such, but if you choose "bob" for a password, your system can usually be brute forced!

Jon: Yeah, that's pretty much it. The only clue worth having is the one that allows you to find the other ones on your own.

3) Security is a process, not a thing.
by Skapare

How will Bastille allow users to treat their computer and network security as a "process" (as Bruce Schneier is quoted to say). Are there tools to help users deal with security "events"?

Jay: We're working on integrating this. Right now, we've got something very rudimentary that checks to see if a cracker's sniffer has been installed on your system. We're working on more. I'm currently hacking up a series of scripts, like Tiger, that will examine the current state of the system for anomalies.

Jon: Security is a process, there's no question about it. When I've got a process that works pretty much the same every time, I turn it into a checklist. Bastille, when it comes down to it, is essentially a checklist that performs the tasks listed on it. So Bastille lets you automate your existing process.

Jay: Yes. A checklist. Actually, in these days of rapidly upgrading (read replacing) your distribution every three-six months, the only way to use a checklist as long as Bastille's is to automate it!

Jon: Software development is also a process; Bastille is in a constant state of development. As we find new things that need fixing, we go to the software development part of the process, then the release part of the process, and then the users hopefully take it to the upgrading process. :-)

(Hint: for this process to work, you need to participate.)

4) "Missing" features?
by Coz

A two-part question:

What features do you feel are missing from Bastille as it stands today, and aren't in the roadmap you have for the immediate future?

What elements of system security do you feel should be part of the "core" (if not the kernel) of the operating system, and why (in your opinions) aren't they there already?

Jay: Part I is a tough one. I think I'd like to see an amazing intrusion detection system integrated in. I've also got some ideas for new offshoots of Bastille that I'll need some time to develop before I bring them up. Part II is somewhat easier. I think an operating system should implement seperated "compartments" so that one root-level program can't tromp all over another.

Further, we really should move away from this simple Unix distinction of "root" and "non-root." We can get a lot more granular than that. We're already seeing this latter bit, such that my web server runs as user www, my name server runs as user named, and so on... I wish we could take this farther, as it would really curb the potential for remote root compromise. As for why we don't have it all yet, consider the huge effort to move to these models... Now, we're getting this, through add-ons. Medusa DS9 is bringing us compartments and system call ACL's that apply even to root. The Linux capabilities work is getting us further to a point where we can confine root's actions.

5) Question
by JCCyC

What were the top 3 most asinine security holes you ever encountered on a GNU/Linux distro?

Jay: There have been a number of security holes that looked dumb in hindsight! I think the more interesting question is this, "what security holes right now are going to be seen as stupid later?" We're going to think that there shouldn't have been nearly so many world-executable setuid-root programs. We're going to seriously question having network-accessible system daemons (ftp, dns, web...) running with root authority. Luckily, we're just starting to question this now. Let's see where it goes...

Jon: I'm with Jay on this one. I don't think that any of the decisions that distributions make are particularly stupid, they're just aimed at different markets.

For example, I don't really think it's possible to completely secure either SuSE or Debian, due to the sheer number of packages included. That doesn't mean that this is the wrong decision to make, it's just aimed at a different population with different needs. (Of course, you can install either of those distributions perfectly well -- but you can't install everything, and you need some more knowledge to do it right than on some other platforms.)

6) Configuration
by FeeDBaCK

In what way does Bastille differentiate between different types of installs? Does it prompt the users about services? Will it shut off my apache service if I plan on making this machine a web server?

What third party tools do you install/recommend to help with the hardening of the system? Tripwire? tcpserver?

Do you incorporate any form of checking when doing your install to ensure that the box has not already been compromised, such as checking for common trojans/backdoors?

Jay: Oh no, another multiple-part question. OK, first, Bastille doesn't really do this distinguishing for you, when run in the default interactive mode. You make the choices, turning off services that you don't need, tightening the configuration on those you do. Second, I strongly recommend Tripwire. It's really the only way to know if your system has been compromised. I'd also recommend replacing your mail daemon with Postfix, as it's got an incredibly secure design. Third, no, we don't. Damn, that's a good idea. FeeDBaCK, want to help us develop that? E-mail me.

Jon: If the box has already been sufficiently compromised by a sufficiently capable and dedicated individual or group, it's a technical impossibility to detect it. Let's say you've cracked the box and installed some custom kernel modules that will report 'correct' file contents for, say, your PAM library even though it's been changed. Tough to do? Yeah. But possible. How would you defend against this?

That's not to say we shouldn't try, but I don't think we can provide adequate assurance on the issue ...

Jay: Jon's got a good point here. But we can, as FeeDBaCK suggests, do at least the trivial first measure of looking for known trojans.

7) Debian?
by luge

Do you guys have any plans to do something similar for Debian, or have others approached you about it? I'd love to apt-get install bastille, and have it do something similar to what I've heard it does for RH. Anyway, even if you don't, keep up the good work.

Jay: We are planning on it. I'm working on a new architecture, which makes it easy to extend Bastille to other distributions without doing the classical "porting" work. We'll include Debian and even Slackware! Watch freshmeat or our announcements list -- when we're in beta quality, I'll announce.

8) Not such a good name for a distro ...
by AFCArchvile

..especially if you want to convey security. Do you remember your late 18th century European history? Right. The Bastille in France was invaded and destroyed, prisoners were liberated, and the monarchy was overthrown by that terrible harbinger of death, La Guillotine.

I'd hate to see any Bastille Linux-oriented viruses or trojans. Maybe there will be one which triggers on July 14th of every year and echoes on the screen: "Libert=E9! Egalit=E9! Fraternit=E9!"

For more historical stuff on Bastille Day, check out this link to the French Embassy.

Jay: OK, so maybe it was a tough name. To tell you the truth, this year's July 14th LinuxSecurity.com interview hit on my birthday ... For the official answer, I'll let Jon pipe in here ...

Jon: Yup, all that bad stuff happened. But the building wasn't the problem: the building was incredibly secure by any standard. The problem was the administration.

So it is with computers.

Besides, we're not a distribution. :-)

9) Why is Bastille Necessary?
by DG

In a perfect world, the Bastille scripts would be unecessary, because the default installation of the distribution would have been hardened from the get-go.

Why do you feel that various distributions are so insecure by default? What are the most common mistakes they make? What kinds of changes need to happen at Red Hat to make your scripts unneeded?

Jay: Well, some of the insecurity comes from trying to reduce phone support costs. Consider for a second what would happen if Red Hat deactivated telnet on their machines, for the reasons I stated above. How many man-hours would go to the five-minute telephone calls, explaining to newbies that telnet was insecure and that ssh was a valid replacement? On top of this, remember that vendors are constantly being pushed to add more and more features. This often flies right in the face of effective security, which is generally much more minimalist.

The thing is, really, that it's not always as clear-cut as "mistakes." The most secure installation is utterly and completely useless. Much of what Bastille's actions make the system at least "inconvenient" and often require user/sysadmin education. Bastille-type hardening programs will always be necessary, especially for Red Hat, a company which has to keep its distribution featureful, easy to use, and convenient.

Jon: Convenience and security are almost always inversely proportional. Red Hat's target market has a whole bunch of people whose goal is to get a web server on the Internet in sixty minutes or less; higher security would only be a barrier to their customers' goals. They know their target market better than we do, but our market is for people who need something else.

Also, I think it's very unfair to single Red Hat out. We picked them as our first target due to their market penetration in the US and the relative ease of securing it, due to the limited quantity of stuff it installs.

Jay: I have to agree with Jon again here. I'll stop before I get on my rant, but companies develop where their users/customers ask them to. People are not asking Red Hat or MandrakeSoft or any other vendor for greatly enhanced security -- they're asking for more convienence, easy of use and a massive feature set -- and they're asking for it without much regard for the effect on security. This isn't intentional. The users just don't know better yet. This is where education must come in. (End rant)

10) Distribution specific, etc.
by matman

I have two questions actually.

The first: do you plan to make a non-distribution-specific hardening program/system/script? If so, how? It would be neat to have a consensus between distributions on file locations, etc to make this easier; do you plan on working with other distributions to come up with some sort of common interface or environment?

The second: do you plan on including any kernel-based capability, IDS, or ACL addons? A good default use of these features would greatly increase the security of linux in general, but they are prohibitively complex for most users. Thus, these are great things to have taken care of by the system -- do you plan on working on something to control these things (semi)automatically?

Jay: Yes, definitely. In fact, I'm currently working on a new internal architecture that easily supports this. In essence, we simply have to keep track of and store more data about each distribution. On top of this, we have to check the state of the system more thoroughly, looking for general files, instead of packages. We'll be able to support a lot more than just Red Hat Linux and Linux Mandrake.

Unfortunately, I don't think we'll ever get to the point where we can dictate file locations to the distribution makers. They're not even maintaining the same file locations from release to release! I think it's mostly an issue of preference for their individual package maintainers, really.

As for kernel-level capabilities/ACLs, I'm highly interested in this. I think the implementations are still immature, but it'll be exciting. Usability will be tough, but I think it can be achieved. We can make this optional for new users and perhaps only place restrictions on small parts of the system. This stuff shows a lot of promise.

A final meta-question
by Jay

The question everybody asks, in a million different ways (sorry, I'm not going through the thread again to pick out users; you know who you are):
Why do this? Why not just use OpenBSD?

Jon: Because people use Linux. Ultimately, standard is better than better. For most tasks, most of the time, assuming that the stuff meets minimum qualifications, it's better to have a single platform than multiple platforms that fulfill different needs.

Besides, a fair part of OpenBSD's security comes from its feature-limited default installation. They've been subject to the same FTP and DHCP exploits as everyone else, only the features aren't enabled by default. Heck, they're not enabled by default for most classes of Red Hat installs either. But people use them.

I'm not opposed to auditing, and I'm not opposed to more secure defaults. But most boxes sure seem to me to be hacked via holes that are known, that have been out for months, in services that aren't being used, and that haven't been patched. We speak to those systems first, since the low-hanging fruit is so extensive.

Jay: Yup. Further, Linux has room to surpass OpenBSD, in my opinion. Linux developers are doing more kernel-level security work, because of Linux's popularity as a standard. OpenBSD, as Jon points out, misses vulnerabilities, because their auditors are human and non-omniscient. Kernel-level security solutions, like Medusa DS9 or WireX's Immunix technology, are the only way to really stop the vulnerabilities that the audits miss. Linux can really rocket ahead here and I think the whole Bastille project will be eager to help.

In closing, please allow me to give some credit where it's due. You can read about this on the web pages: Bastille's and mine. Pete Watkins deserves serious praise for developing and sharing a great firewall. He's also helped take charge of Bastille 1.x enhancements. Sweth C. and Mike Rash have done great work in helping to build new modules and hack existing code. And Yoann V.'s ramping up the new architecture with me -- Bastille will be his baby too, soon. Bastille has benefited from a number of collaborators and sponsors, many of whom you'll find in future CREDITS files.