Red Hat appears to be taking virtualization quite seriously, and they appear to be choosing KVM as their virtualization method of choice. There’s a rather interesting article over at Practical Tech discussing the upcoming virtualization additions to the RHEL 5 line in the next point release. Have a read over the full article at http://practical-tech.com/infrastructure/red-hat-makes-kvm-its-linux-virtualization-of-choice/
Well, as most of you may already know, Red Hat has released RHEL version 5 update 3 today, and they appear to have been quite hard at work. So what can you all expect in CentOS 5.3? Here’s a brief rundown of cool stuff to look forward to:
This is where things get interesting, so hang on.
One thing I’m still waiting to see sorted out is the httpd fiasco on x86_64. In previous releases, you could install both, but it would cause conflicts when run. RH says they fixed this by removing the x86_64 version of httpd from the x86_64 distro. I’m really hoping they mean that they’ve removed the x86 version from the x86_64 distro, and that the release notes just have a nice little heart-stopping typo. Anyone dealing with multi-arch issues might want to keep an eye on this one between visits to the therapist.
Update: Seems the httpd issue was for ppc, though the arch was not clearly spelled out in the release notes. Have a look at http://www.redhat.com/archives/rhelv5-list/2009-January/msg00098.html for information.
You can get the full reading on what’s coming from this url: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Release_Notes/index.html
What features are you looking forward to the most with the new release? I’m curious to see which features people are most interested in using. Let me know in the comments below.
Computer security is once again becoming a hot topic for administrators. There are dozens of new sites springing up around the web, and each is slinging their own ‘Perfect’ setup instructions. They have the usual bell curve of good advice, okay advice, and advice that will effectively leave you with a smoldering pile of rubble where your data used to be. What disturbs me is the growing number of seemingly reputable Linux security websites pitching brittle security advice. I call it ‘brittle’ advice, because while your system is hardened over its previous state, it is also no longer supportable by your distribution. There are several causes for this, but I’ll outline the top three reasons for this breach in support.
Bad Advice:
Really, who didn’t see this coming as the #1 here? Ignoring the occasional typos, misprints and ramblings, there are quite a few security sites which just plain offer bad advice. Much of the advice has to do with offering incorrect permissions changes, which may inadvertently expose data, or cause system breakage. Let’s use a CentOS system here for an example:
SecureCentOS.com (no relation to the CentOS project itself) tells you that the security on /tmp should be secured from the default baseline, and they’re right. They recommend mounting a file in loopback and modifying options there. This is fine. They move on to double check the permissions for your newly created /tmp mount and tell you to chmod it 777. Damn, they were doing so well until they had you do that. The default CentOS permissions, which set the stickybit such that only the user who creates the file can move or delete it. It’s been done with the stickybit in every major linux distro for ages now. Oh well, I’m leaving hope that it’s a typo and that they’ll change their chmod statement to 1777 any day now.
Ignoring Distro Tools
As we descend into flawed-security-advice hell, the next level we come to involves side-lining the distribution provided security tool-kits. This is commonly done through ignorance of their existence or operation, or just basic willful neglect. Regardless of how it happens, the end result remains the same. If you bring your own toys to party, you’re responsible for them. Again looking to CentOS for the example, we find that a large number of websites will completely ignore the security tools default in the distribution. They ignore selinux, aide, audit, and pam restrictions, while touting things like grsec (which may possibly be stagnant, see this announcement), ossec. I don’t want to turn this into a grsec vs selinux holy war ala vim-vs-emacs. Grsec is a good security tool, however it’s not what RHEL and CentOS have chosen to throw their weight behind. Grsec requires a significantly newer kernel than RHEL and centos ship, and this newer kernel can lead to ABI issues with applications or dependency issues for updates. The further you stray from the tools which ship with the distro, the less the distro support mechanisms will be able to help you.
Providing Details
Perhaps the biggest issue I have with supposed security advice is the lack of detail as to what some of the options mean or do. For a rather glaring example, we can use securecentos.com’s page on tuning sysctl.conf. They provide instructions to wget the sysctl.conf file they supply, however they don’t go into detail as to what they set, or what benefits the options provide. Teaching is (or should be) at the core of security. An admin should understand the changes they’re making to a system rather than blindly pecking at keys because someone told them to. To make matters worse, the provided sysctl.conf file doesn’t contain comments explaining the various options there either. A budding admin is going to have no idea what a martian is in terms of linux networking, or why it may be important to have rp_filter enabled. These sorts of things need to be documented to take the voodoo out of security for new admins looking to do the right thing.
With the plethora of poor security advice showing up, and often interspersed with good advice how are admins supposed to know what to listen to? There are a few guidelines to work with so that you keep your system secure, and still get support from your distribution channels. If you stick with these steps, you should be in good shape for having a supportable, secure system.
It’s a near daily occurrence that I see an administrator building something from source because either they fail to understand how backporting works, or they want to install software which isn’t packaged in the default repositories. Source installs used to be common, but the problems inherent in them drove the creation of package management software. Since you have package management software, USE IT! I cannot stress this enough.
Source installs suck for the following reasons:
The benefits of using package management:
Just about every distribution out there has some form of support structure, either via irc, email, forums, or carrier pidgeon. In many cases this community will be able to point you to a location where you can find packages for the software you’re wanting to install. In the case of CentOS, there are a number of very good 3rd party repositories providing quite literally thousands of packages which are not included in the base distribution. By using your distribution’s support mechanisms, you can provide a voice for the users and potentially guide the development efforts for future software releases.
In short, if you need a particular piece of software, please use your distribution’s package management system and if you cannot find a pre-existing package, ASK. If one doesn’t exist, and won’t be created, build a package yourself (there are tutorials aplenty online) and submit it for inclusion. Source installs should only be done when all other options have been exhausted.
Update: Well, since this one seems to have generated some interesting responses, I thought I’d post a couple links that I’d neglected to mention. Thanks to toracat for pointing these out to me, since they fit in perfectly with what we’ve discussed here.
* ,
_/^\_
<>
* /.-.\ *
* `/&\` *
,@.*;@,
/_o.I %_\ *
* (`'--:o(_@;
/`;--.,__ `') *
;@`o % O,*`'`&\
* (`'--)_@ ;o %'()\ *
/`;--._`''--._O'@;
/&*,()~o`;-.,_ `""`)
* /`,@ ;+& () o*`;-';\
(`""--.,_0 +% @' &()\
/-.,_ ``''--....-'`) *
* /@%;o`:;'--,.__ __.'\
;*,&(); @ % &^;~`"`o;@(); *
/(); o^~; & ().o@*&`;&%O\
jgs `"="==""==,,,.,="=="==="`
__.----.(\-''#####---...___...-----._
'` \)_`"""""`
.--' ')
o( )_-\
`"""` `
ascii art taken from http://www.geocities.com/SoHo/7373/xmas.htm#xmastree