compiled from source = bad security practice
Today I saw a ‘how-to’ of what is supposed to be the ‘perfect server‘ setup. Well, the ‘perfect’ was not meant literally, but the setup is in fact very nice – from a functional point of view.
Open source is great, you can learn a lot from looking at the source code of an application, you can even fix a bug here and there, or code in a feature you always wanted. And all for free…
What bothered me with this setup was the excessive amount of custom compiled subsystems to make them all perform in the desired way. To get the system working is a nice achievement, but to keep it running in production would be a nightmare. This is a bad security practice on a binary package based distro, let me explain why.
The applications compiled from source do not integrate with the package manager, and if they do (rpmbuild), it’s just a dirty trick, to compile and build a package to install it. Usually the package is just included in the inventory; versioning is broken, dependencies broken, updates broken…
The administrator would have to track changes to the custom compiled subsystems, pick out the worthwhile updates, and watch for security fixes, patch, compile, reconfigure and test the system while keeping good uptime. That’s not good and you don’t want to do that, unless you are some kind of masochist!
Instead let’s use the resources of the respective distros packaging team. That’s what we have package management for. Use it! Each of the top distros has a dedicated team to keep the packages up-to-date.
If your distro does not natively provide the package you desire, look for optional or 3rd party repositories. Usually your requirements are not that unique, and the application is already prepackaged in one of the optional repositories. There is a good chance that the repositories are maintained well enough, and you’ll have updates available when needed.
Next time when you decide to install something, think – is it also maintainable?
No way is this bad security practice!
For example: Suppose we wish to update a copy of apache. Using compile-from-source, every dependency has to be evaluated in order to upgrade that apache. However, if you use a package manager, do you really know which packages are being updated? Do you know which exploits your system is now vulnerable to? No.
Package managers are great for taking the “hard work” out of updating a system, but they bring a level of dissociation from the fundamentals of system administration that could be allowing systems to be exploited. And certainly the administrator does not know exactly which versions of which packages are on their systems.
I am afraid I have to disagree with you.
Yes package managers abstract the package management to the level that it’s easy to use. And that’s great! Every modern package manager keeps track of version numbers and dependencies for you so really you do not have to. When you want to know what version you have, all you need to do is query the package manager while if you compile from source this would be a lot more trickier.
My point was, do not compile from source, because if you use your distros packaging tool, you are safer in that you will install only tested software and patches which will match dependencies you have already installed while if you manually install from the latest tarball you will have to manually track all the patches and dependencies and everything else down the tree.
To properly track security updates and cherry-pick patches for a stable package branch is not an easy task to do. It gets a lot worse when you have to backport a patch from a different version.
If you want the granular control of knowing exactly what versions of everything you have installed you can still do that with a package manager easily. You’re not giving that away at all. To rest easy you can check a package and its dependency versions and ensure they were correctly updated.