Cannot find selinux rules for smart proxy - missing from package "foreman-selinux"?

Problem:

The underlying issue is that in our recent Foreman+Katello 3.9.1 installation we found that the smart-proxy process (systemctl status foreman-proxy) is running in selinux context system_u:system_r:unconfined_service_t:s0. Security tightening requires that no processes should run in unconfined_service_t.

After digging I found out that this is likely because there are no selinux rules present for the smart-proxy, only for the main foreman service. The package “foreman-selinux” does not seem to contain rules for the proxy - and I don’t find other related packages which might contain the selinux rules for the smart-proxy.

I also went to the Github repository for foreman-selinux, and here I do find references to both set of rules - but it looks like the RPM packages built from here only contain the main service rules.

I tried going back in time and did some random sampling on earlier versions of the foreman-selinux package, but I didn’t manage to find one with the proxy rules.

So, am I completely off track and should look somewhere else?

Expected outcome:

The smart-proxy process should not be labeled unconfined_service_t, but maybe foreman_rails_t or foreman_proxy_t or similar (I don’t know the selinux rules well enough to say for sure).

To accomplish that, the foreman-selinux package should contain the rules for smart-proxy as well as some supporting files. Examples:

/usr/sbin/foreman-proxy-selinux-enable (and -disable and -relabel)
/usr/share/selinux/targeted/foreman-proxy.pp.bz2

Foreman and Proxy versions:

3.9.1

Foreman and Proxy plugin versions:

Distribution and version:

I was testing on Rocky 8, but since the expectation is to get the policies from the RPM package, the same issue should be visible on any RPM-based OS.

Other relevant data:

@packaging
I think there is some error in our workflow for foreman-selinux. Looking at the current builds at copr I see both foreman-selinux and foreman-proxy-selinux being build, but when I look at yum.theforeman.org the package foreman-proxy-selinux is not included in the repositories since 2.5 or the other way was last pushed to the repository in 2.4.

When I look at foreman-proxy-selinux from copr it seems perfectly fine.

I can not find a reason for it not being uploaded, so can please someone have a look who is more familiar with this part?

I might be wrong, but I though the smart proxy policy is unmaintained since 2.something?

This could also be a reason, the .te was last updated on Jun 26, 2019. If this is the cause, I missed it so let me know and perhaps I can get some time to look into resurrecting it.

Well, I would of course like it resurrected as it would make my life easier - or at least the compliance part :slight_smile:

I tried searching but so far I haven’t found a policy statement either way about SELinux for the proxy. I also didn’t find anything in the 2.5 release notes stating that SELinux for the proxy was discontinued. On the other hand, the 2.4 documentation (where those rules are present) only mentions package foreman-selinux, not package foreman-proxy-selinux.

Given that there are SELinux rules for the server part and that it should be quite normal to use the built-in proxy with the server, I’d guess that the intention was to have them for the proxy also.

However, I can also see that the proxy might be slightly harder to manage since there are two variants - the built-in proxy and the external proxy. I’m guessing that the SELinux rules would have to be at least somewhat different for those variants.

What makes it difficult is the nature of the proxy with a (possibly) infinite number of features and providers by plugins which could be even custom. But also for this an existing policy as start would be better than none.

Isn’t that the same for the existing rules in foreman-selinux? I think there are more plugins that apply to the non-proxy (main service?) part than to the proxy part. And in both cases there could be custom plugins. Somehow the plugins must be handled today - maybe by leaving it up to the plugin provider to also provide selinux rules?

The external proxy has the extra actions of fetching repository content from master, and of forwarding template expansion etc through the master. That’s why I was thinking that it might require more rules?

And as you said, a place to start from would be a good start :slight_smile: