11:33 a.m.
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
11:41 a.m.
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.
--
Stephen Smalley
National Security Agency
11:53 a.m.
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...
--
Stephen Smalley
National Security Agency
12:18 p.m.
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.
1:52 a.m.
On Saturday 10 September 2005 02:33, Todd Merritt <tmerritt(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10 a.m.
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.
--
Stephen Smalley
National Security Agency
7:35 a.m.
On Tuesday 13 September 2005 01:00, Stephen Smalley <sds(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
7:53 a.m.
On Saturday 17 September 2005 22:35, Russell Coker <russell(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
6820
days inactive
6828
days old
selinux@lists.fedoraproject.org
7 comments
3 participants
participants (3)
-
Russell Coker -
Stephen Smalley -
Todd Merritt