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."
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.
--
You used CERT to find out where the holes are. CERT is years behind bugtraq
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
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.
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
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*
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)