This was a whole month and a bit ago, and I never got around to throwing it here on the site, but I will now announce that I am a Red Hat Certified System Adminstrator!
Even despite the dominance of webmail, I have long used a traditional desktop email client. I like having a local mail archive should “the cloud” have trouble, as well as the ability to exert control over the user interface and user experience. (That might be partly a euphemism for not having to see ads!)
Apple’s Mail.app built into macOS (going to have to get used to not calling it OS X!) has served me pretty well for quite some time now, alongside Thunderbird when I’m on Linux, and while Mail.app offered the most smooth interface for the platform, it didn’t always have all the features I wanted.
For example, being able to run mail rules is more limited than I wanted in Mail.app. I could have rules run automatically as messages arrived in my inbox, or disable them entirely. But actually how I wanted to use rules was to be able to cast my eye over my inbox, and then bulk archive (to a specific folder) all emails of a certain type if I’d decided none needed my fuller attention.
Recently, I moved to Thunderbird on my Mac for managing email and discovered QuickArchiver.
As well as letting you writing rules yourself, QuickArchiver offers the clever feature of learning which emails go where, and then suggesting the right folder to which that message can be archived with a single click.
It’s still early days, but I am enjoying this. Without spending time writing rules, I’m managing email as before, and QuickArchiver is learning in the background what rules should be offered. The extra column I’ve added to my Inbox is now starting to populate with that one-click link to archive the message to the correct folder!
It’s just a nice little add-on if, like me, you (still??) like to operate in this way with your email.
I’m very excited to have put the ideas mentioned in my previous blog post about Cautious Unattended Upgrades into practice!
To quickly recap, the idea is that, on a Debian-based test system (‘the canary’), this is a software package that runs the latest security updates, runs an automated browser-based test suite to make sure these new updates have not broken any critical functionality on our clients’ sites, then ‘pushes’ just these package updates to the production servers.
In keeping with my original plan, the software is written in Ruby and uses Watir/Selenium WebDriver to run a suite of tests that verify, just as a human being would in a live web browser, that client websites work correctly.
I was expecting the biggest challenge would be getting this browser automation side of things working, but actually that proved very easy, which is a testament to the design of those projects.
The software is still a little rough around the edges, as I explain in the README file on GitHub, but I’m very pleased with the project’s progress. We have put it into use on our live systems at Van Patten Media, so we can keep servers promptly up-to-date with security patches without our intervention, but retain a greater peace of mind that our clients’ sites are still working as they should post-upgrade. (This is of course dependent on the quality and breadth of the tests that we write!)
I am particularly excited that this marks the first ‘real’ project in Ruby that I have written. Ruby isn’t a platform I have worked with too extensively before, so I have enjoyed challenging myself to be exposed to a different environment and quickly pick up how to achieve what I want to do. There is definitely more work to do — it really should be organised in a slightly more ‘Ruby-like’ way, and perhaps become a proper Ruby Gem, listed on rubygems.org, so those are things I will be looking at over the longer term for this project.
If you are interested in using Cautious Unattended Upgrades, or contributing to making it better, the project is licensed under a BSD-style licence and the code is available on its GitHub project page.
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!
As long as you remember that SELinux can be the cause of potential unexplained weirdness, your first port of call can be audit2why:
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!
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.
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.
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!
Google Analytics is almost ubiquitous as the solution for collecting useful information about how your website is being used by visitors. It is a good product, and has evolved over the years to be very flexible indeed.
But since it first launched, my opinions of Google have certainly changed, as have many others. Without wishing to get into a debate on the subject, there definitely is a market for a competitor to this very useful tool that might free us of that reliance on Google infrastructure, and be more respecting of our visitors, by means of initatives like Do Not Track.
It might not do enough for your application — but as a way to put your money where your mouth is and genuinely support the user’s right to give and withdraw consent for tracking, it is most definitely worth a look.
I recently completed a physical migration of my server, the one that hosts this very page! It all went successfully, and without any noticeable downtime for this site, which I am pleased to be able to do.
There was, however, a period of time during which this server needed to be physically switched off and moved to the new location. To enable zero downtime, something would need to be able to host the server during that period.
Enter my Raspberry Pi!
This amazing little thing is capable of running Raspbian, a modified version of Debian, which means I get access to the rich library of Debian packages that are available. I have a private Git repository containing a modular set of Puppet manifests. These describe the exact configuration of this server, so by applying the Puppet manifests, I can spin up a new instance of this particular server’s configuration on a whim.
So, I dusted off an SD card that was lying around, dropped Raspbian on it, and installed Puppet and Git and applied the manifests.
If I’m honest, there were a few components that weren’t quite so happy to run, despite packages being available. Varnish didn’t seem to like my VCL file, so I had to run the site here directly with Nginx pointing to PHP-FPM instead.
To cut a long story short, it worked! I was successfully serving up this site, from the Pi, using (almost) my existing configuration. Performance was not stellar, even compared to the modest hardware that normally serves this page, with page load times about 10 times slower than uncached page loads normally would be. The main blog page did take 1.5 seconds to render! For the short time I needed it though, I was very happy to have a very inexpensive and easy solution.
The recent news about the bash vulnerability being called “ShellShock”, and the degree to which it is getting mainstream press has got me thinking about how software vulnerabilities are now being reported in the mainstream media.
Apparently, no vulnerability these days is complete without a catchy name and logo — see Heartbleed and Shellshock! Joking aside, though, the very fact that these vulnerabilities are making non-tech news headlines puts pressure on everyone running potentially vulnerable systems to do their duty — usually as straightforward as running a pre-packaged security update.
The Heartbleed and Shellshock stories are taking the place of what we used to see reserved for particularly influental computer worms, like Sasser and Mydoom. It’s most definitely positive that some vulnerabilities are getting attention — unfortunately it is still the case that for some companies and system administrators, only outside pressure will convince them to promptly, diligently and consistently apply security updates.
What I’d like to see, is some way for people interested in improving computer security, the “good guys” for lack of a better term, to leverage this media interest to send a message to system administrators that it’s always necessary to apply software updates promptly, even when they don’t get on the TV news!
The Curse of The Black Box
The other key issue that Shellshock highlights, as did Heartbleed, is the issue of embedded ‘black box’ systems that might be vulnerable. This kind of system is everywhere — and because in many cases they are ‘set it and forget it’ machines, they represent a particular risk. It’s often very difficult to convince vendors of these systems of the importance of pushing upstream software updates down to end users, particularly when there is a lack of understanding and a lack of financial incentive.
Something big and mainstream, like Shellshock and Heartbleed, might convince system administrators to badger vendors to release patches for this kind of product, but we need to extend this further, and make it a social (or even a legal) expectation on vendors to supply security updates for any product they ship, for a reasonable lifetime period for that product.
The security landscape is too complex, and everything too interconnected, for anyone to have the opinion that “I don’t need to patch that, because there’s nothing important on it”.
Leaving Yourself in the Loop
I want to part with a few bullet points, with some actions I try to take to stay up-to-date. Automatic updates are increasingly common, but not universal, and these simple things can help you not miss a known vulnerability.
- Document and understand the whole software footprint of the systems for which you are responsible. (This means embedded systems, software libraries, and more!)
- Subscribe to announce mailing lists, follow Twitter accounts of the software projects and systems you use. (It pays to be in the know about available updates, and not hear about them after it is too late!)
- Look for useful vulnerability resources for particular projects you use. (For example, for WordPress, the recently launched WPScan Vulnerability Database.)
Back in my earlier Linux days, I would experiment and fiddle a lot with different setups for desktop environments and appearance, customising my Linux system to my heart’s content! An example: I loved the 3D desktop effects of Xgl/Compiz back in 2006.
Time moved on, and I ended up settling with the defaults that distributions provided. I liked Ubuntu’s direction with Unity, upon its release in 2011.
I have fallen out with Ubuntu and Unity more recently, however. The troubling privacy issues with the Amazon ‘lens’ and other changes to their corporate behaviour scared me off.
So, I moved over to Debian for my personal server and my Linux desktop systems, and I have been very happy with it. At the same time, though, I wanted to get back to my previous spirit of playing around with different bits of software instead of just going with the defaults and surrendering to a full-size desktop environment. Frankly, the way I use Linux means I don’t find an overwhelming need for a wide variety of graphical applications.
With that in mind, I have set up a very unusual, and minimalist, desktop experience, which I thought I would document a little here for those that might be interested.
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!