Slashdot Log In
Words From Bastille Developer Jay Beale
Posted by
timothy
on Mon Jul 17, 2000 05:51 PM
from the honey-did-you-remember-to-secure-the-linux-box? dept.
from the honey-did-you-remember-to-secure-the-linux-box? dept.
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."
This discussion has been archived.
No new comments can be posted.
Words From Bastille Developer Jay Beale
|
Log In/Create an Account
| Top
| 87 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
But the real question is... (Score:3)
Seriously, it sounds like a cool product, but a) no debian yet so no help to me
~luge
Bastille gripes... (Score:5)
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.
A simpler way of saying it... (Score:3)
--
Re:Capture /flag at Apple (Score:3)
Re:A better way of saying it... (Score:3)
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
Re:other distros? (Score:3)
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.
Re:Bastille gripes... (Score:3)
WWJD -- What Would Jimi Do?
Re:Bastille gripes... (Score:3)
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".
This is all part of network security though. The purpose of doing this kind of "damage" isn't just protecting you from local users. The idea is that if an outsider cracker manages to compromise a user account (which is much easier than getting root directly) you want to prevent them from then using internal exploits to gain root.
Capture /flag at Apple (Score:3)
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 [cert.org] 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.
Dont Forget About the Most Neglected Security Type (Score:4)
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.
Re:Mandrake == Redhat? (Score:3)
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)
Re:Capture /flag at Apple (Score:3)
In my day, we didn't have any fancy schmancy Bastille scripts to harden our systems. If we wanted a secure VAX system, we wrote our own scripts to do it. If we didn't know how secure it was, then we called our friend Kevin M. to come over and test it out. Nowadays, all you lazy Silicon Valley kids couldn't secure up a computer if it was turned off. You wouldn't know a secure computer from a circuit breaker and my friend Kevin M. can't help you because he can't come within 10' of a computer. The lazy government didn't like him testing the security of their computers, and threw him in prison!