search

openSUSE / ca-certificates

Utilities for system wide CA certificate installation
GNU General Public License v2.0
24 stars 21 forks source link

Make certbundle.run container friendly #8

Closed stefannica closed 3 years ago

stefannica commented 3 years ago

Running containerized services and applications in the context of privileged users is a practice highly discouraged. This creates a problem, given that said services and applications also require a runtime container initialization stage during which container-wide configuration changes are made, some of which include installing custom certificates.

To solve this problem, some prefer using non-privileged user to install custom certificates, which in the context of ca-certificates requires changing the ownership of the /var/lib/ca-certificates folder and running update-ca-certificates as a regular user. However, not all of the ca-certificates scripts are designed to be executed by a regular user.

This commit makes changes to the certbundle.run script to allow it to be executed as a regular user (i.e. its previous form runs into errors because newly created files have 444 permissions and a regular user isn't allowed to modify them without explicitly setting the owner write permission bit.

lnussel commented 3 years ago

So the fix is actually the mv -f rather than moving the code around?

stefannica commented 3 years ago

So the fix is actually the mv -f rather than moving the code around?

@lnussel mv -f is just half of the fix. The other half is to avoid having to modify $certfile.new after its initial creation, because it's created read-only due to the global umask 222 and as you know regular users aren't allowed to modify read-only files. There are other ways to fix this, like changing the umask only for this particular code block or running a sub-shell, or changing permissions temporarily, but they all look really "ugly" in comparison with the current approach.

lnussel commented 3 years ago

Doesn't seem to hurt so ok. You your case seems very fishy though. Allowing unprivileged users to mess with /var/lib/ca-certificates is crossing boundaries. If you want to create a compat cert store as user it should be stored somewhere else.

stefannica commented 3 years ago

Doesn't seem to hurt so ok. You your case seems very fishy though. Allowing unprivileged users to mess with /var/lib/ca-certificates is crossing boundaries. If you want to create a compat cert store as user it should be stored somewhere else.

@lnussel yes, I agree, it is fishy. Certificate management in the context of containers - kubernetes containers in particular - is an area poorly explored so far. For kubernetes applications, there are additional restrictions that make it difficult to find both simple and safe solutions to this. On one hand, running containerized commands/processes as a privileged user is highly discouraged, for obvious security reasons. On the other hand, custom certificates still need to be installed at runtime in containers and used by containerized applications. Until someone comes up with a better idea, people will either keep running those container initialization commands as root, in spite of recommendations, or use the approach I mention in this PR: changing the cert paths ownership and running the cert update script as a regular user.