Bug 1793287

Acknowledgments:

Name: Joseph LaMagna-Reiter (SPR Inc.)

This is intentional [1], and the risk was deemed low because the test image should only be used for throw-away containers with short lifetimes.  Now that at least some CI jobs run in 4.3 clusters based on CRI-O [2], we may be able to revert [1] to take advantage of [3].  We may also be able to revert [1] because we are removing our 'ssh' from the teardown container [4].  So hopefully will be able to return to more appropriate creds on the password file soon.  I'll see about nudging those efforts along.

[1]: https://github.com/openshift/origin/commit/ca35cd633a46d2156ef598e827ce230391684926
[2]: https://github.com/openshift/release/tree/2f802eaaa0f8acc47185ad7dbfd7cea289bb42e0/clusters/build-clusters/01_cluster
[3]: https://github.com/cri-o/cri-o/pull/2022
[4]: https://github.com/openshift/release/pull/6854

This is not a CVE.  We should not have removed this code.

Containers that depend on /etc/passwd not being writable are not in our security threat model.

Changing this broke test infrastructure.

I reverted this change in https://bugzilla.redhat.com/show_bug.cgi?id=1813428, see the linked descriptions there.

In a container environment like openshift it is trivial to subvert any part of the filesystem, so no caller may depend on filesystem permissions for anything other than trivial security. Just like mount on the host allows you to subvert the kernel (by replacing locations on disk the kernel accesses), in OpenShift/Kubernetes the ability to specify volume mounts allows you to subvert any process in the behavior.

If a user wants to change the permissions back they can create their own image.

(In reply to Clayton Coleman from comment #9)
> I reverted this change in
> https://bugzilla.redhat.com/show_bug.cgi?id=1813428, see the linked
> descriptions there.
> 
> In a container environment like openshift it is trivial to subvert any part
> of the filesystem, so no caller may depend on filesystem permissions for
> anything other than trivial security. Just like mount on the host allows you
> to subvert the kernel (by replacing locations on disk the kernel accesses),
> in OpenShift/Kubernetes the ability to specify volume mounts allows you to
> subvert any process in the behavior.
> 
> If a user wants to change the permissions back they can create their own
> image.

In regards to the openshift/ose-tests container we can perhaps justify dropping the CVE.

However, at this time we would have to disagree and argue that a writable /etc/passwd file is in fact a CVE. Making the argument that this is an unintended escalation of privileges and in general increases the attack surface of a node. 


We're coming from the other perspective (not a user/admin of OpenShift but consumer), accessing an application such as Jenkins, in the default namespace unnecessarily allows for any process/user in the container to add their own root user to /etc/passwd.

This is an issue because if you can setuid, you are the equivalent of root on the node. Albeit you still have to bypass SELinux and dropped capabilities.


With the latest updates to CRI-O this technique for a writable /etc/passwd for nearly all containers shouldn't be required anymore - unless there are requirements such as testing.

Rejecting this CVE. 

The reasoning is that this is a test image and is used in a throw away/short live container. Additionally, a writable /etc/passwd is required by the test infrastructure.

Closing this flaw. Trackers closed except for 4.4, which seems like it's been added to a RHBA anyway.

Statement:

Red Hat Product Security does not consider this to be a vulnerability. 

This container image is for testing purposes and is used in a throw away/short lived life cycle.  Additionally, a writable /etc/passwd is required by the test infrastructure to function correctly.