Missing packages: Don’t trust external repositories!
If you are in the business of system administration, you know the big dilemma when it comes to installing software: missing packages. Yes, a lot of packages are available in the repositories of your Linux distribution, but not the one you need. Or when it is, it is horribly outdated. So you reach out to external resources, like community maintained repositories, right?
With Lynis, we face this same issue. While most of the distributions have Lynis in the repository, it is often outdated. We could do packaging ourselves, and most likely will in the future. But for now, that task is taking too much time with the regular updates we provide. Packaging, testing, and checking is a delicate process, often better done by people who know that specific Linux distribution from the inside out.
Many software components are facing the same and other people step up to provide community maintained repositories. In this article, we have a look at the benefits, but also the serious risks involved.
The Trust Issue
One of the big problems with external resources is that you have to trust people. People you possibly don’t even know. Every single person is a new line of trust, adding up slightly more risk. That is totally fine, until you have too many “trust relations” going on. It is hard to keep up if everyone in the chain remains trustworthy. Or even worse, if someone in the chain goes bad and malicious activity occurs on purpose. In this case that might be an altered package, or a hacked software repository.
So in any case, you want to trust as less as possible. For those areas you want to trust, you want to have assurance that the people (or companies) involved are doing everything they can to minimize risks and maximize protection.
Why Not Use External Repositories
Depending on your environment, packages maintained by a third party might introduce a new level of risks. For example when your environment is totally build up with RHEL systems, chances are big you need sooner or later an external component. By adding the repository, you might lose support or even face unstable software. There is also a serious risk in inadequate support to keep up with security bulletins. Voluntary repositories often don’t have the resources like the Linux distributions themselves. The only exception of using an external repository might be for official vendor supported software. An example is that of Docker. They have their own build process and release schedule, so they don’t want to rely on all Linux distributions to keep up.
Great, What Then?
The best option is to build some software yourself, especially if you have the intention to roll it out in your whole Linux environment. This gives you the opportunity to decide what versions to use and quickly patch it when needed. By compiling and packaging the software packages, you feel also more responsible for introducing new software components. After all, a healthy barrier will be added, which will avoid you from just installing more and more external software components.
The Way Back
So you might think “great, but I already have those external packages in my environment”. In that case not all hope is lost. Even if you use(d) repositories like those of Dag Wieers or Repoforge, things can be improved step by step:
- Make an inventory of all used repositories
- Craft a list of “alien” packages
- Determine exceptions
- Remove unneeded packages
- Build replacement packages
- Limit access to repositories
So let’s go into more details on how to achieve these steps. The first action is getting an inventory of all used repositories on the systems. Make a shift between the native built-in repositories, and those externally hosted.
Next step is to search for all packages and determine to which repository they belong. Were they being part of the built-in repository, or one of the external ones?
Alien packages
When you have the list of alien packages, it is time to determine which ones are really needed, and the ones which are optional. Everything unneeded should be uninstalled. The remaining packages are for the self-packaging list. Depending on your needs, this list might actually be lower than initially thought. It is common to find the same packages being installed on many systems.
Packaging
Next step is building the packages yourself. The first time it might be a daunting task. The positive news is that usually the external repositories often provide you the source build files. This way you can reproduce what they have done and do it yourself. Use it to build the packages and start testing deployment.
Exterminate
Then finally when everything is done, ensure that external repositories become the past. Monitor your YUM/APT configuration files and block the addition of any new repositories. You might even want to filter them out in your proxy or firewall.
Patch!
Last but not least, keep your own packages up-to-date. Especially network services might be extra vulnerable for attacks from outside. Also implement a software patching plan, in case you didn’t have that yet. Security patches are released on a daily basis, so keep all packages up-to-date.
Conclusion
External packages are often used to overcome the “missing packages issue”. Your favorite repositories might not be hosting them, so external ones are being used. While this might sound as an easy way, it introduces the risk of unstable software, vulnerable or even malicious harmful software.
The best option is limit to official repositories from your Linux distributions and well supported external vendors. They have both the capacity and knowledge to supply packages, as they name is on the line. Don’t trust external resources too much and avoid them as much as possible.
And as usual, it is easy to introduce something, but getting rid of it might be close to impossible. We all those “it is just temporary” installations. Simply do not sacrifice the integrity of your software for convenience. Keep your IT environment healthy, instead of building it on all kind of loose ends and external dependencies.
Stay safe!
