Slashdot Mirror
Red Hat to Release Enhanced-Security Linux
Klatoo55 writes "According to an article by Techweb, Red Hat will release Red Hat Enterprise Linux 4.0, which includes support for Security-Enhanced Linux, in 2005. Red Hat has been running this system with a published IP address asking for hackers to try to break the security. The last version was defeated within 45 seconds, but this new version (apparently to be the policy for the next Fedora) has yet to be cracked."
I think we can bring that baby down without a hack.
What say you slashdot?
45 seconds? Sounds liek someone yanked the power cord out of the boxen to do it that fast...
Eat recycled food - it's good for the environment, and OK for you.
Holy smokes!! If it only took 45 seconds to crack it the last time around, I'd venture to say they overlooked a MAJOR security hole. This one has yet to be cracked; but if they overlooked a major one before, what are the chances that there are several obscure security vulnerabilites they overlooked this time?
-- Stu
/. ID under 2,000. I feel old now.
Has they created something by their own to enhance the security, or is it just that they have included some restricitons to the users/administrators? (ie. have they dissabled the root-account?)
------- In the end there are no begining
The article implies that SE Linux would be more secure that Windows, especially in light of the MyDoom virus. But doesn't the MyDoom virus depend on a dope sysadmin clicking on a binary attachment to spread?
So how does SE Linux protect systems against trojans?
It's nice to see that SEL is being adopted by someone like Red Hat. I think this development will get more distros and organizations interested in using it, which will benefit the project greatly.
Like it or not, Red Hat sets the tone in many ways, and in this case it's a good thing.
dmiessler.com -- grep understanding knowledge
"... the root had no IP address" presumably should have read "... root had no password" and the jump from the NSA developed SE Linux to the Eclipse IDE escapes me.
This, IMHO, is smart policy. What better way to find the holes in a distro than to co-opt the people most capable of exploiting them? Even at worst this will give the folks at RH a good idea of what exploits are going to be most frequently used against thier systems.
Of course, the security of any system is dependant upon the admin and how he/she configures the software used on the system, but this at least will help to establish a baseline from which to work, and provides full disclosure of any inherent system vulnerabilities to the admins that work with the system.
...as an added bonus, this /. post will see how the system might stand up to a major bandwidth spike....
Don't Panic!
Yes. But exploiting a bug in a particular application or service is only going to expose the data that application or service uses. In a SE Linux system, you don't gain root or system privileges by breaking an application or service since NONE of them run as root.
What happened? Someone ran a brute force root login with the pwlib dictionary or something? Maybe a quick ride with Nessus? Or was it a social engineer who managed to call someone and get the root password?
As has been echoed before time and again -- security is a process, not a product. Of course you'll have more secure products, but it's still up to a competent admin to make sure things are kept secure. Even then, you better have good backups because that one disgruntled guy who works in the mailroom on a machine already inside the firewall just might have an extra ace up his sleeve.
It seems to me that our package managers (used by the majority of Linux users...not everyone compiles from source) are vulnerable to some type of subversion. They are not controlled or vetted by a central authority. There is no 'certificate' which can be attached to them to guarantee their purity. What the Linux community needs, I feel, is a type of central signing authority or cryptographically sealed DRM-compatible package management system. This could eliminate potential threats associated with trojaned Linux packages. Imagine a secure apt-get. Packages would be enveloped in a tough layer of crypt() security. They would be digitally signed by the Debian project manager, or even Ian Murdock for highly critical packages like the kernel. And it would be impossible to accidently load and install a trojan. Apt-get could even be modified to 'phone home' and let the Debian administrators know which packages where the most popular (and make security updating easier!) packages were being installed and to automatically e-mail users with news of package updates and 'special offers' from co-sponsors. I look forward to the community's response!
yes, but a good core OS will limit the damage any 1 program can do... A common argument about windows is that it itself is secure, however the programs that run it(drivers/applications/etc) are insecure. In actuallity, even with a buggy/trojan program being run, a good OS would not allow it to reak havic on much of the system, let alone crash the entire computer.
So now Red Hat is using the tired and cliche approach of getting PR by hosting a cracker contest. You would think that they'd have learned from previous examples. Just because a system hasn't been defeated in a cracker contest doesn't mean its secure. Security is a process not something you can shrinkwrap. The proper way to demonstrate the security of a product is through repeated, thorough code audits like some other software distributions are doing. Things must be looking dire indeed for Redhat if they're starting to make announcements of products like this ala another company we know and love.
Mail handling is a good example. Each receive process should be running in a separate jail, with a net connection to the incoming port, a limited connection to the mail database, and no privilege to open files or network connections. Then it doesn't matter what happens in the receive process.
The software that passes data across security boundaries has to be carefully written and audited. But it doesn't have to do much. Software has to be divided into two kinds - big, untrusted programs that do the work, and little, carefully audited security-critical programs that do very little.
The job of the OS is to keep each program in its own security box.
Mail, DNS, and web servers need to be broken up in this way. Now that Red Hat is going with SE Linux, it's time to do this. Get busy.
Anyone know the IP in question?
It's 127.0.0.1. If you do manage to break in, see if you can find any interesting files, and go ahead and post them up here.
2 questions:
Anybody have more info as to why the last machine was compromised in 45 seconds?
Anybody know of a guide for the Linux beginer on how to secure (shutting down services not needed for a desktop machine, in an easy to understand way)a out-of-the-box desktop system??
from: root@redhat
to: groups@l33tscript3rs.org
subject: hack da gibson
Hackable Server, come hack me plz. IP: 127.0.0.1
"But vendors and IT decision-makers widely believe it is too expensive to implement these more hacker-resistant security models, he [Tiemann] said."
So let me get this straight: US industry alone spent around half a billion buckaroonies cleaning up the last little virus/worm fiasco, we get about a half-dozen or so of these little gems per year, and yet it's TOO EXPENSIVE(tm) to engineer in security that would stop this kind of thing from happening?
So tell me, just who are these "vendors and IT decision-makers"? Or, to rephrase the question, just who are these drooling, incompetent, feeble-minded idiots who understand so little about security and the consequences of its failure? I'm asking because I want to make sure that i never, ever use (or heaven forbid, purchase!) any product that they have had anything to do with.
Mr. Tiemann, please tell us, did some people actually say this? Really? Because if so, we need to know which products, companies, and idiots to avoid. And I want some of what they're smoking.
Anyone care to share their experiences with SELinux?
There have been exploitable buffer overflows in (going from memory here) PINE, MetaMail and Mutt, all of which in theory could allow a trojan email to be sent to a unix user, and none of which required clicking on an executable.
Are you willing to warrant that there are no such holes in Evolution, Thunderbird or KMail?
News for Nerds. Stuff that Matters? Like hell.
I was at EclipseCon and saw his speach. He didn't say that the last "version" was hacked in 45 seconds. He said the "average" time it took to hack a computer without a firewall on the internet (including M$ and *nix) was 45 seconds and that a version of SELinux is on the net with no firewall or root password and it has not yet been compromised.
"So you call this your free contry, tell me why it costs so much to live?" - Three Doors Down
I have never even used SELinux, but unlike many here, have at least taken the time to read up on it. Here is the little I have understood:
SELinux, if set up properly, is secure, and completely bypasses the inferior UNIX security model. You could say:
* Windows is insecure
* Linux is less insecure
* SELinux is almost secure
IN SELinux there is no root account, or at least it has no privilidges -- user's don't have privilidges in this system. So, you can give root to anyone and they won't be able to do a thing. Gentoo have a machine with public root access for just this purpose.
The difference is that each program is banned from doing anything by default. Reading a file, using the network, whatever... The packagers must explicitly assign each program access to what it minimally needs to do it's job.
So Bind (fairly insecure) might be given read access to it's config file, write access to it's cache directory, and port access only for the ports that it needs to listen on. If you then exploit bind it doesn't buy you very much. You can change the cache files, and answer DNS queries, but you can't even change Bind's own configuration, let alone anything else.
You may have the right as an administrator (nothing to do with root) to run bind, but the programs you run do not inherit your privilidges.
As a user, the privilidges that you have depend solely on the roles that you belong to. That's why root is useless, it is a user not a role.
Although there are many security patches for Linux, SELinux seems to me the only truly sound approach to security out there at the moment. If you combined it with hardening solutions designed to minimise the chance of exploits (binary sandboxes) you would end up with a system that is very difficult to exploit in the first place, and once you do manage it it buys you almost nothing anyway.
Although SELinux is built into Linux 2.6, it must be turned on and manually configured before it is useful. This is currently being done for Fedora, Gentoo, Debian, and other serious Linuxes. I believe this will make Linux the most secure general purpose operating system available. Then we really can lord it over the Windows users.
Lsof is useful for analyzing a box, but you can simply add the -p flag to netstat -- netstat -ntap -- and see the controlling process. Run this command as root, or netstat will only be able to identify the processes you own.
/etc/rc.d/rcX.d/).
/var/log). You back up your data, right? (If not, you *will* lose your data one day, and *will* be a sad camper trying to rebuild everything you've ever created that you didn't want to spend thirty cents on a CDR backing up). Include your logs in your backup procedure.
On Red Hat, use chkconfig to set which services start at startup (this is nothing more than a pretty frontend to rename a couple symlinks in
The first thing you should do on a new box is run whatever update mechanism your distro provider uses. Apt-get update;apt-get upgrade, yum update, whatever. There have probably been holes discovered. If security is more important than fully tested reliability, I'd automatically run the update sequence through cron nightly.
If you're extremely paranoid, run syslog to a second machine. If your main machine gets compromised, you have a nice log.
Major Linux oopses I've seen before:
* When using X11, never ever use "xhost +". )"xhost +local:" is still asking for trouble.) I don't care how much of a good idea it seems like, *don't fucking use it*. Don't even do it if you aren't on a network and don't think anyone will ever connect to you. This disables all authentication to X11, and at one point a lot of university hackers (old school) used this when they wanted to run a program from another system. Do not do this. If you're running su'ed as root and root can't display a window on the local X11 server due to lack of authorization, use "xauth merge ~[username logged into X]/.Xauthority". That'll just grab the magic authorization cookie for this session from the local user's auth file and hand it to root, so that root can continue to work. Note that recent releases of Red Hat (perhaps due to changes in XFree86, perhaps due to something clever in root's login scripts) seem to authorize root to poke at local displays. Without this, anyone on the Internet with any inclination can sniff your keyboard, dump your screen, send input to your programs, and generally has full privileges of anyone that uses the X server.
* When using X11 programs from a remote system, use ssh and use X11 tunneling. If you don't do so, your keystrokes will cruise over the network unencrypted.
* Use ssh protocol 2 in preference to 1 unless you are damn sure that doing so is not a good idea (or you want to use protocol 2 only). This is probably already default for your site.
The above two points can be implemented by adding the following to your ~/.ssh/config -- this is what I use:
Host *
Protocol 2,1
ForwardX11 yes
* Don't use FTP. We have scp for a reason. FTP sends passwords in plaintext.
* Don't use plaintext mail authentication. Too many people send out their mail password in plaintext. Someone with a 802.11b-capable laptop and sniffer on a college campus can grab *masses* of email passwords from someone's copy of Outlook trying to grab new mail every ten minutes. Most places with a competent mail admin support at *least* support MD5-hashed passwords (which still exposes your email to anyone listening on your network segment, but is better than nothing in that they can't also get your password). I use fetchmail with SSL enabled.
* (not a vulnerability, just a tip) Most Linux distros today are reasonably secure in terms of enabled services out of box. Used to be, in the Red Hat 5.x era, that finger and telnetd enabled out of box was entirely reasonable. Today, however, many folks don't know how to disable services, and so most distributions ship with things off instead of on.
* Archive your logs (generally, the contents of
* This isn't a Linux-specific suggestion, but use gpg. Linux is one of the few platforms with free mail clients
May we never see th