Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

containers-policy.json: provide default config in /usr/ #2157

Open
dustymabe opened this issue Oct 24, 2023 · 6 comments
Open

containers-policy.json: provide default config in /usr/ #2157

dustymabe opened this issue Oct 24, 2023 · 6 comments
Labels
kind/feature A request for, or a PR adding, new functionality

Comments

@dustymabe
Copy link

dustymabe commented Oct 24, 2023

Disclaimer: I didn't know where to file this issue. The containers-policy.json file is provided by the containers-common RPM. There is also a https://github.com/containers/common repo, but this man page also lives in the https://github.com/containers/image repo. Please transfer this around to the most appropriate location.

It would be nice if there could be a configuration split like most software where system defaults are provided by the OS distributor in /usr/ and then overriden by the user in either /etc/ or $HOME/.config.

For example, for containers.conf the man page reads:

Container engines read the /usr/share/containers/containers.conf, /etc/containers/containers.conf, and /etc/containers/con‐tainers.conf.d/.conf files if they exist. When running in rootless mode, they also read $HOME/.config/containers/containers.conf and $HOME/.config/containers/containers.conf.d/.conf files.

Can we provide a similar structure for containers-policy.json where the configuration provided in /usr/ is sufficient for a working system?

One example where this is a problem is running skopeo on a system that somehow doesn't have a /etc/containers/policy.json. I ran into one such case in osbuild/osbuild#1410 where /usr/ gets mounted in from the "host" but /etc/ doesn't.

@mtrmac
Copy link
Collaborator

mtrmac commented Oct 24, 2023

Thanks for your report.

Structurally, as to “where to file this”, we’ve made a mess of things: see #1726 .


WRT the idea itself, I’m generally wary of adding any variability to signature enforcement. Admittedly there already is a precedent in looking for per-user files, and the /etc vs. /usr thing is a reasonably established pattern…

I ran into one such case in osbuild/osbuild#1410 where /usr/ gets mounted in from the "host" but /etc/ doesn't.

… but I don’t see this as a strong argument; there are infinite ways to create a broken system.

Actually, “the policy file got somehow lost” is exactly a good reason to “fail closed” and not fall back to some other policy. The default policy in /usr would, I think, have to be pretty permissive (maybe restricting repositories where the OS provider ships code, to be signed by keys from that OS provider) — so falling back from a site-wide strict policy to the built-in fairly permissive one could be a problem.

@dustymabe
Copy link
Author

maybe restricting repositories where the OS provider ships code, to be signed by keys from that OS provider

That's what we do today. We (the OS provider being Fedora/Red Hat) ships:

    "transports": {
        "docker": {
	    "registry.access.redhat.com": [
		{
		    "type": "signedBy",
		    "keyType": "GPGKeys",
		    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
		}
	    ],
	    "registry.redhat.io": [
		{
		    "type": "signedBy",
		    "keyType": "GPGKeys",
		    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
		}
	    ]
	},

but we ship it in /etc/ and not /usr/ like we probably should.

I guess there's another argument to make here being that the keys referenced in that config are also in /etc/.

@mtrmac
Copy link
Collaborator

mtrmac commented Oct 24, 2023

Yes, but if that file is “lost” then we don’t fall back to any other policy, we just fail and force the user to provide a policy.

(Admittedly if the user sets up the policy with something valid but not what was intended, there is no way for policy consumers to tell — and I don’t have a strong argument that “forgot to provide a policy” is a more important failure case than “provided the wrong one”. But still, if we can’t do better in some cases, I don’t think that means we should give up on doing better in other cases.)

@dustymabe
Copy link
Author

Thanks for the discussion.

@mtrmac
Copy link
Collaborator

mtrmac commented Oct 25, 2023

I very much appreciate the irony that just filing a “also read from /usr” issue without more justification would probably have had a smoother path; and that adding a real-world use case is what triggered my “oh, wait, this is actually good not to do” reaction.

I don’t really know what’s the best path forward here. It’s definitely valuable to have an issue filed, so that the decision can be centralized and tracked.

@rhatdan
Copy link
Member

rhatdan commented Oct 25, 2023

I think we should move the c/i config files to usr and overrride in /etc for consistency, and then users can just blow away /etc/ to get back to default configuration.

@mtrmac mtrmac added the kind/feature A request for, or a PR adding, new functionality label Oct 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A request for, or a PR adding, new functionality
Projects
None yet
Development

No branches or pull requests

3 participants