Red Hat to Release Enhanced-Security Linux 326
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."
Security? (Score:3, Interesting)
I'm Done With Redhat (Score:1, Interesting)
I hope things work out for them because to a large extent, their success (or lack) will be tied to the Open Source movement.
Invulnerable to MyDoom type virii? (Score:5, Interesting)
So how does SE Linux protect systems against trojans?
This is the right question (Score:5, Interesting)
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.
now or later? (Score:2, Interesting)
i didnt RTFA but the blurb said nothing of compensation if someone did crack it. IF there is a bounty, im sure its not as much as one would make cracking a bank a year from now.
Re:Windows Beats Linux! (Score:5, Interesting)
I guess it's no surprise, given the amount of Code Red traffic there was at the time, but I just didn't think of it at the time since I had planned on installing all the updates after reloading.
Out of box Security (Score:4, Interesting)
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??
Re:Invulnerable to MyDoom type virii? (Score:3, Interesting)
Because a privileged app can't setuid, they all have to have their own user + a password hardcoded into the binary (or stored in the registry.. same difference) which can be decoded to plaintext (Windows requires the plaintext password of a user to call LogonUser even if you're an admin). This is why there's the IIS_xxx accounts in Windows so IIS can drop privileges (decoding those passwords is trivial and it's quite fun as you can't change them!).
Of course if you're a *legal* app then you need the plaintext password. If you're a *virus* then you don't.. you just need enough social engineering to be able to get either write access to a couple of critical registry keys or CreateToken privilege. If you get access to the registry keys, btw. you can create a delegation level access token and use that access to do a network-wide hack (no I'm *not* going into any more detail... I only got away with it because the net admin at work has a sense of humour... like the day I dumped a list of every password on the network on his desk and said 'it's about time people stopped using their first name/girlfriends name as their password!').
Tony
Re:Windows Beats Linux! (Score:3, Interesting)
Re:I wonder how the last system was defeated? (Score:1, Interesting)
You're an idiot. It's common knowledge, especially with the Slashdot crowd, that early Linux versions were easy to hack.
Hell, I got so much root back then (though a lot of that was thanks to SunOS, not just Linux).
Re:Other ways to improve Linux security? (Score:3, Interesting)
You know, you probably *are* right -- the FSF's archives didn't get broken into for no reason.
However, I think that other avenues are more appealing.
Think about the number of packages in a typical Linux distro. There are a lot -- I currently have about eleven hundred packages installed. Assume that each project has an average of two people with CVS commit access. Many projects do not have rigorous revies of all commits. If someone can compromise the computer of *any* of these 2200 developers and slip a subtle hole in. If someone can submit a patch with a hard-to-find hole, how likely is it that they can manage to slip it in eventually? If they do an anonymous submission, they can keep hammering software projects with evil patches. I have no idea who maintains, say, gkrellm, but how do I know that he's good at ensuring that UNIX software is secure and back-door-free?
Red Hat probably puts a phenomenal amount of work into securing their distribution servers. A single developer's workstation would be a lot easier to compromise.. Package management is a weakness in that it instroduces a new person with the ability to produce a malicious package -- the packager.
No, the last thing Linux package management needs is more centralization. What we need is *less* centralization.
I cannot agree. Mike, I agree with your technical goals in package management (and respect the work that you've done), but I don't find this to be a security argument. A system such as this is weakest-link. Only one system involved in the production, building, and distribution of software must be compromised for the end user's systems to be compromised. More decentralization means more systems to potentially be a weakest link.
What Linux package management needs to be more secure is for projects to host their own binary packages as they do for source packages. That way if/when breakins occur, the damage is at least limited.
Mmmf. I can't agree. At least with the RH/Fedora model, there is a long (months long) QA process run on the software ahead of time. If software projects have the power to push updates to the masses without QA...they could cause all *kinds* of problems. Currently, they have only the power to push updates to Red Hat.
If software projects provided eDonkey links or similar, so that a cryptographic hash of the file is in the wild, that *would* be one more guarantee of security.
Packagers don't audit the code, you know.
In general, you're right, but RH has pushed security patches to projects before.
Bandwidth issues.
Re:Other ways to improve Linux security? (Score:3, Interesting)
There is a way that Linux packaging could be used to improve security. Current state-of-the-art Linux packaging systems pretty much operate in "install as root". There's a script run that runs as root and has the ability to do anything. It would be helpful if, packages could contain a standard way of denoting the privileges that a package requires to be installed. (A package manager could place restrictions on what is allowed.) Package managers currently provide very minimal or nonexistant sandboxing capabilities.
For example, perhaps I do not want to allow an installer to create any SUID files, since I don't want more floating around on my system. Perhaps I want to prevent an installer from modifying any existing files, and only adding the files specified in the package requirements. Perhaps I want to *require* that all executable files be SUID/SGID a new user with no remote login requirements. Perhaps I want to require that all executables that the package installs be started with a limited set of POSIX capabilities.
Why is this a big deal? Because it's technically possible to produce a sandbox that will let me run and poke at code from a random person on IRC. But no package managers currently do so. It's technically possible to ensure that more SUID binaries don't pop up on my system -- since SUID binaries are one of the few potential security holes on a UNIX system, I'd like to avoid installing any if possible -- but I cannot do so. It's technically possible to force all installed binaries to run SUID/SGID/chrooted. It's possible to ask that packages not touch any system-critical files -- initscripts, PAM, kernel, etc. Basically, when I recieve an RPM currently, I have two choices. I can su to root and install the RPM, giving the install script and package complete and total control over the system. Any malicious stuff in the package or bugs could blow away my system. I can try installing the thing with a different RPM database as a user with different prefixes, but it's a royal pain. I can choose not to install the package. And those are my only real options.