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."

Re:45 Seconds?!?!

[c_oflynn]

Its not so bad - the earlier version wasn't designed to be as secure, and this was 1999!! From the article:

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 system was published to would-be hackers and the root had no IP address.

It is a Big Deal

[llouver]

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.

Re:I'm Done With Redhat

[cubicledrone]

Stock price is up 400% in 12 months. Is that successful enough?

Re:Big Deal

[Tim C]

Don't forget the users - most, if not all, of the fastest spreading Windows trojans and viruses of recent years have relied entirely on user-intervention.

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:All PR and no substance. . . .again

[iggymanz]

code audits are just one piece of security testing.....there's plenty of flaws that have been found in all major OS trying to break systems just by throwing different things at it. Being an OpenBSD fan, I see problem found where ICMPv6 on a listened tcp port can crash the 3.4 as version as found on distribution CD. Cracking contests are great for PR, true, but also yet another way to test security. Only relying on code audits is the same as trying to design aircraft by textbook only without ever doing wind tunnel test.

Re:Invulnerable to MyDoom type virii?

[pacman on prozac]

I suppose non-root users can't send e-mail? 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?

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, thats kinda the point of it. They're assuming your box is going to get rooted, and letting you protect it from what root can do to it.

Theres a couple of SELinux demo systems online that let you login as root, one here [gentoo.org]. Yep, anyone, anywhere, given free root, only you can't do anything with it. Normal linux, yep all your arguments stand, bung ACL's on there and its rock solid. Unfortunately its also a royal PITA to run a desktop machine on.

I've not got around to trying selinux yet but was thinking of the posibility of a perl script parsing its error log while its running in non-enforce mode and generating ACL's from that, anyone know if this would be possible? Would certainly make it a lot easier to setup a desktop workstation running SELinux.

Re:Invulnerable to MyDoom type virii?

[drinkypoo]

You don't need to be an administrator to infect NT with MyDoom. However the worm will only run as users who have run it once. It thereafter puts a registry entry in to start it on login.

Re:Invulnerable to MyDoom type virii?

[Spoing]

1. So how does SE Linux protect systems against trojans?

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:Security Enhanced Sure! But...

[dtfinch]

I wouldn't say everything, at least when the hacking has to be done over a network. The chance of having a vulnerability increases with the complexity of the program and the functionality it exposes. But some programs written with security and minimalism in mind have faired very well against hacking attempts.

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.

Too much security for you!

[menscher]

Pardon the "Hackers" joke, but please keep in mind that a Trusted OS (B-level in the orange book) is very different from the standard C-level security we're all used to. While it's good to see linux developing a trusted version, I am concerned about introducing this to the masses. It's going to confuse the heck out of most users, and probably many admins. Up until reading this story I was a strong supporter of Fedora. Now I'm a little nervous.

Anyone care to share their experiences with SELinux?

Re:Invulnerable to MyDoom type virii?

[Pros_n_Cons]

my doom works even if you're not root (admin) "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 viruses?

[skyhawker]

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.

Wrong. The main problem with Windows is that you can't generally log in with two different user ID's at the same time. With Linux or Unix, doing that is trivial. So on my Windows 2000 machine, I normally run with Administrator privileges, while on all my Linux machines, I normally run as a non-prvileged user. If I need to install some software or do some other sysadmin chores, I merely open an xterm and log in as root. No way to do that on Windows 2000 (in general) without logging out of your normal user session. And that's the biggest problem with the Windows design, if you ask me.

Oh -- I might add that I have never been hit by a virus or a trojan on any of my Windows systems, despite running with Administrator privileges, because I don't do stupid things (like use Outlook or Outlook Express to read email), and I keep all my antivirus software completely up to date.

Tienemen misquotes

[bigman921]

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.

Re:Invulnerable to MyDoom type viruses?

[hoeferbe]

Although the Windows 2000 runas command is a step in the right direction, it is a far cry from the ease of "su - root" and "sudo ...". Take, for instance, if I want to change the IP address in Windows 2000, but I'm logged on as a non-admin user. To do this, I have to kill my user's explorer.exe process before starting up a new one (by typing it into Task Manager's "Create New Task" dialog box) as the administrator. Only then can I get to the Network Properties in the Control Panel with the privledges necessary to change the IP address.

Your all wrong

[Findus Krispy]

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.

How to secure a Linux box

[0x0d0a]

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.

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 /etc/rc.d/rcX.d/).

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 /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.

* This isn't a Linux-specific suggestion, but use gpg. Linux is one of the few platforms with free mail clients

Re:Big Deal

[Anonymous Coward]

Other technologies that attempt to make buffer overflows (among other things) very difficult/impossible to exploit is not included in SELinux, nor in Redhat.

But they ARE in the 2.6 kernels

(the buffer overflow protection that is...)

WOOHOO!

[NerveGas]

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