According to sources close to the company, the release is planned for 14 February to coincide with the LinuxWorld conference in Boston. A UK spokeswoman from Red Hat was unable to confirm the release date on Monday.
Red Hat has previously indicated that Red Hat Enterprise Linux 4 would be based on version 2.6 of the Linux Kernel. A beta version of the product, released in September 2004, was based on the Linux 2.6 kernel. The current version, Enterprise Linux 3, supports some features of the 2.6 kernel, but its kernel core is based on version 2.4.
Adding full support for the updated kernel should allow the operating system to run file systems of more than one terabyte and improve the performance of the input/output subsystem.
Rival Linux distributor Novell has already incorporated the 2.6 kernel into SuSE Linux Enterprise Server 9, which was released in August 2004.
Mark Cox of Red Hat security response team told ZDNet UK last summer that Red Hat Enterprise Linux 4 will also include security enhancements derived from the US National Security Agency's Security Enhanced Linux (SELinux) project.
Cox explained that SELinux "segments programs completely", so a bug in one application cannot be exploited to modify other applications. Users are responsible for setting up the policy files for each application. "You need to create the policies and configure them, which some people won't do," said Cox.
SELinux cannot provide any protection against flawed software that is running as a root user, according to information on Red Hat's Web site.
Talkback
Strange, the article states states that SELinux canät protect you from misbehving applications runnig as root. I wonder what Red Hat have done to get that behavior. Normally iin SELinux it doesn't matter what user you are, the security policy is everything. E.g if I have some kind of sofware that misbehaves in a way that it elevates iits priviledges too root SELinux would kick in and I would only run the default security role for root. By haming very few privileges in that securyty role such problems could be avoided.
There is of course notheng to prevent harmful things in some roles of root. But that would normally require some user intervention like typeing a password.
There is of corse the risk that SELinux in it self gets hacked, but that is a separate sysem from the normal Linux permissions, so I you would probably need tow hacks to manage that.
Either the auther doesn't understand the info on the Red Hat site, or they have configured it extremely stupid by default.
That's right. The SELinux policy in RHEL4 is what they call a "targeted policy" which is designed to be less complicated to manage. Instead of having a "deny all" default policy (similar to default policies in firewalls), it's an "accept all" policy to which further restrictions are added. At least, that's my understanding. It's going to be difficult enough for SELinux newcomers to figure out, so it's probably best that they use a targeted policy since most sysadmins aren't SELinux gurus yet. One can, at least with the latest Fedora Core, switch to a strict (deny all) policy by changing just one line in a config file, so it's there if someone wants to turn on full enforcement.
> SELinux cannot provide any protection against flawed
> software that is running as a root user, according to
> information on Red Hat's Web site.
should probably be:
| RHEL4's default SELinux policy provides complete
| protection for network-facing applications that
| could be running as a root user.
|
| RHEL4's default SELinux policy does not provide any
| protection against arbitrary flawed software that is
| running as a root user, according to information on Red
| Hat's Web site.
Russell Coker, http://www.linuxjournal.com/article/7955 :
> The "targeted" policy which is in Fedora Core 3 and will
> be in Red Hat Enterprise Linux 4 solves this. It restricts
> only the daemons that are at most danger (network
> facing daemons initially but as we progress we will add
> other daemons to the list). This stops quite a number of
> attack vectors while having no restrictions on users
> who login to the system. Of course this means that
> targeted policy doesn't prevent a local user from
> attacking the system, but that is a trade-off that the
> administrator can make for ease of use.