Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
The risks of supply chain attacks on software libraries is well documented, however, I have not seen much on OS packages/dependencies. How important is it to both 1) pin OS dependencies (apt,rpm,etc.) and 2) host them in private repositories?
The same logic would seem to apply as software libraries, but again, most of the supply chain discussion is centered around those and not OS packages.
It is very important to both pin OS dependencies and host them in private repositories. Pinning OS dependencies allows you to control the versions of packages installed on your system and ensure that only the intended versions are allowed. Hosting them in private repositories ensures that you are able to control the source of the packages, which can help reduce the risk of malicious attacks or tampering. Additionally, private repositories can provide an additional layer of security by allowing you to control who has access to the packages and by providing visibility into when and how packages are updated.
To answer your question, it depends on the available resources and how critical role the OS plays in its infrastructure or business.
Hosting OS packages in private repositories has been used in several occasions in order to speed up a company's computers updates and preserving network bandwidth; all updated packages are downloaded to the private repo from the OS repo once (usually during off-hours) and can be downloaded from the private repo several times to the company's computers without causing any disruption to the network's upstream.
Pinning OS package versions has also been used in order to establish OS stability policies. For example, you may want to stick to the current software version for 6 months after a new version of the software comes out; thus, if the new version introduces any defects you won't be affected and you allow time for any issues to be solved before you adopt it.
In terms of security, you can combine the two approaches in order to elevate your overall security; pin the version of packages until you verify that the new versions are (to the extend possible) found to be secure. The new versions can be stored in a private repository where you can run security scanners on them. For the ones that are found to be secure, you can allow them to be installed in the target OSes. This is a very scalable approach that facilitates the management of an OS lifecycle - especially when there are a lot of computers involved.
The reason why it's not a widely adopted practice (especially the private repo part) outside of organizations that are big, handle critical data or their operations require advanced security measures (e.g. intelligence agencies) is that it is much more involved and costs money and time to operate. Small businesses and/or individuals are usually satisfied with trusting the official (public) repos to be secure and have some sort of quality measures in place (that include checking for and reporting security issues); something that, generally speaking, has worked well so far.
They are not really important
This seems an scenario where you have a GNU/Linux distribution, such as Ubuntu or Red Hat.
If a package (e.g. libc) was compromised upstream, and Red Hat packaged it, it would flow to your OS (the classic scenario you have found discussed).
A supply chain issue at the distro would be that the upstream package was clean but the package distributed was not.¹ The possibilities are:
The source code is clean but the compiled version has some malicious code added. The solution for this would be to recompile all packages you use from a trusted system. Reproducible builds want to ensure that third parties are able to compile the same package file as the distro, thus ensuring it corresponds to the published source code, but in many cases we are not there yet. We don't need those if we build all our artifacts, though.
The packager added some evil code to the source (in the build script or a patch), in which case your private builds would produce malicious packages as well. Avoiding this would require you to review the packaging of all packages you use. For each version.
There's also an important yet implicit requisite, which is that you must be able to upgrade packages (at least for security bugs). Otherwise, it would make no sense to pin packages is nothing is ever going to be installed.
Now, let's analyze your proposed solutions:
Hosting the packages in private repositories is useful for reproducibility (e.g. if the official mirrors disappear), but of limited use for security. It may protect you if an existing package gets changed and a machine that didn't have it later needs it installed, but since a package version shall be immutable once created, it's much easier to keep a list of package hashes and yell if an existing package changes its signature.
Note that someone able to change the contents of an existing package and resign the package list to pass the cryptographic validation could as well insert a new version of an existing package so that it will be upgraded. Much more effective (albeit noisier). So you would need to apply the same countermeasures for an evil maintainer (with an honest builder) anyway.
You may consider that your other solution:
protects you from this, but it's actually a can of worms, as it will cause conflicts with the goal of keeping the OS updated. Pinning packages will prevent updating the pinned packages, and it may transitively block others as well. So you actually want to end up upgrading all proposed package, what you need instead is a verification step of all packages that are going to be updated.
So, the main tools to protect your supply chain at the distro level would be to host your own builds and/or reviewing the work of the packagers. Hosting a private copy would be of marginal benefit (although a local mirror can be useful for non-security reasons), and package pinning actually harmful when blocking security upgrades.
¹ In this case as end users it is not relevant whether the maintainer itself was evil or the infrastructure was compromised (including the signing key).
