-
Notifications
You must be signed in to change notification settings - Fork 374
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
Allow oscap-podman to run rootless #1665
Conversation
Running oscap-podman as rootless only requires that we run "podman unshare" at key points to change the namespace. Check if we're rootless, and if so, prepend with unshare.
Can one of the admins verify this patch? |
1 similar comment
Can one of the admins verify this patch? |
Linking to Red Hat Bugzilla 1906849 |
@openscap-ci test this please |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is amazing patch!
Unfortunately, it doesn't work for me, because when I try to scan any profile as a normal user I get every rule evaluated as not applicable. But under sudo
it gives expected results.
For example:
utils/oscap-podman registry.access.redhat.com/rhel7 xccdf eval --profile ospp /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
sudo utils/oscap-podman registry.access.redhat.com/rhel7 xccdf eval --profile ospp /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
The sudo version produces expected results.
utils/oscap-podman registry.access.redhat.com/ubi8 xccdf eval --profile ospp /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
sudo utils/oscap-podman registry.access.redhat.com/ubi8 xccdf eval --profile ospp /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
Again, the sudo version produces expected results.
I'm using podman-2.2.1-1.fc32.x86_64, scap-security-guide-0.1.53-1.fc32.noarch and openscap-1.3.4-2.fc32.x86_64.
What do I miss? Have you experienced similar problems?
|
||
if [ ! -f "$DIR/run/.containerenv" ]; then | ||
# ubi8-init image does not create .containerenv when running podman init, but we need to make sure that the file is there | ||
touch "$DIR/run/.containerenv" | ||
$ROOTLESS_CMD touch "$DIR/run/.containerenv" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the command used in the if condition ([ ! -f "$DIR/run/.containerenv" ]
) also needs to be run with podman unshare
.
Podman's |
Apparently the problem is about determining the applicability. The applicability is determined using RPM check. If the platforms checks are removed from the datastream, it produces some results, but some other RPM results are broken. I guess it has problems with chroot(). As a non-root user it can't chroot but some code parts in oscap require a chroot. I don't know what to do with that, it might be that we will need further changes in oscap. |
Have you tried it with the elevated capabilities binary (used in tests)? |
Yes, but I still get wrong results |
Just letting you know I didn't forget about this, was on break and back today. Thank you everybody for testing this and working on it. |
So, But we sort of stuck with it: https://bugzilla.redhat.com/show_bug.cgi?id=1566985 |
I think that |
Yes, that's likely. However, I can't see any failure in the verbose logs. I would expect to see
|
The BZ https://bugzilla.redhat.com/show_bug.cgi?id=1566985 has been closed as WONTFIX and my understanding is that without that we can't get rid of chroot which blocks using the podman unshare command which means we can't merge this PR. @evgenyz Is my understanding correct? Or is there some other information? |
I'd say that RPM's inability to properly operate without chroot is the most definitive pain in the ass in regard of being rootless. OTOH in theory we can try to replace sudo with elevated capabilities of the binary itself. No sure if it would be a great idea in terms of security though. Edit: meh, we are running in circles here. And the RPM library is the worst offender indeed. We can try and reopen the bug, maybe now it could be possible to fix? |
What should be done with this? Would it make sense to update https://bugzilla.redhat.com/show_bug.cgi?id=1566985 with the new reasoning why we would like to have it fixed? |
All the reasoning falls into the category of pushing for the ability to work with librpm without being root. We can do everything we want (well, almost) if we drop this requirement. I believe the desire to be root/chroot-less was already expressed in the bug, we won't bring anything new. On the other hand I'm not really convinced that we really want to be rootless, because root gives us access to all the data in the system, not only RPMs. We will loose a lot of important information sources without this privilege. Evaluation would be incomplete and inconsistent. I have some ideas about how to tackle this RPM-related rules problems by actually not using the RPM probe (or using it in a limited way). But I'll require some time to dig around before expressing my thoughts on the topic. |
Running oscap-podman as rootless only requires that we run
"podman unshare" at key points to change the namespace. Check if we're
rootless, and if so, prepend with unshare.
This appears to work with both rootless and root modes without issues: