OpenSCAP
Allow oscap-podman to run rootless
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:
$ wget -O - https://www.redhat.com/security/data/oval/v2/RHEL8/rhel-8.oval.xml.bz2 | bzip2 --decompress > rhel-8.oval.xml
$ podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.redhat.io/ubi8 latest 33df2983b061 5 weeks ago 208 MB
$ /usr/bin/oscap-podman-rootless 33df2983b061 oval eval --report vulnerability.html rhel-8.oval.xml
Definition oval:com.redhat.rhsa:def:20205237: false
Definition oval:com.redhat.rhsa:def:20205236: false
Definition oval:com.redhat.rhsa:def:20205146: false
Definition oval:com.redhat.rhsa:def:20205100: false
Definition oval:com.redhat.rhsa:def:20205085: false
Definition oval:com.redhat.rhsa:def:20204952: false
- - - - 8< - - - -
Definition oval:com.redhat.rhba:def:20194268: false
Definition oval:com.redhat.rhba:def:20193674: false
Definition oval:com.redhat.rhba:def:20193384: false
Evaluation done.
$ head vulnerability.html; echo "- - - - 8< - - - -"; tail vulnerability.html
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
Color mapping
Result enumeration
Class |t|f|u|e|na|ne|
compliance |G|R|B|Y|- |- |
inventory |-|-|B|Y|- |- |
misc |-|-|B|Y|- |- |
- - - - 8< - - - -
<tr class="resultgoodB">
<td class="Text" align="center">oval:com.redhat.rhba:def:20193384</td>
<td class="Text" align="center">false</td>
<td class="Text" align="center">patch</td>
<td class="Text" align="center">[<a class="Hover" target="_blank" href="https://access.redhat.com/errata/RHBA-2019:3384">RHBA-2019:3384</a>], [<a class="Hover" target="_blank" href="https://access.redhat.com/security/cve/CVE-2019-8320">CVE-2019-8320</a>], [<a class="Hover" target="_blank" href="https://access.redhat.com/security/cve/CVE-2019-8321">CVE-2019-8321</a>], [<a class="Hover" target="_blank" href="https://access.redhat.com/security/cve/CVE-2019-8322">CVE-2019-8322</a>], [<a class="Hover" target="_blank" href="https://access.redhat.com/security/cve/CVE-2019-8323">CVE-2019-8323</a>], [<a class="Hover" target="_blank" href="https://access.redhat.com/security/cve/CVE-2019-8325">CVE-2019-8325</a>]</td>
<td class="Text">RHBA-2019:3384: ruby:2.5 bug fix and enhancement update (Moderate)</td>
</tr>
</table>
</body>
</html>
Podman's unshare is a very specific technique that might be not the only thing we need and maybe not in this exact way.
https://www.redhat.com/sysadmin/rootless-podman-makes-sense
What do I miss? Have you experienced similar problems?
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, chroot again. Or, our not exactly correct usage of it because of the way librpm handles root directory override (and it is the only reason for chroot ATM, we were (or could be) able to replace everything else).
But we sort of stuck with it: https://bugzilla.redhat.com/show_bug.cgi?id=1566985
Have you tried it with the elevated capabilities binary (used in tests)?
Yes, but I still get wrong results
I think that podman --unshare interferes with chroot capabilities.
I think that
podman --unshareinterferes withchrootcapabilities.
Yes, that's likely.
However, I can't see any failure in the verbose logs. I would expect to see chroot failed in the logs. But I can see
* Switching probe to PROBE_OFFLINE_CHROOT mode.
* I will run rpminfo_probe_main
* Package .... not found.
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?
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.