Ignore security.ima xattrs #1608
Conversation
Fixes: containers/podman#18543 Signed-off-by: Daniel J Walsh <[email protected]>
|
containers/buildah#2127 explicitly wanted them to be copied, although it is not exactly clear to me if this was only ever used as root. It may be better to only skip it as rootless if it doesn't work rootless. |
|
I don't think we should ignore them. To address the specific issue, we can skip these xattrs when we copy the catatonit executable, but not in general |
|
The thing is that you need root privileges to be able to copy IMHO, rootfull should fail in case of error; rootless might issue a warning, but pass. While |
|
So we need to drop the attributes when pulling and running a container rootless (because we can’t se the attribute rootless), but we must not drop when pulling and building a derived image (because they are a required part of the built image)? One immediate difficulty is that often, at times of a pull, we don’t know whether that image is going to be run or built upon. Another is that many builds involve running containers on that image, i.e. rootless is just in an impossible situation that must fail if we store the attribute natively. Do we need to think about “virtualizing” the extended attribute, recording it in some c/storage metadata but not on the kernel-visible backing filesystem? That would at least allow us to take an image with IMA attributes, make a small change (edit a config file), and push that build image, rootless. For full rootless builds, including things like |
|
How about we add a flag indicating whether or not you care about IMA labels. Default to fail as we do now. But allow users to set list of ignores. Move the list of ignored XAttrs to storage.conf, default to selinux. |
|
Yes, that would work. I suppose for the |
for that specific case we don't care about IMA at all. We only need a known binary that can keep the infra container alive. We are using catatonit because it is the only static binary we can be sure about, but it could be anything. Maybe once wasm is more available, we can replace it with a hardcoded wasm payload, so that it is 1) static 2) works on all platforms. |
|
Do we have the option of not caring about IMA if the kernel is configured to enforce it? Or is that something that just doesn’t work and isn’t worth worrying about? |
This exists today in tar-split right? |
The tar headers, which describe everything about the layer except the contents of non-zero-length files, are preserved so that we can reconstruct the uncompressed version of the layer diff, but that's pretty much all we can do with it, since it's not stored in a seekable format. |
|
Ah, right. So what ostree does related to this topic is use an But the equivalent would be storing the tar-split header as a EDIT: Though this is tricky because tar-split is also serializing the order of files and exactly how their names appear in the tar stream, so we'd still need to save that out of band. |
|
BTW related to this, and definitely related to the existing flow where And On the client side we deserialize these back. So basically every ostree feature related to xattrs (which also includes IMA) works, even when transporting container images around. |
Hold up, are you saying that xattrs are not present in tar headers in layer diffs that ostree creates? |
Yes; I didn't trust that we could reliably get the |
That information needs to also be in the headers, though, so that containers/storage can decide whether or not to apply it to layer content that it's extracting. The alternative is binaries like |
So far though, there hasn't been a real use case to execute file-capability binaries inside an ostree-container base image. The use case for running these as a container e.g. with podman/docker is solely to use them as a "build environment"; and there's no sane use case for running any file capabilities there - it doesn't even work outside of a privileged container (or at least The other problem strongly related to this is that in a default unprivileged Containerfile/Dockerfile style build flow, we don't allow the build process to set some of these critical xattrs because the process inherently conflates build environment == target environment. Trying to set e.g. So use of these xattrs in container image flows (outside of base images built externally or at least with a src != target style flow) is uncommon in my experience. Ultimately what we may want is a way to "remap" xattrs in overlayfs more natively. What would actually be nice is that the default of |
I won't try to enumerate all of the ways that file capabilities could be made relevant at run-time. I can confirm that we've had a bug report about |
Yes...but here's the thing; the file capability xattr i.e. It's also interesting to note here that for rpm (and what spawned this bug report) is that rpm doesn't treat
I think everyone roughly agrees on this...but the problem is we need to decouple 3 things in the general case:
(Decoupling the first two is the biggest fix) |
Fixes: containers/podman#18543