New Package Request: selinuxd

[jhrozek]

This ticket is a follow-up or a branch of openshift/enhancements@9984669#r645083951 As said in that thread, it is not absolutely required that the package is part of the OS, but I do think it would be beneficial. In that thread, @travier said that he'd like to see a demo and I'll be happy to provide one, just let me know in what form (should I join some meeting? Record something in e.g. asciinema along with a write-up? ...)

Please note that selinuxd is not packaged in Fedora at the moment, although there's nothing inherently preventing it. We're trying to find a suitable home for selinuxd at the moment.

Please try to answer the following questions about the package you are requesting:

1. What, if any, are the additional dependencies on the package? (i.e. does it pull in Python, Perl, etc)
   No python or perl, selinuxd is written in go. The full list dependency list is:

ldd ./bin/selinuxdctl
        linux-vdso.so.1 (0x00007ffe9f7f5000)
        libsemanage.so.1 => /lib64/libsemanage.so.1 (0x00007fd51cceb000)
        libsepol.so.1 => /lib64/libsepol.so.1 (0x00007fd51cc38000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd51cc16000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fd51ca4c000)
        libaudit.so.1 => /lib64/libaudit.so.1 (0x00007fd51ca1a000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fd51c9ed000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fd51c9d8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd51cd55000)
        libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007fd51c9d0000)
        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fd51c937000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fd51c930000)

2. What is the size of the package and its dependencies?
   My local build of the binary is 14MB. The dependencies above come from the following packages:

• libsemanage (311786)
• libsepol (765232)
• glibc (17293431)
• audit-libs (312564)
• bzip2-libs (79024)
• libcap-ng (55718)
• pcre2 (641128)
• policycoreutils (705735) (which itself depends on cracklib, diffutils, gzip, libselinux-utils, libutempter, shadow-utils, util-linux).

3. What problem are you trying to solve with this package? Or what functionality does the package provide?
   Custom SELinux policy management for containers, in particular in the context of OpenShift. While it is possible at the moment to set custom policies for containers, the management is not practical - the admin needs to log in to the node and call semodule -i to install the policy.
   selinuxd watches the /etc/selinux.d directory for files and installs any selinux policies dropped there, so all that is needed is to drop the policy file there. There is also a very simple REST API to query the installed modules and get information such as any error messages that were generated when a policy was installed.
   In the OpenShift context, the idea would be to drop the selinux policy file to the nodes with a MachineConfig (hopefully in the future without a node reboot) and then selinuxd would install the policy.
   Also note that selinuxd is used by the Security Profiles Operator that is currently being proposed to be added to OpenShift.

4. Can the software provided by the package be run from a container? Explain why or why not.
   Yes, it can. Having the daemon on the node has the benefit of allowing to install policies before nodes start up -- in the OpenShift context, this means e.g. containing the static pods.

5. Can the tool(s) provided by the package be helpful in debugging container runtime issues?
   Indirectly maybe? I think the REST API provides a nicer way of debugging which SELinux policies are installed over having to ssh to the node and run semodule

6. Can the tool(s) provided by the package be helpful in debugging networking issues?
   No

7. Is it possible to layer the package onto the base OS as a day 2 operation? Explain why or why not.
   Yes, this is not an inherent OS feature, but an add-on.

8. In the case of packages providing services and binaries, can the packaging be adjusted to just deliver binaries?
   There's a single binary called selinuxdctl

9. Can the tool(s) provided by the package be used to do things we’d rather users not be able to do in FCOS? (e.g. can it be abused as a Turing complete interpreter?)
   I don't think so, the REST API is read-only and the only other inteface is dropping a policy to the directory.

10. Does the software provided by the package have a history of CVEs?
    No, the project is very new.

[jlebon]

Hi @jhrozek,

A few questions:

