Slashdot Mirror
Words From Bastille Developer Jay Beale
How secure do you feel? Occams Razor points to "A great interview with [Jay Beale,] the Lead developer, about the Linux Bastille project." Beale talks about the direction that Bastille has taken, and seems fairly pragmatic about the Linux security model and computer security in general. A nugget: "... to fully secure a system, you really have to grind it into dust, scatter the pieces to the wind, and hope that Entropy does [its] part. Since you can't do this, you make tradeoffs."
I'd just like to wibble a little about my experience, as a developer in a corporate environment, with watching boxes get secured. I'm afraid I've had to post this anonymously, as I don't want to give away any information about which corporation I'm talking about (moderators: AC's need lovin' too...)
I've seen our architecture/support/security guys lock down NT and Unix boxes (both of various flavours). What's struck me as the major difference between the two is the level of experience they've brought to the job. It seems to me that Unix is a much more known quantity; people *know* how you lock down a Unix box, they've been doing it for 15 years. NT boxes, OTOH, are relatively new technology. No-one really has a big-picture overview of what you've got to do to them. This leads to all sorts of mistakes (I want to change permissions on this directory...of course that means override all subdirectories) - and it's difficult to tell when you've finished.
The other big problem that you face is reversibility --- if someone makes a security change, can you undo it without rebuilding the box? If not, what will that stop you doing in future --- all software that goes on web boxes will need upgrading, and if that upgrade, eg, involves a new DLL & registry editing, can we do it? [insert analogous Unix-type question here]? Is the technology described in the article reversible? It does say (ominously) "You see, to secure a system, you'll have to remove some functionality" ... how closely defined can you make "some" in that remark?
Just my $0.02
More opportunity. Trojan horses are easier to get as user, as it is to exploit problems with pine or lynx and such. Not to mention the much higher likelihood that you can sniff a user account's password, or that if you crack a password file, odds are good that the users will choose weaker passwords than root.
How about the recent problems in BitchX (made me glad that I had been running BitchX in a well-supervised chroot for quite a while), that would also get you a user account.
etc etc etc
----------------------------
Why name a security product after a fort whose only claim to fame is that it was stormed by a bunch of peasants? :( and b) really, a better name :) My suggestion would be Gibraltar, or maybe (once they get IDS set up) "Invading Russia in Winter."
Seriously, it sounds like a cool product, but a) no debian yet so no help to me
~luge
IAAL,BIANLY
I installe Bastille a few days ago. It's a great idea... a security "hardener" for Linux. There are a few things about it that kind of bugged me though.
On thing that bugged me is the fact that it doesn't make it easy for you to choose what kind of security you're really looking for. For example, all I'm really concerned with on my home machine is network security. I don't want people connecting from a remote location and doing nasty things. On the other hand, I don't care about people who have physical access to the machine, because I have physical security to prevent that. Bastille ended up chmod'ing a bunch of executables so only root could use them. This ended up breaking numerous things, including the Helix updater. I couldn't even run ifconfig as a normal user after running Bastille. At least it generates pretty thorough logs, so I was able to undo the "damage".
The other thing is that it doesn't do any checks of what's turned on in your kernel. I was pretty sure I didn't have the firewall support compiled in, so I was pretty surprised that Bastille didn't complain. Some investigation showed that the scripts it installed to secure the network connection were all failing because of this. This is especially dangerous, because without actively checking, some users will think their system has been secured when it really isn't.
Over time, I'm sure Bastille will get better. In the meantime there are some quirks though, so be careful.
--
But there are people working on things like this.. I'm one of 'em.
Cheers,
~ Signal 11
That's the theory anyway.. the practice is that creating an initrd.gz image with SSH, login/authentication capabilities (via PAM) and the necessary tools to boot up a basic mandrake 7 system is about 20MB. Bloatware (ugh). All that needs to go into RAM. Even worse.. the linux kernel only defaults to creating 4MB of ramdisk.. so as soon as it accesses anything past 4MB.. *BOOM!* fscking piece of #$@! anyway.. I'll write up a HOWTO once it's done.
Does anyone know any others?
Saturn services (saturnservices.com) also allows ssh with every hosting package.
Finkployd
You used CERT to find out where the holes are. CERT is years behind bugtraq
From the article
... as Bastille does more and more, it has to ask a lot more questions! ... but it annoys some users who just want a quick fix. ... we're making "One Shot" configurations, where they can choose a sample configuration that matches their own and deploy that. While they miss a crucial part of securing the system (Secure the Admin!) they still get a safer system...
Secure the Admin means to educate the Admin on the tradeoffs between security and ease of use. As Pen said in the original post, Security is inversely proportional to convenience. Bastille takes the next step, and tries to educate as it undoes what the distros have done. Its easy to make a machine very secure, but you end up with a box nobody can use. With an under-educated Admin, it can be very tough to know what to turn on or off and why and how.
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
First step to securing a system is to secure the admin.
Then go to work securing the system.
Its a motto I've been living by, but it can be very frustrating at times when all someone wants is a big security switch. I tell them its the one marked [| O], the | means insecure, the O means Oversecure.
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
This method would require that you type in a password ot mount your root/usr/whatever partitions. no password, the partition is just random junk.
This is already easy to do for most partitions, but not root. What sig11's trying to do is to make a boot sequence that mounts a temporary partition, asks you for the password and then remounts the encrypted root. This is kinda tricky, as it requires you to atomically ('cause you always need a root) swap root partition. I looked into this as well a few months ago, and as far as I could figure, I'd need to hack the kernel to make a swap_root_fs call or something.
Too much hassle. I found an encrypted home-dir package which was a 95% solution for 5% effort.
The real trick in all of these cases is to avoid getting the password swapped out to disk. Encrypting the swap can slow things down alot.
That is a dangerous assumption. Nowadays with the growth of broadband and always on connections, its important that all machines are secure.
In fact I would say that since desktop machines are administered as well or as closely as server machines, its more necessary to have easy ways to secure it.
Many insecure desktop machines are used to cover the tracks of crackers, as well as to launch DDoS attacks.
...that it's a little odd to name a security enhancement after a fortress that was successfully stormed (admittedly by the good guys). Though not an exact analogy, it's kind of like a Texan naming their security system The Alamo. Which reminds me -- Go Armstrong!
Anyway, at least they didn't name it the "Maginot Line" or "Dien Bien Phu".
Since most Unix machines will allow telnet access from any IP address, and many other machines allow FTP or other filesharing access from any address, then you are basically as secure as the weakest machine one of your friends or users happens to log into you from, which could be anywhere and is not under your control unless you make special effort.
The reason for this is that if a cracker (always use the correct terminology...) should break into some less-secure machine than yours, he could install a network sniffer or keystroke recorder on it that captures your buddy's password the next time he logs into your supposedly secure machine from the compromised one.
Poof goes your carefully secured fortress. He doesn't have to use any careful exploit at all to crack your machine. He just logs in using your buddy's username and password.
Better hope you're machine is tightened down against root cracks, and you better hope your buddy wasn't logging in using the root password.
One thing for sure - don't every log into anywhere as root, or do an su, if your telnetted via an intermediate machine, as there could be a sniffer or recorder running on that machine.
This exploit may be even easier than you think - one of the original versions of telnet could be compiled with a debugging flag that, if set to true, would dribble all the keystrokes out to a file. All the hacker had to do would be to gain write access to the telnet executable file and set the value of the global debugging flag from 0 to 1 and he'd get everyone's keystrokes that ever used telnet.
Me? I don't ever use telnet. I use ssh (secure shell). The only external site I ever log into is my web hosting service. I think a minimum requirement of a web hosting service these days is that they provide secure shell access to their customers - mine does, it is Seagull Networks. Does anyone know any others?
Also don't transfer files with FTP - passwords are provided in the clear and crackers can copy your files with sniffers. Use scp (secure copy) instead.
-- Could you use my software consulting serv
While my complaints about A/UX fell on deaf ears in the A/UX team, the people who maintained the Unix machines for Apple employees to use (yes, some Apple employees do use Unix, they even used to have a Cray running Unicos) invited me to play capture /flag.
In the root directory of some of the multiuser machines was a file named flag that was not writeable. The objective was to write into it and then tell the admins how you did it.
When I started the current contents was "such and such a department rules". I guess I would have written "Mike was here" or something.
While I was able to crack A/UX 2.0 every which way, I never could capture /flag.
My understanding is the security holes got fixed in A/UX 3.0. It's a dead product now.
The way I found the security holes was to start methodically working through the CERT advisories and checking which ones A/UX was not compliant with. When I'd find one and they'd refuse to fix it, I'd file a bug report and send some emails around with explicit details of how you can break root because they weren't listening to CERT.
If you administrate a computer on a network, you should go through the CERT advisories yourself and tighten up your system.
-- Could you use my software consulting serv
There are some folks working pretty actively on adding Slackware support, and I think Bastille will have Mandrake 7.x support before too long. The biggest reason Red Hat is "the main target" is becuase that's what most of the developers seem to use, and being a volunteer project, there isn't a big ol' lab where Bastille hackers can play with all the distros (and architectures!) they might like to support. Anyone with a bit of experience and Perl knowledge who wants to help extend Bastille to support other distros would be welcomed!
Yes, but the point is, as a bastion of security, the Bastille was UNsuccessful. Hence, a poor model for or symbol of network security.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
You are protected, in the U.S. at least though laws in other countries differ, from being compelled to bear witness against or present evidence against yourself. You would have to decrypt said data if it would incriminate other people (not including a spouse) or be of use in criminal matters not pertaining to you, but if decrypting that data would provide evidence against you then you are constitutionally protected from being compelled to do so. The only exception is that you could be compelled to decrypt the data if you were guaranteed immunity from prosecution for the offences the decypted data implicates you in, in which case you wouldn't have to worry about doing it since you'd be free and clear of all related charges. There are many alarmists who keep crowing about how you can be compelled to decrypt your data, but in the U.S. this is not at all the case. The U.K. I fear is a different matter entirely, but I defy anyone to find a single U.S. case in which someone was held in contempt of Court for not decrypting data that could implicate him, who was not given a guarantee of immunity to do so. You won't be able to find one.
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*
Mitnick was never compelled to decrypt the contents of his drive. Law enforcement is keeping the drive *because* he refuses to decrypt it, but he's not in jail for contempt of Court for not doing so. He can't be compelled to decrypt it because the contents may incriminate him, and to force him to do so would violate his Fifth Amendment rights.
Now, whether or not law enforcement can keep the drive(s) indefinitely is a very gray area with little precedent. As of now the matter hasn't been appealed as it could, and for good reason: Mitnick is still on parole, unable to be near computers and such things anyway. I wouldn't want to anger the people who fucked me over for so long and who can still put me back in jail for minor things. But I hope that when Kevin is truly free and no longer on parole, that he challenges this and wins--but I wouldn't count on it, since the value of those old computer components is negligible even now, since it's been so long, that a fight over them wouldn't be very financially justified. At any rate, I'd rather forfeit a couple of hard disks than my freedom, so it's not such a bad deal.
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*
I'm always disappointed that there's not a greater effort to provide data security through an easy-to-implement optional encrypted file system. Yes, you can get the patch from Kerneli.org to accomplish this, but this really isn't enough. The first line in the Howto on kerneli is: "This process requires the kernel source code, knowledge of compiling this code, and a lot of patience."
There should be a distribution--and maybe there is, can anyone point us to it?--which offers the encrypting file system as an option during install. Most of the install process for the more friendly distros already have all the install options laid out in fairly easy-to-use dialogs and what not, but it would go a long way toward insuring privacy if an encrypting file system were a standard install option in a big distro. With relaxation of crypto export regulations, it's becoming increasingly possible for the big US Linux companies to do this, and of course most non-US distros could have been doing it already.
The fact is, most *nix OSes are already much more secure from cracking exploits and viruses than Windows can ever dream of being; something like Bastille is just icing on the cake. But the next step in security, and in ensuring our privacy, is having an encrypted file system as an option in widely used distros, or in widely used/easy to apply add-on products. A standard complaint when someone suggests this is the increased overhead--but with modern microprocessors, the overhead is barely noticeable--I'd know because I use encrypted file systems in Windows on a measly old K6-2 400, with overhead barely visible at all. Just try using an efs on a processor made in the last 2 years, and you'll see it's pretty snappy. Running programs from encrypted drives does sometimes have noticeable, but not deadly, overhead, but accessing data stored on those drives (logs, writings, multimedia files, etc.) is hardly slower than accessing it on non-encrypted drives. And this is my experience under Windows, I can only imagine that under Linux performance would be far superior.
Just an attempt to point out that there's more than one issue in security; securing from crackers is far more well addressed, in almost all operating environments, than security for stored data. These days the U.S. and U.K. governments, and many others, are cracking down on expression of unpopular ideas and distribution of IP-infringing source and executables, and if they come to search your computer and find an encrypted file system, you're better off than if they find that copy of a DeCSS sort of proggie you wrote, or that article you thought you published anonymously but they managed to trace back to you, or the opinion you expressed about a company which has now decided to sue you for libel, or that copy of the webpage you uploaded which calls school officials and classmates the misguided bastards they really are.
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*
What I mean by the subject line: don't think that ssh in itself guarantees security. Even with ssh (or scp for that matter), there's always a danger of a man-in-the-middle attack (as ssh itself calls it). A compromised machine between you and the host you're connecting to could easily pretend to be that host, sending you a fake ssh key, and forwarding your packets through another connection to the real host. This way, your communications is encrypted, but only to be decrypted at the compromised machine and re-encrypted and forwarded to its real destination.
Of course, this could be prevented if you know the key of the host you're connecting to beforehand. But how many of us actually verify the authenticity of the host's key the first time we connect to that host? And some hosts do change their keys once in a while (perhaps a reboot, an sshd upgrade, etc.) -- although we *could* verify the new key, I doubt in practice most people bother to.
Anyway, my point is, don't ever fall into the trap that human beings are so prone to: equating security with some entity, like unconsciously equating "ssh" with "secure connection". To be truly secure, you have to be careful at every step. Unfortunately, this is often impractical... but at least, be aware of the vulnerable parts of the chain so that at least you know what could bite you (or what bit you, if something happened). Never, ever, fall into the trap of thinking your system is secure.
A system is never 100% secure; so, it's better be aware of its vulnerabilities than to blindly trust it, and then look around bewildered when something bites you.
---
mikre he sophia he tou Mikrosophou.
I gave bastille to a friend that wanted to learn about security, and he was able to secure his box, get answers for some of his questions, and overall have a better understanding of how security on Linux boxes should work.
Now if they would only port it to slackware...
Jay, keep up the good work!
--
--
brave little toaster
"Remember, don't try this at home until the statute of limitations has expired."
Information confidentiality is not information security. Confidentiality of is only one aspect. Integrity and availability of information are also important -- often much more important than confidentiality.
Look at slashdot itself for an example. How important is data confidentiality? Ok, there are some passwords people could steal, but they're not significant by themselves -- they're only meta-information. Why are the passwords important? They don't protect confidential information -- they guard the integrity of authorship. To slashdot, integrity is more important than confidentiality. (Of course, there's the issue of true identities... but slashdot could only provide clues.)
How severely would a denial-of-service attack impact slashdot's business? Very completely. An effective denial-of-service attack would completely disrupt slashdot's business.
As far as I can tell, availability is slashdot's (and many other organizations') most important information security consideration. Confidentiality is the least important of those three information security categories (availability, integrity, and confidentiality).
Most information is not confidential, so in most cases, integrity and availability of information are the top priorities.
Many of the severe threats to information security throughout history have been its destruction and/or modification, and many historically significant compromises to confidentiality are now viewed as desirable increases in the availability of the affected information. Confidentiality is (as is illustrated to an extreme in George Orwell's "1984") also extremely important, but it's not the only consideration in information security.
Ok, let me explain (I'm the person from Mandrake Jay is talking about)...
Mandrake has its own security system, which was called Msec, and was renamed to Usec (Unix Security) because many people asked for Msec to not only work on Linux-Mandrake, but also on any kind of Unix system...
Msec was coded too quickly, it was a bunch of shell scripts, hardening your system security and doing some security check using a cron job;
unfortunately, it was unmaintainable...
So Usec was coded with maintainability in mind,
using two XML databases, one for security points (see questions, with predefined answer for default security level, etc etc ), and another database with defined actions for each answer to each questions...
All of that was coded in a library called libbus,
that can be easily used by frontends.
Finally, Usec and Bastille-Linux decided to merge into one project called BUS ( Bastille Unix Security );
The point is that we keep all of the Usec stuff,
excepted backend, and that we use the Bastille-Linux perl backend, which many people have put a lot of work in ( Bastille-Linux backend support, as an exemple, transaction, and any change can be backed out. )
All the Bastille-Linux security hardening point will be present in Bastille Unix Security, the security points just need to be rewriten in the XML databases (a lot is already done right now)
Don't get the wrong idea. Security is always a good thing, but in my mind, I don't see what the point of this is. Why not just use OpenBSD, with uncompromising security, and then stick your Linux boxes behind a firewall? For a home user, simply simply following standard procedures and closing off unnecessary ports can achieve a reasonable level of security.
For a business, a real firewall, protecting the weaker systems can be enough. I'm not saying I'm a BSD zealot, and there isn't anything wrong with having an 'ultrasecure' Linux for its own sake, but I don't really see why this is needed.
Amber Yuan 2k A.D
"and dear god does this website suck now." -- CmdrTaco
Actually, IBM does this, and they provide whets called a 'security audit' for companies for a fee. Interestingly, IBM has a lot more luck simply walking into companies and walking out with their systems in their arms then they do with breaking into systems. (about 70% success vs. 20% success)
My high school tried a similar tact when testing out some crappy Mac software, unfortunately the guy they got to test the software a huge moron (The school wasn't really that bright, they only provided 3gigabytes of storage for 1700 students, they ran out of space 3 weeks into the first semester). The major problem with the security wasn't security, but the fact that the software managed disk space, and program crashes by deleting random (or all) files.
Amber Yuan 2k A.D
"and dear god does this website suck now." -- CmdrTaco
Why is Bastille Redhat only? IMHO is Radhat more a desktop distribution wich probably doesn't have to be as secure as a server.
Would it be difficult to port it to other distros like Debian and Slackware?
After all, the only reason we even know the name Bastille is because the mob was able to batter down its gates rather easily and storm the citadel... But then, the only reason we know the name Crusoe is because he got left stranded on a desert isle -- not the image I'd want my potential customers to be pondering as they considered my product...