Security and privacy: Do you know what's lurking on your system?

I had a fascinating job once that involved designing hardening procedures for systems we were going to use for security-related projects. This was probably 15 years ago, and not only were guides a little thin on the ground for the Linux distribution I was using, but what we were doing was quite niche. At first, I think I'd assumed I could just write a script to close down a few holes that originated from daemons¹ that had been left running for no reasons: httpd, sendmail, stuff like that. It did involve that, of course, but then I realised there was more to do and started to dive down the rabbit hole.

So, after those daemons, I looked at users and groups. And then at filesystems, networking, storage. I left the two scariest for pieces last, for different reasons.

The first was the kernel. I ended up hand-crafting a kernel, removing anything I thought was unlikely we'd need, then restarting several times when I discovered that the system wouldn't boot because the things I thought I understood were more … esoteric than I'd realised. I'm not a kernel developer, and this was a salutary lesson in how skilled those folks are. At least, at the time I was doing it, there were less code and fewer options than there are today. On the other hand, I was having to hack back to a required state, and now there are more cut-down kernels and systems to start with than there were back then.

The other piece I left for last was pruning the installed operating system applications and associated utilities. Again, there are cut-down options that are easier to use now than then, but I also had some odd requirements—I believe that we needed Java, for instance, which has, or had …. well let's say a lot of dependencies. Most modern Linux distributions³ start off by installing lots of pieces so you can get started quickly without having to worry about trying to work out dependencies for every piece of external software you want to run.

This is understandable, but we need to realise when we do this that we're making a usability/security trade-off.⁵ Every utility, every library, every executable you add to a system increases your attack surface and the likelihood of vulnerabilities.

The problem isn't just that you're introducing vulnerabilities, but that once they're there, they tend to stay there. Not just in code that you need, but, even worse, in code that you don't need. It's a rare but praiseworthy hacker⁶ who spends time going over old code and removing dependencies that are no longer required. It's a boring, complex task, and it's usually just easier to leave the cruft⁷ where it is and ship a slightly bigger package for the next release.

Sometimes, code is refactored and stripped: most frequently, security-related code. This is a very Good Thing™ but it turns out it's far from sufficient. The reason I'm writing this post is because of a recent story in The Register about the beep command. This command used the little speaker that was installed on most PC-compatible motherboards to make a little noise. It was a useful little utility back in the day but is pretty irrelevant now that most motherboards don't ship with the relevant hardware. The problem⁸ is that installing and using the beep command on a system allows information to be leaked to users who lack the relevant permissions. This can be a very bad thing. There's a good, brief overview here.

Now, beep isn't installed by default on the distribution I'm using on the system on which I'm writing this post (Fedora 27), although it's easily installable from one of the standard repositories that I have enabled. Something of a relief, though it's not a likely attack vector for this machine anyway.

What, though, do I have installed on this system that is vulnerable and I'd never have thought to check? Forget all the kernel parameters that I don't need turned on, but that have been enabled by the distribution for ease of use across multiple systems. Forget the apps I've installed and use daily. Forget even the apps I installed once to try and neglected to remove. What about the apps that I don't even know are there, and that I never realised might impact the security posture of my system? I don't know and have little way to find out.

This system doesn't run business-critical operations. When I first got it and installed the operating system, I decided to err toward usability and be ready to trash⁹ it and start again if I had problems with compromise. But that's not the case for millions of other systems out there. I urge you to consider what you're running on a system, what's installed on it, and what you really need. Patch what you need, remove what you don't. It's time for a spring clean.¹⁰

1. I so want to spell this word dæmons, but I think that might be taking my Middle English obsession too far.²

2. I mentioned that I studied Middle English, right?

3. I'm most interested in (GNU) Linux here, as I'm a strong open source advocate and because it's the operating system I know best.⁴

4. Oh, and I should disclose that I work for Red Hat, of course.

5. As with so many things in our business.

6. The good type or I'd have said "cracker," probably.

7. There's even a word for it, see?

8. Beyond a second-order problem that a suggested fix seems to have made the initial problem worse…

9. Physically, if needs be.

10. In the Northern Hemisphere, at least.

This article originally appeared on Alice, Eve, and Bob – a security blog and is republished with permission.