1. Have you seen RFE: safe SELinux policy updates #701? Currently, there is an issue in FCOS/RHCOS where if the policy is recompiled locally, future policy updates will not be inherited. I could imagine selinuxd being a way to work around this limitation. Does selinuxd overwrite the default policy path? Would it correctly detect if the base policy changes and trigger a rebuild on boot? If we remove the policy customizations, would it correctly go back to the base OSTree policy?
2. This is geared towards container-related things. But in the generic use case it would be nice to match the Ignition philosophy of preparing everything up front (i.e. in the initrd) to (1) error out if a policy is incorrectly written, and (2) rule out any race condition between injecting the policy and the subject software. Does selinuxd have a "one-shot" mode we could leverage here where it rebuilds the policy, but doesn't load it?

[jlebon]

I could imagine selinuxd being a way to work around this limitation.

On that topic, we did discuss this issue with the SELinux team some time back and IIRC I think part of what we hashed out was a similar design where the policy is recompiled on boot. If you haven't already, it would probably be good to chat with them and see whether they have any plans in that area.

[jhrozek]

Hi @jhrozek,

A few questions:

1. Have you seen RFE: safe SELinux policy updates #701? Currently, there is an issue in FCOS/RHCOS where if the policy is recompiled locally, future policy updates will not be inherited. I could imagine selinuxd being a way to work around this limitation. Does selinuxd overwrite the default policy path? Would it correctly detect if the base policy changes and trigger a rebuild on boot? If we remove the policy customizations, would it correctly go back to the base OSTree policy?

I will get back to you with a more thorough (and tested!) answer tomorrow, but #701 includes a link to a discussion thread where the user adds a CIL to the Ignition file and then runs semodule -i - this is pretty much what selinuxd does. As pointed out in the discussion, this triggers a rebuild of the policy, which slows down the boot, though.

2. This is geared towards container-related things. But in the generic use case it would be nice to match the Ignition philosophy of preparing everything up front (i.e. in the initrd) to (1) error out if a policy is incorrectly written, and (2) rule out any race condition between injecting the policy and the subject software. Does selinuxd have a "one-shot" mode we could leverage here where it rebuilds the policy, but doesn't load it?

Yes, it does. I'm afraid we don't have great docs (the project is really new and was mostly used as an implementation detail of security profiles operator upstream so far), but I'll try to fix them tomorrow.

[jhrozek]

I could imagine selinuxd being a way to work around this limitation.

On that topic, we did discuss this issue with the SELinux team some time back and IIRC I think part of what we hashed out was a similar design where the policy is recompiled on boot. If you haven't already, it would probably be good to chat with them and see whether they have any plans in that area.

We did show a demo of both selinuxd and the security profiles operator to the SELinux team, but either way it won't hurt to tag @wrabcak to see if he has any insights.

[dustymabe]

We discussed this in the community meeting today.

13:17:33      dustymabe | #info we're interested to learn more about selinuxd and
                        | how it can support some SELinux usability issues on ostree
                        | systems. Having an rpm built would enable us to play
                        | around with it on an FCOS system.

@jhrozek - is there an rpm we could use to play with? Also do you have any demos to share where you show off the features of selinuxd beyond https://github.com/JAORMX/selinuxd#testing-for-demo-purposes

It was mentioned in the meeting that ideally we would handle selinux changes in rpm-ostree directly, but that hasn't happened yet. Check meeting logs for context.

[jlebon]

It was mentioned in the meeting that ideally we would handle selinux changes in rpm-ostree directly, but that hasn't happened yet. Check meeting logs for context.

Ahh yes, this is where I mentioned this in the past: #368 (comment).

[jhrozek]

We discussed this in the community meeting today.

13:17:33      dustymabe | #info we're interested to learn more about selinuxd and
                        | how it can support some SELinux usability issues on ostree
                        | systems. Having an rpm built would enable us to play
                        | around with it on an FCOS system.

@jhrozek - is there an rpm we could use to play with?

I built one:
https://copr.fedorainfracloud.org/coprs/jhrozek/selinuxd/

