Security of OpenSCAP daemon features

[mpreisler]

Some parts of the daemon are harmless and we don't have to require root permissions to access it -- for example the CVE scan. Some parts are more or less privilege escalation devices, users can get root rights by injecting content with bash remediations. These remediations can do anything root can do, including giving some particular users root rights. This is obviously something we have to avoid!

These are some ways to solve this:

• The tasks can optionally drop rights before evaluating
  • technically this is very nice, users can evaluate using their own rights
  • unfortunately this is not very useful, most content requires root rights to be usable
• We can split the interface, allow anyone within some group to do all the unprivileged safe stuff and only let root do the dangerous stuff
  • what do we allow in the unprivileged interface besides cve scanning?
• We can require root for everything and then nothing is privilege escalation (this is what we do now)
• Combination of the above

Thoughts? I'd like to discuss this a little before committing to any direction.

@ybznek @baude @isimluk

[mpreisler]

See https://github.com/OpenSCAP/openscap-daemon/blob/master/org.oscapd.conf for more context

[ybznek]

I don't have much experience with issues like that and I don't know how to technically do that...

IMHO the best choice is "optionally drop rights before evaluating " + "allow anyone within some group to do all the unprivileged safe stuff and only let root do the dangerous stuff"

So, root should be able don't use his rights. I think, there is a lot of content which don't require root rights.

[isimluk]

In a first step, I would go for dropping privileges for CVE scan. Afterall it may execute content from the network.

[baude]

The CVE scan of a containers/images does require root privs because it has to mount a thinpool device. So while the scan itself does not need to be technically run by root, there are steps to setup and tear down that would.

[mpreisler]

There are 2 distinct problems we need to solve and I apologize for mixing them up in this thread.

1. Who do we allow to interact with OpenSCAP Daemon via dbus and what do we allow them to do?

• can just root create tasks and change tasks or do we allow that for more people?
• special privileged group?

2. Where do we drop privileges in OpenSCAP Daemon?

• scanning local machine with content that doesn't require root -- this is IMHO very very rare and we don't even have to consider it
• scanning remote machines via oscap-ssh is one obvious case
• scanning virtual machines may be applicable but that depends on configuration
• right now I don't see that many other opportunities to drop privileges

I would like to solve 1) first because it alters the public interface that I want to stabilize.

[isimluk]

On the other hand solving the (2) first, may put some light on (1).

These are all hardish questions anyway. From user perspective, it would be great if the tool mimics the priviledges of the user (including libvirt, ssh-agent, selinux label (like staff_t)). This leads me to think that daemon may want to fork and change identity from root to the user, who scheduled that particular action (requestee). Is this technically possible, is daemon able to authenticate requestee over dbus?

What are your thoughts?