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 Enhanced Sure! But... (Score:5, Funny)
What say you slashdot?
Re:Security Enhanced Sure! But... (Score:3, Insightful)
Re:Security Enhanced Sure! But... (Score:4, Informative)
qmail security guarantee [cr.yp.to]
SELinux I've heard adds finer grained security features to limit each program's access to exactly what it needs, on top of the user level security, to further limit the damage that can be done by breaking a single program.
I wonder how the last system was defeated? (Score:5, Funny)
Re:I wonder how the last system was defeated? (Score:3, Funny)
45 Seconds?!?! (Score:3, Insightful)
Re:45 Seconds?!?! (Score:3, Informative)
Tiemann outlined an instance of how SE Linux is more secure than traditional Linux in his EclipseCon keynote Wednesday. He said that in a security test on a previous version of Red Hat Linux in 1999, it took only 45 seconds for a hacker to break into the system. A recent test on a version of Linux running SE Linux as its security policy still has yet to be cracked, even though the IP address of the
Re:45 Seconds?!?! (Score:3, Insightful)
What's that supposed to mean?
Re:45 Seconds?!?! (Score:4, Funny)
Re:45 Seconds?!?! (Score:5, Funny)
Re:45 Seconds?!?! (Score:2, Funny)
It sounds like it was designed to be insecure...
Re:45 Seconds?!?! (Score:5, Funny)
Re:45 Seconds?!?! (Score:5, Funny)
Re:45 Seconds?!?! (Score:2)
Re:45 Seconds?!?! (Score:2)
Re:45 Seconds?!?! (Score:2)
(and using USE flags doesn't help either as on the next emerge world it'll pull in all the crap you told it you didn't want next time...)
Re:45 Seconds?!?! (Score:2)
Re:45 Seconds?!?! (Score:2)
Re:45 Seconds?!?! (Score:2)
Security? (Score:3, Interesting)
Re:Security? (Score:5, Funny)
Invulnerable to MyDoom type virii? (Score:5, Interesting)
So how does SE Linux protect systems against trojans?
Re:Invulnerable to MyDoom type virii? (Score:5, Funny)
Re:Invulnerable to MyDoom type virii? (Score:4, Insightful)
I suppose non-root users can't send e-mail? Afterall, that is a major component of what the mydoom virus does.
And I suppose non-root users can't listen on a port for incomming instructions to execute? Or run a proxy server on a non-privleged port?
And will it stop a trojan which asks 'Root password needed to continue:' and then proceeds to use it to screw your system? If users are dumb enough to run arbritrary code, they will be more than happy to supply a root password.
Linux is no more secure than windows against trojans.
Re:Invulnerable to MyDoom type virii? (Score:5, Insightful)
By simply clicking on an attachment in any mail client in linux it will not execute... The user would have to save the attachment to disk, chmod it +x, and then execute it, and then, if the trojan wanted to write anything to disk outside of the users home directory, it would have to ask for the root password, and then if the user was that stupid, ok they really deserve to be infected with a virus. However, in a decently admined system the users don't know the root password, they don't need it ever, and they should never be installing programs. The amount of work it would take to install the trojan on linux would be a deterrent, it is also the deterrent to wide scale adoption by home users of linux.. because installing programs is just as difficult as installing trojans.
Re:Invulnerable to MyDoom type virii? (Score:2)
But for ease of use, and pressure to have admin privs, you have this insecure situation under Windows. The same will be true of Linux if it were to go mainstream.
Re:Invulnerable to MyDoom type virii? (Score:2)
Not necessarily true. (Score:4, Insightful)
Are you willing to warrant that there are no such holes in Evolution, Thunderbird or KMail?
Re:Not necessarily true. (Score:3, Insightful)
Are you willing to warrant that there are no such holes in Evolution, Thunderbird or KMail?
All very true. However, for a virus such as mydoom to spread like wildfire and do the DDoS damage it was designed to do, it needs to acheive a "critical mass" that can only be acheived thr
Re:Invulnerable to MyDoom type virii? (Score:3, Insightful)
Your all wrong (Score:4, Informative)
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.
Re:Invulnerable to MyDoom type virii? (Score:2)
Re:Invulnerable to MyDoom type virii? (Score:3, Insightful)
I would respectfully disagree. Linux is no more secure than windows against "social engineering", but there is a difference in a trojan run as a user and a trojan run as root. One of the primary problems with Windows is the difficulty in running some software that should be "user" software without root access.
I got my first SunOS shell many years ago, and I am pretty sure most trojans, if they had existed, might have wiped out my files, but not wiped
Re:Invulnerable to MyDoom type virii? (Score:2)
Therefore, a Linux virus could 'get root' under a normal user account a hell of a lot easier than one could under Windows. With root access, a virus then becomes a lot more serious.
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 tr
Illogical (Score:2)
Saying linux is no more secure than windows implies that linux gives no advantages over windows against trojans. By your own argument, this is a false statement.
A true (IMO) statement is "Linux is not much more secure than windows against trojans." This is true in any operating system. Trojan
Re:Illogical (Score:2)
Just the same as under windows with the admin/user accounts.
I was just showing that the trojan could even get root access if it wanted to - with the amount of local root exploits it probably wouldn't even need a password. Windows however has very few local root exploits because it doesn't use setuid.
Re:Invulnerable to MyDoom type virii? (Score:3, Informative)
Not with SELinux or other ACL systems such as grsecurity and LIDS if they're given the right settings, revoke net capabilities from all users and only grant them to the ones that need it.
And will it stop a trojan which asks 'Root password needed to continue:' and then proceeds to use it to screw your system?
SELinux will yea
Re:Invulnerable to MyDoom type virii? (Score:2)
I suppose non-root users can't send e-mail? Afterall, that is a major component of what the mydoom virus does.
And I suppose non-root users can't listen on a port for incomming instructions to execute? Or run a proxy server on a non-privleged port?
Uh, yeah, that's pretty much how it would work under SELinux with an appropriate policy. Presuming it is set up properly (and the default
Re:Invulnerable to MyDoom type virii? (Score:2)
Now we could go from here into an argu
Re:Invulnerable to MyDoom type virii? (Score:2)
I could write a mail client under windows which doesn't execute attachments when you click on them, and requires you to save the file to disk and rename it to execute, therefore windows is also secure!
I could write a client under Linux which sets the execute bit and runs attachments when you click on them, therefore Linux is insecure!
bah.
Re:Invulnerable to MyDoom type virii? (Score:3, Informative)
Re:Invulnerable to MyDoom type virii? (Score:3, Informative)
Re:Invulnerable to MyDoom type virii? (Score:2)
What your saying is basically Linux is too difficult to use for a user to spread viruses under. I can see this changing over time however.
Re:Invulnerable to MyDoom type virii? (Score:2)
Alas, to gain usability, distros targeting mass market desktop users are starting to make them log in as root by default (Lindows).
If Linux is ever as popular as windows, I'll bet most people will be running as root. And, they'll not hesitate to download zips and run them. Come to think of it, we can't even tell them "Don't click on
--
We got zips in the wire. Drop all you got on my position.
Re:Invulnerable to MyDoom type virii? (Score:4, Insightful)
Whether I run as root/Administrator or not, all the important stuff on my machine (my files) are read/write/delete my user anyway. Running as an unprivileged user means two things:
a) I can't interfere with other users' files
b) I can't interfere with system files
If I'm the only user, and my system files are all backed up on the nice, shiny install media, what is the difference, apart from perhaps having to reinstall?
Re:Invulnerable to MyDoom type virii? (Score:2)
Non-root users cannot open raw sockets to craft packets (hence nmap -sS must run as root). Non-root users cannot run the ethernet device in a promiscous mode, allowing sniffing of packets on the wire. Before you say anything about switches preventing you from getting anything interesting by sniffing, I suggest that you take a look at dsniff [monkey.org] before showing your ignorance. A non-root user can't open a port below 1024 (Un*x), or add services (Windows), or install a r00tkit on any system, or many other thing
Re:Invulnerable to MyDoom type virii? (Score:2)
Don't think per-user, think per-process (and per-whatever).
If your email program runs in isolation from your other files, and it spawns files as a seperate process, a rogue virus -- even if you run it -- won't do any dammage. It will be effectively 'jailed'; locked away from other resources including the network and other files that the single-us
Re:Invulnerable to MyDoom type virii? (Score:5, Informative)
SE Linux removes what you might consider to be the "superuser" account (aka 'root' under *nix or 'administrator' under Windows).
You can configure the system to act just as it is now -- having an account that is all-powerful (root or another one), or you can have very limited focus accounts that can not 'see' or use the resources of the others.
The core OS still has the ability to do root-like things and dole out those permissions, though the scope of what needs to be watched is greatly reduced.
By itself, this is not interesting. As a base for a security policy, the increased ability to log who-did-what, and the ability to stop per-process resouce use (not just per 'user'), it becomes very very interesting.
Here are some links on it;
Security-Enhanced Fedora Core 2 [lwn.net]
Looking forward to Fedora Core 2 [lwn.net]
(follow this thread) Re: Proposal: Discourage rpmbuild --sign [redhat.com]
The main SE Linux site [nsa.gov]
Re:Invulnerable to MyDoom type virii? (Score:2)
More to the point, it probably only has mail programs which make it clear that the user is arranging to download and run software from an untrusted source, as opposed to merely viewing something.
Re:Invulnerable to MyDoom type virii? (Score:2)
http://www.eweek.com/article2/0,4149,1514997,00.a s p
read the second page, specifically:
" In Windows, though, any user can always act as root for their machine's core programs and MyDoom uses this opening to add %system%/shimgapi.dll, %temp%/Message and %system%/taskmon.exe. Taskmon.exe is a core Windows 98 family file, and Windows lets a user-level program change this, or in the case of the NT/2000/XP family, add this file! This is security at its worse. "
Re:Invulnerable to MyDoom type virii? (Score:3, Insightful)
Not really. Two points:
The problem with Windows permissions is that you could attach an executable and it would have 'execute' permission by default, unless in Unix-like OSes whe
Windows Beats Linux! (Score:5, Funny)
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.
Re:Windows Beats Linux! (Score:3, Interesting)
A good thing... (Score:4, Insightful)
Like it or not, Red Hat sets the tone in many ways, and in this case it's a good thing.
Get a Tech Writer Already (Score:3, Insightful)
Re:Get a Tech Writer Already (Score:2)
Presumably Tiemann made this comment (a perfectly valid one, giving kudos to the Open Source community) at EclipseCon just to tie it in with SELinux, and the writer didn't really know how (in)significant this comment was.
which is most secure (Score:2)
By secure I mean mitigating the likelyhood that any bug will allow an attacker to obtain root, remotely or locally.
Ideally so secure that when properly (and strictly) configured no hole discovered in the past few years would have been exploitable.
Re:which is most secure (Score:2)
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.
Re:which is most secure (Score:2)
But, that was a pain in the ass to set up and update. The server machine was stripped down, for security reasons. So, I had to build the application & updates on a seperate development machine. Then, copy the environment over. It was a painful process.. I couldn't just use updated packages from the project or linux distro. Of course, this leads to not staying
Re:which is most secure (Score:2)
smart policy (Score:3, Insightful)
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....
Maybe (Score:2)
1) It is not a thorough test of security. People miss things, they take the easiest routes, ignoring more difficult but viable attacks, etc.
2) This is the part that most security people hate: it is often used as a replacement for a real security audit. The script kiddies don't really hold a candle to some of the folks whose time is too valuable to waste on someone's PR
45 Seconds? (Score:5, Insightful)
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.
Re:45 Seconds? (Score:2)
Unless they happen to have some back office numbers, they'd waste 45 seconds (more!) just navigating the voice answering system.
And even without that, just the preliminaries of "hello, how are you, nice weather we're having, by the way what's the root password?" would take a couple minutes easy.
I think any hacker worth his paranoia would stay far away from any openly advertised hackfest. A good (and at liberty) hacker i
Technically Gutsy Move (Score:2, Insightful)
Other ways to improve Linux security? (Score:5, Insightful)
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!
Re:Other ways to improve Linux security? (Score:3, Insightful)
That's right. When you have piles of packages (source or binary) hosted on single servers run by the same group of people, you're making yourself a really tempting target. You don't even have to trojan a package - just find an exploit then DDOS the update servers so people can't access the fixed packages easily and you've bought yourself some time. A
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 CV
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 w
All PR and no substance. . . .again (Score:4, Insightful)
Re:All PR and no substance. . . .again (Score:3, Informative)
Re:All PR and no substance. . . .again (Score:2)
And what's wrong with that?
>>>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.
Corrent, but it goes to try to prove the Monkey-Typewriter theory. If there's a problem in the policies/exploit somone's bound to catch it sometime. However, you can log all CURRENT exploits found in that and
Re:All PR and no substance. . . .again (Score:2)
Red Hat page (Score:2)
45 seconds in 1999 (Score:2)
Re:45 seconds in 1999 (Score:2, Funny)
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:now or later? (Score:2)
Or maybe I'm just cynical.
Terrible name (Score:2)
Obligatory MP quote (Score:2)
replace "castle" with "linux distribution" and it almost makes sense.
Default in Fedora? Excellent! (Score:3)
SELinux really does make huge strides in securing a system, providing the policy is set up well (for which there are some tools, but a good default from distros will help immensely). Sure, no system is unbreakable, but SELinux is vastly ahead of anything else out there right now. The more boxes out there secured like this there are, the stronger Linux's claims of truly superior security. Windows really does have absolutely nothing even remotely comparable to SELinux right now.
Jedidiah.
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??
How to secure a Linux box (Score:5, Informative)
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
Redhat Publishes IP (Score:4, Funny)
to: groups@l33tscript3rs.org
subject: hack da gibson
Hackable Server, come hack me plz. IP: 127.0.0.1
Security is too expensive? (Score:4, Insightful)
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.
Too much security for you! (Score:5, Informative)
Anyone care to share their experiences with SELinux?
Re:Too much security for you! (Score:4, Insightful)
Among the other security issues with XFree86:
* Runs as root. On UNIX, this is a big sin. On traditional UNIX systems, and still with most Linux systems (POSIX capabilities are one way around this), root can do anything. If you can compromise XFree, you can compromise anything. Not only that, but XFree does not drop privileges -- the whole damn thing runs with elevated privilege.
* Any user that sits down locally can use the thing. It's easy to interface with.
* By default, most systems listen for incoming connections. If you can exploit the auth system, you control a root daemon remotely.
* There are many ways to authorize to the thing (xauth, xhost, etc). It is easy to turn off authorization, and many people (disturbingly many) do so.
* There are many ways to communicate with the thing (UNIX domain sockets, TCP). XFree is not small and simple and easy to check for flaws.
* XFree talks directly to hardware. Aside from the OS, it mucks with all kinds of things that might be exploitable.
* XFree is a major attack path for monitoring user input.
* XFree is responsible for displaying a login screen (and accepting username and password).
* XFree does not natively encrypt remote connections, though many people now use ssh's tunneling abilities.
* XFree is decidedly vulnerable to traffic analysis.
XFree is pretty bad from a security standpoint, and almost anathema to a trusted system. That's not a stab at XFree -- many decisions have been made in favor of simplicity, stability, and performance, and lots of other remote access systems aren't great from a security standpoint either. If X had been built as a secure system, it'd be a lot less usable for general purpose stuff. It would be the single thing that I would first remove from a system that *must* remain secure.
Tienemen misquotes (Score:3, Informative)
WOOHOO! (Score:3, Informative)
Does this mean they'll actually MD5 the root password?
(Sarcasm-less explanation: During the RedHat installation procedure, the ability to choose to use MD5-encrpted passwords comes *after* you choose your root password, so your root password is encrypted with much weaker encryption until you change it.)
steve
It is a Big Deal (Score:3, Informative)
Re:Big Deal (Score:2)
Indeed, this is why we have projects like Hardened Gentoo [gentoo.org] where SELinux is just one part of it. Other technologies that attempt to make buffer overflows (among other things) very difficult/impossible to exploit is not included in SELinux, nor in Redhat.
Re:Big Deal (Score:3, Informative)
As long as a user can run arbitrary code that opens up network ports and sends data to arbitrary destinations, it will be difficult to completely secure a machine. Per-application egress filtering would go a long way to securing this, but I'm not aware of anything available for Linux that allows you to do so.
Re:Big Deal (Score:2)
Um, SE Linux :)
At least it goes a way towards this. Combined with some good iptables rules (possibly dynamic?) you could get a pretty good system.
Executed mail attachments not having access to add
Re:Big Deal (Score:5, Insightful)
eureka. (Score:2, Funny)
2. Stop releasing OS for free
3. Sell security based OS
4. ?????
5. Profit!
Re:I'm Done With Redhat (Score:3, Informative)
Re:So.... (Score:5, Funny)
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.