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."
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.
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.
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
Looking forward to Fedora Core 2
(follow this thread) Re: Proposal: Discourage rpmbuild --sign
The main SE Linux site
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
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
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.
Anyone care to share their experiences with SELinux?
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