Forgot your password?
typodupeerror
Red Hat Software Businesses Security

Red Hat to Release Enhanced-Security Linux 326

Posted by timothy
from the compound-modifier dept.
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."
This discussion has been archived. No new comments can be posted.

Red Hat to Release Enhanced-Security Linux

Comments Filter:
  • by Anonymous Coward on Saturday February 07, 2004 @06:43PM (#8214476)
    I think we can bring that baby down without a hack.

    What say you slashdot?
    • But Red Hat's point is that somebody can bring down Slashdot, with a hack. And, were it a race, I dont think /. could bring them down in 45 seconds.
  • by Snake_Plisken (666881) * on Saturday February 07, 2004 @06:43PM (#8214477)
    45 seconds? Sounds liek someone yanked the power cord out of the boxen to do it that fast...
  • 45 Seconds?!?! (Score:3, Insightful)

    by Gunfighter (1944) on Saturday February 07, 2004 @06:43PM (#8214480) Homepage
    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?

  • Security? (Score:3, Interesting)

    by azatht (740027) on Saturday February 07, 2004 @06:44PM (#8214485) Homepage
    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?)
  • by Raster Burn (213891) on Saturday February 07, 2004 @06:45PM (#8214492)
    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?
    • by BoomerSooner (308737) on Saturday February 07, 2004 @06:49PM (#8214531) Homepage Journal
      By not running your mail client as root.
      • by shird (566377) on Saturday February 07, 2004 @06:56PM (#8214581) Homepage Journal
        You should already be running your mail client under windows without admin privs, which achieves the same thing. However:

        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.
        • by pavera (320634) on Saturday February 07, 2004 @07:08PM (#8214659) Homepage Journal
          Wrong,
          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.
          • The same can be done with a securely coded mail client and correct user account under windows.

            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.
          • Stick it in a tgz then, the +x file permissions are preserved. Recent MS virii (viruses, virus`) have done similiar, and it hasnt really slowed them down.
          • by Doktor Memory (237313) on Saturday February 07, 2004 @08:27PM (#8215140) Journal
            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?
            • by Xpilot (117961)
              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?


              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
          • From what I've seen lusers do I'm pretty confident that some people would spend four hours installing dependencies just so they could get the virus or trojan to run.
          • Your all wrong (Score:4, Informative)

            by Findus Krispy (737807) on Sunday February 08, 2004 @02:50AM (#8216849)
            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.
        • Linux is no more secure than windows against trojans

          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
        • Actually the problem is probably worse under Linux than windows. Because of setuid programs, there are a lot more local root exploits under Linux than windows (which has very few, due to no concept of setuid root).

          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.
          • Untrue... it's one of the areas that Windows actually makes itself more insecure because of short sightedness.

            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
        • You cannot say it is no more secure than windows. Linux adds another layer of defense (i.e. the user has to give the trojan a password) This isn't a perfect solution, but don't you agree it's better than nothing?

          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

          • The user does not have to supply the password, the trojan should be able to do all the above without root access.

            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.

        • 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
        • You should already be running your mail client under windows without admin privs, which achieves the same thing. However:

          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
        • It's always assumed that running attachments in Linux is the same as running them from Windows, but that couldn't be further from the truth. In Windows all anyone has to do is double-click the attachment to execute it, but it doesn't work like that in a typical Linux distribution. Even with nothing but the default settings one would still have to consciosly make that attachment into an executable file (ie: chmod +x attachment) and ONLY THEN could that file be executed.

          Now we could go from here into an argu
      • 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.
      • 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."
    • doesn't the MyDoom virus depend on a dope sysadmin clicking on a binary attachment to spread?

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

      --
      We got zips in the wire. Drop all you got on my position.
      • by Tim C (15259) on Saturday February 07, 2004 @07:12PM (#8214688)
        But on a single-user system, what difference does it really make?

        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?
        • 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

          1. 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?

          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

    • by Spoing (152917) on Saturday February 07, 2004 @07:45PM (#8214856) Homepage
      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]

    • Depending on how it is configured, it might actually prevent outgoing connections on port 25 from programs not configured by the installer as mail programs and prevent users from modifying mail programs.

      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.
    • No mydoom doesn't need admin
      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. "
    • But doesn't the MyDoom virus depend on a dope sysadmin clicking on a binary attachment to spread?

      Not really. Two points:

      • In Windows XP everyone defaults to being sysadmins
      • A virus does not need access to other people's files to access our user's address book and mass-mail itself. Though in this case the virus would only be active once the user logs on

      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

  • by Anonymous Coward on Saturday February 07, 2004 @06:45PM (#8214493)
    The last version was defeated within 45 seconds
    That's nothing. I put a stock Windows box on the internet, didn't even bother publishing the IP, and it was cracked within 10 seconds! Take that, open-source advocates, Windows has finally beat you at something!
    • by hendridm (302246) * on Saturday February 07, 2004 @07:38PM (#8214814) Homepage
      Not sure if you're joking or serious, but during the Code Red fiasco I put a Windows machine with IIS online on my cable modem. Thanks to port 80 being forwarded to that machine on my firewall, my computer was infected after I installed Windows in the time it took me to find and install the service pack! From then on, I made sure to remove port forwards before installing updates on newly installed machines :)

      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.
      • That's nothing. I installed MS Desktop SQL Server (comes with Visual Studio) on my machine, explicitly denied it access to the Internet, explicitly denied access to it from the Internet (both in my software firewall), and it was infected with Slammer within 15 seconds of connecting over dialup. I'm dead serious. I guess that something could have deactivated my firewall, but it claimed that it was up.
  • A good thing... (Score:4, Insightful)

    by danielrm26 (567852) * on Saturday February 07, 2004 @06:46PM (#8214501) Homepage
    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.
  • by llouver (579855) on Saturday February 07, 2004 @06:46PM (#8214502)
    "... 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.
    • I think the point about Eclipse was supposed to be that an easy-to-use development platform ``take[s] the development of security off the shoulders of individual corporations and put it in the hands of the community at large.''

      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.

  • What is the most secure Linux setup? SELinux, grsecurity or something else? Should I ignore these and put every daemon in a separate UserModeLinux jail?

    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.
    • I've been toying with the UML jail concept recently, and I must say it looks great on paper. However, the setup and administration can be a real PITA.

    • by Animats (122034) on Saturday February 07, 2004 @07:04PM (#8214632) Homepage
      With mandatory security with levels and compartments going mainstream, we need apps designed to use it properly.

      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.

    • User Mode Linux looks attractive.. In the past, I have used chroot jails to secure any network services that were externally accessible.

      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
  • smart policy (Score:3, Insightful)

    by son_of_asdf (598521) on Saturday February 07, 2004 @06:50PM (#8214533)

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

    • This has been done before (many times, many ways...). Some of this has been said already, but basically, it boils down to a few points:

      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)

    by Eberlin (570874) on Saturday February 07, 2004 @06:50PM (#8214536) Homepage
    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.
    • Or was it a social engineer who managed to call someone and get the root password?

      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

  • I dig engineering/development efforts that come out and dare people to break their 'stuff'. It takes cahoneys to do such a thing and pretty talented developers to back up such a stance. More power to em!
  • by Debian Troll's Best (678194) on Saturday February 07, 2004 @06:57PM (#8214587) Journal
    RedHat's 'trial by fire' approach for their new security policy is a good one, and is something all distro makers should try. Nothing beats having your default security config probed and tested by the world's best crackers in a real life environment. But network security is only one piece of the puzzle. As the Windows community has demonstrated time and time again, trojans and spyware can be just as dangerous from a security point of view as network exploits. And while the problem may not be as severe on Linux due to the separation of the root user from the average day-to-day account, havoc may still be wreaked by a regular user downloading a package and installing it, and thus inadvertently installing a trojan.

    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!

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

      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

      • 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 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
      • Darn, I forgot to include the tidbit that I really *did* want to include, given who you are.

        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
  • by Anonymous Coward on Saturday February 07, 2004 @07:03PM (#8214621)
    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 [attrition.org]. 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 [openbsd.org] 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 [microsoft.com].
    • 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 wi
    • >>>So now Red Hat is using the tired and cliche approach of getting PR by hosting a cracker contest.

      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
  • That is five years ago just so you know.
  • now or later? (Score:2, Interesting)

    by crabpeople (720852)
    if you actually did find a hole, wouldnt it be lot more profitable to wait till the os is deployed worldwide and then exploit it?

    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.

    • Well, given that this is supposed to be a Fedora prelude, and given that Fedora is supposed to be a RedHat ES/AS/WS prelude, I'd say the "bounty" is theirs when they get to market it commercially as "un-crackable".

      Or maybe I'm just cynical.
  • Would you like Security-Enhanced or our regular Shitty-Security product?
  • King of Swamp Castle: When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built in all the same, just to show them. It sank into the swamp. So I built a second one. And that one sank into the swamp. So I built a third. That burned down, fell over, and then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Son, the strongest castle in all of England.

    replace "castle" with "linux distribution" and it almost makes sense.
  • by Coryoth (254751) on Saturday February 07, 2004 @07:36PM (#8214810) Homepage Journal
    Having SELinux security policies the default security set up is a positively excellent idea. I was hoping some distros would do this (hopefully eventually all), but Fedora is a good start.

    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)

    by niko9 (315647) on Saturday February 07, 2004 @07:42PM (#8214833)
    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??

  • by m1kesm1th (305697) on Saturday February 07, 2004 @07:42PM (#8214835)
    from: root@redhat
    to: groups@l33tscript3rs.org
    subject: hack da gibson

    Hackable Server, come hack me plz. IP: 127.0.0.1


  • by Emor dNilapasi (455542) on Saturday February 07, 2004 @07:57PM (#8214932)
    "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.
  • by menscher (597856) <[ude.cuiu] [ta] [todhsals+rehcsnem]> on Saturday February 07, 2004 @08:02PM (#8214965) Homepage Journal
    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?

  • Tienemen misquotes (Score:3, Informative)

    by bigman921 (265507) on Saturday February 07, 2004 @11:14PM (#8215985) Homepage
    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.
  • WOOHOO! (Score:3, Informative)

    by NerveGas (168686) on Sunday February 08, 2004 @01:41PM (#8219105)

    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

Programmers do it bit by bit.

Working...