I can't find where I read this now, could somebody please tell me what I need to add/remove from the strict policy to disallow running of the setenforce command (but still allow changing enforcement mode via rebooting) ?
Thanks, Todd
On Fri, 2005-09-09 at 09:33 -0700, Todd Merritt wrote:
I can't find where I read this now, could somebody please tell me what I need to add/remove from the strict policy to disallow running of the setenforce command (but still allow changing enforcement mode via rebooting) ?
Typically, the can_setenforce() macro defined in macros/core_macros.te is used in the policy to allow processes to change /selinux/enforce (which is how setenforce works). It is used in macros/admin_macros.te to allow administrators to do it, and in domains/program/initrc.te to allow /etc/rc.d/rc.sysinit to do it for emergency recovery situations. So you could remove its individual occurrences or change the macro definition to expand to nothing. You likely also would want to modify the unconfined_domain definition and update the assertion in assert.te to check that it isn't granted anywhere else.
Naturally, the problem then becomes dealing with policy updates after making such a customization, so you might want to consider implementing this as a policy boolean or tunable and submitting it for inclusion in the standard policy. That would let you disable it easily without having to make invasive changes to the policy.
On Fri, 2005-09-09 at 09:33 -0700, Todd Merritt wrote:
I can't find where I read this now, could somebody please tell me what I need to add/remove from the strict policy to disallow running of the setenforce command (but still allow changing enforcement mode via rebooting) ?
BTW, if you are going to do that, I assume you also want to remove the ability to reload policy after the initial load? Although that has implications for policy updates...
On Fri, 2005-09-09 at 12:53 -0400, Stephen Smalley wrote:
On Fri, 2005-09-09 at 09:33 -0700, Todd Merritt wrote:
I can't find where I read this now, could somebody please tell me what I need to add/remove from the strict policy to disallow running of the setenforce command (but still allow changing enforcement mode via rebooting) ?
BTW, if you are going to do that, I assume you also want to remove the ability to reload policy after the initial load? Although that has implications for policy updates...
I hadn't thought of that. There's no point closing the window and leaving the door open, but that may be more hoops that I care to jump through for this application.
On Saturday 10 September 2005 02:33, Todd Merritt tmerritt@email.arizona.edu wrote:
I can't find where I read this now, could somebody please tell me what I need to add/remove from the strict policy to disallow running of the setenforce command (but still allow changing enforcement mode via rebooting) ?
I've attached a patch against the latest rawhide policy (which should also work against the latest FC4 policy).
This patch adds a new boolean named secure_mode_policyload to cover loading policy, setting boolean states, and setting enforcing mode. It also adds a new boolean named secure_mode_insmod to control module loading.
NB Setting secure_mode_policyload to default to 1 at boot time will work, but that means policy can only be loaded once at boot (should be able to install new policy and reboot the machine though). Setting secure_mode_insmod at boot will probably make the boot process fail for all non-trivial machines, the initial values of booleans are set before modules for devices such as Ethernet cards. Setting secure_mode_insmod after the boot process is completed might be a good idea if you have no plans to use USB or Cardbus/PCMCIA, there have been exploits which relied on the ability to trick the system into loading modules (EG the ptrace exploit).
We could probably do with more work in this area, but the patch I have attached works reasonably well and adds usefully to the secure_mode functionality so I believe it's worthy of inclusion.
On Mon, 2005-09-12 at 16:52 +1000, Russell Coker wrote:
I've attached a patch against the latest rawhide policy (which should also work against the latest FC4 policy).
This patch adds a new boolean named secure_mode_policyload to cover loading policy, setting boolean states, and setting enforcing mode. It also adds a new boolean named secure_mode_insmod to control module loading.
NB Setting secure_mode_policyload to default to 1 at boot time will work, but that means policy can only be loaded once at boot (should be able to install new policy and reboot the machine though). Setting secure_mode_insmod at boot will probably make the boot process fail for all non-trivial machines, the initial values of booleans are set before modules for devices such as Ethernet cards. Setting secure_mode_insmod after the boot process is completed might be a good idea if you have no plans to use USB or Cardbus/PCMCIA, there have been exploits which relied on the ability to trick the system into loading modules (EG the ptrace exploit).
Did you attach the wrong patch? The one you sent doesn't define new booleans; it just wraps additional rules with the existing secure_mode boolean.
On Tuesday 13 September 2005 01:00, Stephen Smalley sds@tycho.nsa.gov wrote:
NB Setting secure_mode_policyload to default to 1 at boot time will work, but that means policy can only be loaded once at boot (should be able to install new policy and reboot the machine though). Setting secure_mode_insmod at boot will probably make the boot process fail for all non-trivial machines, the initial values of booleans are set before modules for devices such as Ethernet cards. Setting secure_mode_insmod after the boot process is completed might be a good idea if you have no plans to use USB or Cardbus/PCMCIA, there have been exploits which relied on the ability to trick the system into loading modules (EG the ptrace exploit).
Did you attach the wrong patch? The one you sent doesn't define new booleans; it just wraps additional rules with the existing secure_mode boolean.
I attached the patch, re-worked it, and then forgot to attach the new patch.
The correct patch is attached to this message.
On Saturday 17 September 2005 22:35, Russell Coker russell@coker.com.au wrote:
Did you attach the wrong patch? The one you sent doesn't define new booleans; it just wraps additional rules with the existing secure_mode boolean.
I attached the patch, re-worked it, and then forgot to attach the new patch.
The correct patch is attached to this message.
I hate doing this.
Just after I sent the previous patch I discovered a minor bug. When building a policy with ypbind.te included the nested booleans break the compile. The attached patch fixes this.
selinux@lists.fedoraproject.org