Also do you have any demos to share where you show off the features of selinuxd beyond https://github.com/JAORMX/selinuxd#testing-for-demo-purposes

So I was trying to prepare some demo today and ran into some issues. For one, I wasn't able to get the service enabled for an overlaid package and I wasn't able to produce my own FCOS image with the package. Those probably boil down to my ignorance of how FCOS works -- so far I was mostly just interacting with RHCOS through openshift and could probably be solved by reading the docs better.

But the bigger issue I found was that installing the policy module with selinuxd still triggers recompiling of the policy and modifies the selinux/targeted/policy/policy.XX file under /etc/. I reached out to the SELinux developers for help to see if we're just doing something wrong in selinuxd or if this is just an inherent issue.

It was mentioned in the meeting that ideally we would handle selinux changes in rpm-ostree directly, but that hasn't happened yet. Check meeting logs for context.

[jhrozek]

I'm sorry I don't have better news than "we talked with the SELinux team and they're looking into the issue".

Petr Lautrbach from the SELinux team suggested a compile change to SELinux that moves the DB from /etc/selinux to /var/selinux. The basic things seemed to work but more work is needed and tracked in https://issues.redhat.com/browse/SELINUX-2695

[justinkinney]

We're interested in exploring selinuxd - it sounds like it'd be a great fit for our use case. I'm trying to build an RPM to play with locally, but the systemd service units don't exist in the source as far as I can tell. I can cobble something together, but do you have anything you can share @jhrozek?

I also don't have access to view or vote on the issue referenced above (SELINUX-2695). Is there any progress being made on this internally? @wrabcak is that something you could speak to?

[wrabcak]

@justinkinney, yes internal ticket talks about following PR already merged by ostree developers. @WOnder93 can share more details.

[jhrozek]

We're interested in exploring selinuxd - it sounds like it'd be a great fit for our use case. I'm trying to build an RPM to play with locally, but the systemd service units don't exist in the source as far as I can tell. I can cobble something together, but do you have anything you can share @jhrozek?

I also don't have access to view or vote on the issue referenced above (SELINUX-2695). Is there any progress being made on this internally? @wrabcak is that something you could speak to?

I did get through the motions of packaging selinuxd as an RPM some time ago (for this reason) and the branch is still available here: https://github.com/jhrozek/selinuxd/tree/make_install
It's probably a bit outdated, though. If you can make rebase the branch, even better. There's a commit that implements make install that might be good enough, at least to play around in a VM and the systemd units should still be reasonably up-to-date.

[dustymabe]

Thinking out loud here and asking a dumb question.. Where does this sit now that ostreedev/ostree#2569 has merged (related to #701)?

[jhrozek]

Thinking out loud here and asking a dumb question.. Where does this sit now that ostreedev/ostree#2569 has merged (related to #701)?

Honestly, if you think that running oneshot systemd units that install the modules is OK for the FCOS use-case then I'm not sure if having selinuxd as a package on the host itself brings that much.

Where having selinuxd on the host would be beneficial would be in the context of OCP/OKD/k8s where you could deploy the policies as MachineConfigs. But then again, this use-case is probably better served with the Security Profiles Operator.

This probably leaves the (edge?) case of pushing policies for static pods on k8s/OCP/OKD, but I wonder if it's worth it..?

[dustymabe]

Honestly, if you think that running oneshot systemd units that install the modules is OK for the FCOS use-case then I'm not sure if having selinuxd as a package on the host itself brings that much.

I don't actually. oneshot systemd units can be awkward to write. I think it's much easier to drop down a config file that tells the machine what you want.

In that context selinuxd is still useful IMO.

Thank you for refreshing my memory.

[cgwalters]

Where having selinuxd on the host would be beneficial would be in the context of OCP/OKD/k8s where you could deploy the policies as MachineConfigs

Big overlap/intersection with OCP CoreOS Layering here.

I think the dividing line here is that the selinuxd approach inherently supports live/rebootless updates, but I also think we should support that in a uniform way via rpm-ostree ex apply-live.