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

pkg/subscriptions: add /etc/crypto-policies/config in fips mode #1667

Merged
merged 1 commit into from
Sep 29, 2023

Conversation

Luap99
Copy link
Member

@Luap99 Luap99 commented Sep 27, 2023

Make sure /etc/crypto-policies/config is bind mounted from the host so it does contain the proper FIPS value and a reinstall of crypto-policies-scripts does not overwrite the existing files with the default config.

Fixes https://issues.redhat.com/browse/RHEL-9836

@Luap99
Copy link
Member Author

Luap99 commented Sep 27, 2023

@mheon @TomSweeneyRedHat @rhatdan PTAL

@mheon
Copy link
Member

mheon commented Sep 27, 2023

LGTM

@Luap99
Copy link
Member Author

Luap99 commented Sep 27, 2023

/hold
I want to do some more changes, the ro mount might break existing workloads that try to change the mode.
It is properly safer to just create tmp file that we mount on top of /etc/crypto-policies/config like we do for /etc/host or hostname.

@Luap99
Copy link
Member Author

Luap99 commented Sep 28, 2023

/hold cancel
PTAL again

@TomSweeneyRedHat
Copy link
Member

LGTM

Source: cryptoPoliciesConfigFile,
Destination: policyConfig,
Type: "bind",
Options: []string{"bind", "rprivate"},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be Mounted R/O?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it is, one can't switch policy to something else.

If it is not, one can, and I don't see why not allow it.

@rhatdan
Copy link
Member

rhatdan commented Sep 28, 2023

SELinux would break writing to this directory anyways, so I don't see mounting the file read/only would be likely to break anything.

@Luap99
Copy link
Member Author

Luap99 commented Sep 29, 2023

SELinux would break writing to this directory anyways, so I don't see mounting the file read/only would be likely to break anything.

Currently the container can write this file, if we now mount ro over it it may cause breakage. But yes you are right selinux blocks access so I have to relabel.

Make sure /etc/crypto-policies/config is bind mounted from the host so
it does contain the proper FIPS value and a reinstall of
crypto-policies-scripts does not overwrite the existing files with the
default config.

We create a tmpfile and write FIPS to it so we can bind mount it and the
contianer can change the config if needed.

Fixes https://issues.redhat.com/browse/RHEL-9836

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
@rhatdan
Copy link
Member

rhatdan commented Sep 29, 2023

SELinux would block the container from writing to this directory, so this would only break users with SELinux Disabled within the contain. I would argue that allowing users to write to this directory should be considered a security problem, since the container could unexpectedly change the security of the host system, And this needs to be changed immediately because it could be considered a severe bug. If users want the container to write to this directory they could add their own volume mount with read/write.

@Luap99
Copy link
Member Author

Luap99 commented Sep 29, 2023

We are not bind mounting from the host, the policy content must be within the container image and of course the container can write to that. The existing bind mount is /usr/share/crypto-policies/back-ends/FIPS (within the container!) to /etc/crypto-policies/back-ends. Thus selinux allows you to write that which well causes the reported problem that the reinstall of the package writes to the dir and changes the policy.

Now my patch adds a mount for /etc/crypto-policies/config so it has the correct value in it and can be changed just like the existing policies dir.

Now whenever the container should be allowed to change the policy is far beyond my understanding of FIPS rules.
Of course if nothing should change it then both mounts must be read only.
However because it is currently possible to overwrite I am not looking to change it with this patch.

If someone thinks that must be changed to ro then please clearly state this on the RHEL bug because that would effect the existing mount as well.

@rhatdan
Copy link
Member

rhatdan commented Sep 29, 2023

Ok if the content is coming from container private storage, then I don't care and you are right the container should be allowed to do whatever it wants with the content.

/approve
/lgtm

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Sep 29, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Luap99, rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 6856d56 into containers:main Sep 29, 2023
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants