-
Notifications
You must be signed in to change notification settings - Fork 158
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
turn arbitrary SELinux booleans on or off at boot #291
Conversation
tangent: grrr - i wish we had fixed coreos/ignition#586 already This seems like a good idea to me as a short term solution to our "configuring SELinux in a more cloud native way" problem. Is there any concern about multiple of these systemd units running at the same time and possibly colliding with one another? An alternative approach would be to have users drop down a config file and have a single service run, read the configuration, and apply the booleans. |
You can run arbitrary numbers of these units, using just the single template. For the firstboot workaround, you can space-separate the list of units to be enabled. |
Yep. That's how systemd works. What I'm asking is if a user were to define 20 systemd unit instances of this service and many of them fire off at the same time does running
I'm not sure what you mean? Are referring to your suggested workaround for coreos/ignition#586. There's actually a simpler solution I think which is what I used for the kmods-via-containers work (example copied below), which just adds another unit that requires the instantiated unit.
|
Yeah, your hack is simpler, but doesn't go away after first boot. If the admin checks whether the service will come back up, the obvious answer from systemd would be incorrect. |
I think that the underlying selinux tooling has locking, but it's much more efficient to set multiple booleans at once. |
Indeed, this method takes about 0.02 seconds per boolean, or 1 second for 50 booleans... so I wouldn't worry about the boot-time impact. I have no idea about any locking issues. @rhatdan is an expert.
|
I'd less-prefer to enable services such as these thru a bogus service dependency, as systemd will then report such services as not enabled:
Even though I've My more-troublesome firstboot-only service avoids this. Really, we should just fix the ignition bug. |
@jamescassell 👍 to everything you said |
Overall I like the idea and it's basically a nicer elaboration on the suggested workaround in openshift/machine-config-operator#852 (comment) So it will avoid the ostree selinux bug if we make these transient - and that also implies removing |
OK let me see if I can dig into this a bit. My first reaction is that we should merge this, but now I have some concerns:
I'm thinking that since we don't really get a benefit (because it's not less complicated) without fixing coreos/ignition#586 then we shouldn't merge this right now. While we wait maybe our long term SELinux story will gain some clarity and we'll have a better idea on if |
As we already know we have to live with an hackish workaround for some time, I'd rather suggest we put this templating logic into |
yeah, I'd be in favor of some syntactic sugar to selinux:
booleans:
- name: container_manage_cgroup
state: on I'll be sending another PR to make the workaround closer to a one-liner, but the above would also be nice. |
Just to reference a PR where Not an expert here at all, but maybe |
setsebool is available for turning on and off booleans and is part of policycoreutils and does not require python. |
good news: WIP PR to fix the ignition bug: coreos/ignition#934 |
I'm going ahead and closing this stale PR. |
to use it after first boot, do something like
systemctl enable --now setsebool-on@container_manage_cgroup.service
To use it, you'd normally use an
fcc
like this one:That doesn't actually work because of coreos/ignition#586 or a related bug.
to make it work for now, use something like this: