Effraction by Sébastien Launay on Flickr. Licensed under CC-BY 2.0.

My attention has turned recently to how to automate the installation of security updates on various Linux distributions.

As Van Patten Media runs more servers, the effort and time needed to apply critical security updates promptly grows. Waiting several days to get security fixes just isn’t acceptable in a post-Shellshock era, yet there is always a risk of a completely automated update breaking important functionality.

One of the projects I will be investigating over these few weeks is how we might build an automated test environment that could apply the updates quickly to a test VM, run a test suite to verify none of our critical client functionality breaks, then push those updates to the live servers.

There are various solutions for truly automatic updates; I focus on Debian’s unattended-upgrades package here. What seems to be more difficult, however, is being able to push that list of ‘approved’ packages and just install those when we are ready.

My current train of thought on how to proceed on this is as follows:

• Test box installs the day’s upgrades
• Runs the test suite automatically
• If the test suite passes, it determines which packages were most recently installed
• Pushes that/those package names to the unattended-upgrades whitelist on the clients
• Clients, on next unattended-upgrades run, will install those upgrades
• Upon successful upgrade, we reset the whitelist

I am in the very early stages of looking at this, so that is a very rough sketch of where my thoughts are currently. There are missing pieces, but I was looking at Watir for the browser test suite component.

I would be interested to hear from anyone who has looked at this before, or if anyone knows of any interesting similar projects I haven’t found!

Security Enhanced Linux (SELinux) is a pretty powerful technology that adds another layer of access control to a Linux system. It helps significantly limit the ability for an attacker who has partly compromised a system to use their access to jump deeper into the system.

It has been standard in Red Hat Enterprise Linux and its derivatives for quite some time, and is often the cause of many a headache when something doesn’t work because it is being (apparently) silently blocked by SELinux’s security enhancements!

Its potential to cause breakage, especially when third-party bits and pieces are brought into the mix, means the advice from well-meaning individuals is often a cry of “just turn off SELinux!”, rendering a system without that extra layer of protection.

I will not pretend that my recent dealings with SELinux in CentOS 7 have been free of frustration, but a few simple tools have made it a surprisingly simple affair to get something up and running again if a particular behaviour (always of something a bit third-party in my experience!) is being erroneously blocked.

I think a big part of what makes SELinux get switched off in frustration is the perception that it is breaking things silently, and the psychological impact of its verbose ‘scariness’ when you do find those logs!

audit2why

As long as you remember that SELinux can be the cause of potential unexplained weirdness, your first port of call can be audit2why:

audit2why -a

What is particularly nice about this tool is how quickly you get (semi-)human readable output, detailing which rules an application is breaking. If you do hit one of these ‘weird problems’, a quick trip to this tool usually makes it clear that SELinux is the cause of the failure!

audit2allow

I was surprised by how relatively quick it was to identify an issue with audit2why and make a custom module with audit2allow to get an application working again.

There are a good set of instructions in the Red Hat manual.

It sounds like a big deal, but the tools have made it almost completely automated — it really isn’t necessary to have a deep understanding of SELinux’s internal workings.

setsebool

Finally, there are some flags that are disabled by default for SELinux protected applications that you might need. Again, audit2why will often make it clear what you need to toggle using this tool!

For example, a web server process that does legitimately send out emails might need the appropriate flag switched on. Without it, the web server doesn’t get the right to talk to sendmail.

Give SELinux Another Chance!

I suppose my point in this rambling is this: give SELinux a chance if you have given up on it in the past. If you have the time to set up your system properly (and you should!), taking a little extra to figure out how to grant only the permissions really needed does make a material difference to your security should one application be compromised. An attacker being able to get their foot in the door needs to be assumed to be possible, so making their life a lot harder at that point is worth making your life slightly harder on the odd occasion.

With a little patience and the use of the tools I have talked about, I think it is a lot easier to work with than it might seem at first glance, or when it first arrived in RHEL many moons ago!

Following on from my previous video, showing how to install PHP 5.5 on CentOS 6, I now complete the tasks needed to meet the requirements for installing Moodle 2.7 on CentOS, and replace the Oracle MySQL distribution with MariaDB 5.5.

As always, feedback is appreciated!

I have been inspired once again to fire up my screencasting rig, to show you how to install PHP 5.5 on CentOS 6 using Rackspace’s IUS Community Repositories.

More and more web applications now are likely to require versions of PHP beyond 5.3. CentOS 6 users are stuck with 5.3, with backported security updates, unless they diverge from standard repositories or compile PHP themselves! Until CentOS 7 is with us, those of us trying to run a rock-solid web server on CentOS will be left out in the cold running recent web applications like Moodle 2.7 which require a newer PHP.

In this video, I show you how to use the IUS repositories to get PHP 5.5 running. These repositories, with their Rackspace backing, seem likely to be nice and stable going forward.

As always, I’d love any feedback you might have.

It has been far too long since a video tutorial made its debut here, so I would like to introduce a new tutorial!

Cacti is a great graphing and monitoring tool, but I have struggled in the past with getting it installed, and getting it to do what I want. It can be a little bit complex and fiddly, but recently I have had more success and am putting it to good use measuring and graphing more things.

In this tutorial, I will walk you through installing Cacti on a basic CentOS 6 system with Apache, PHP and MySQL already installed. By the end of the video, it is collecting information for the default graphs in the default installation.

I hope to extend this video series soon with some details about the additional graphs I have recently succeeded at getting installed.

As always, your comments and feedback are appreciated!

My server (and subsequently this site) is going to be down tomorrow between 10:00 AM and 1:00 PM GMT, for scheduled maintenance. Basically a clear out the cobwebs (which is scarily literal) job, and the opportunity to double-check that everything hardware-wise is hunky-dory. Also I’ll be doing a couple of special backups so I have even higher levels of redundancy, while I get the opportunity of the server being down.

See you on the other side.

UPDATE: Completed successfully, and I didn’t break anything.