Paranoid Penguin - Security Features in Red Hat Enterprise 4
Keeping your system up to date with the latest security patches is absolutely essential on any Linux system. Red Hat was a pioneer in offering automatic updates when it introduced the combination of the up2date utility and the Red Hat Network service offering several years ago, and this system is even more mature now.
The way this works is that when you set up your Red Hat system (any current version), after the first reboot you're prompted to configure a Red Hat Network subscription. A subscription with an RHN Update entitlement is included with every Red Hat product. When prompted, you simply enter the user name and password you'd like to use (one account can be used to manage multiple systems under the same subscription), and then the subscription number printed on the Activate Your Subscription card that came with your Red Hat installation media.
The net effect of all this (no pun intended) is that you now will have an active subscription to the Red Hat Network service, with a system profile corresponding to your new Red Hat system, which in turn is associated with an RHN Update entitlement that allows your system to check for and download the latest versions of all software packages that are part of the version of RHEL you purchased.
The simplest way to check for and apply security updates is to right-click the icon for the Red Hat Network Alert Notification Tool on your GNOME desktop (it's a glowing red exclamation point if your system isn't up to date, or a blue check mark if it is), and select Check for updates, run up2date and so on, as needed.
You can set up automatic updates by logging on to the Red Hat Network Web site (www.redhat.com/en_us/USA/rhn for US users) with your RHN credentials, clicking on the Systems tab, clicking on your system's profile, clicking Properties and checking the box next to Automatic application of relevant errata (Figure 2). Obviously, you shouldn't enable this feature on high-availability or change-controlled systems, because software patches always have the potential to introduce other bugs or conflicts.
Although the up2date/RHN system is mature and feature-rich (especially for large organizations with the need and ability to pay for network management and provisioning entitlements), as a Linux desktop user, I find it more difficult to use than Debian's apt system (which is more primitive in some ways, but easier to script) or SUSE's YaST Online Update system (which is much easier to configure).
Oddly, as with many other aspects of RHEL, up2date configuration options appear to be spread across multiple GUIs, including the Red Hat Network Web site, unless of course you configure things from a shell (in which case everything you need is in /etc/sysconfig). If you administer Red Hat on servers (that may not even have the X Window System installed, which is always a good policy on hardened systems) or are otherwise command-line-centric, I'm sure up2date and other Red Hat functions are easy to learn. Ironically, I find many of RHEL's GUIs, which are, of course, supposed to simplify things, confusing. (But maybe it's just me!)
As we've seen, RHEL seems to rely very heavily on SELinux for system security. This is hardly a sloppy or mentally lazy design choice; SELinux provides a comprehensive and granular array of mandatory access controls against system users, applications, processes and files. As described in the previous section, the included targeted SELinux policy provides default controls on some of the most commonly used applications.
This default policy's behavior can be tweaked easily using the Security Level applet accessible via GNOME's Application→System Settings menu (Figure 3). The same applet can be used to configure a simple local firewall policy.
The implementation of SELinux in RHEL ES 4 is truly commendable for its simplicity, not to mention the very fact that it's enabled by default. That's the good news; the less-good news is that to create a custom SELinux policy, that is, one that uses tighter or looser controls than the included policy or one that addresses other applications, you're going to have to do some reading. The best place to start is the Red Hat Enterprise Linux 4 Red Hat SELinux Guide, available at www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide.
You'll also probably want to install some extra GUI tools for this purpose, too, namely the setools and setools-gui packages. These packages provide, among other things, sepcut, apol, seaudit and seuserx. For more information on what these tools do and how to use them, see the documents in /usr/share/doc/setools-1.5.1 (the directory name on your system may reflect a different version number).
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development