You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm seeking some clarification on the allow_disabled property that I referenced in my closed bug report here: #152
For some background, we had an issue where we enabled selinux with a custom policy module to allow access for an application. Since the allow_disabled property by default prevents compiling policy modules unless selinux is enabled (as in, selinux has been enabled and the server has subsequently been rebooted) our policy module was not compiled/enabled until later. This gap in time resulted in our audit logs being pummeled and subsequently forwarded to an rsyslog server and causing some network contention.
I'm curious if the behavior of the allow_disabled property is reversed from its true intent. Is there a reason that, by default, an admin would want to forego compiling a module until after enabling selinux? Doing so would always create a scenario where applications would function poorly/unexpectedly (in the case of enforcing mode) in the time between rebooting a server to enable selinux and chef-clienting to compile the module.
The text was updated successfully, but these errors were encountered:
I'm seeking some clarification on the
allow_disabled
property that I referenced in my closed bug report here: #152For some background, we had an issue where we enabled selinux with a custom policy module to allow access for an application. Since the
allow_disabled
property by default prevents compiling policy modules unless selinux is enabled (as in, selinux has been enabled and the server has subsequently been rebooted) our policy module was not compiled/enabled until later. This gap in time resulted in our audit logs being pummeled and subsequently forwarded to an rsyslog server and causing some network contention.I'm curious if the behavior of the
allow_disabled
property is reversed from its true intent. Is there a reason that, by default, an admin would want to forego compiling a module until after enabling selinux? Doing so would always create a scenario where applications would function poorly/unexpectedly (in the case of enforcing mode) in the time between rebooting a server to enable selinux and chef-clienting to compile the module.The text was updated successfully, but these errors were encountered: