Interesting....
I was actually trying address a (slightly) different issue: how to
recreate, after the fact, as much of the state as possible
from the log. Can certainly add to the user space code
to detect this change, and then emit a message to the log.
Prior to your suggestion, I looked at the code for selinuxfs.c.
I think a one line change could also do the trick:
(I modeled this after the log prints on a policy load)
***************
*** 135,140 ****
--- 135,143 ----
length = task_has_security(current, SECURITY__SETENFORCE);
if (length)
goto out;
+ printk(KERN_INFO "setenforce: %s->%s\n",
+ (selinux_enforcing ? "enforcing" : "permissive"),
+ (new_value ? "enforcing" : "permissive"));
selinux_enforcing = new_value;
if (selinux_enforcing)
avc_ss_reset(0);
tom
------------------------------------------------------------------------
* /From/: Stephen Smalley <sds epoch ncsc mil>
------------------------------------------------------------------------
On Tue, 2004-06-29 at 18:35, Tom London wrote:
How difficult would it be to add 'old state->new state' to the log on a
change in
the enforcing state? Currently, 'setenforce' appears to be logged as a
toggle....
The kernel just audits the permission check, i.e. that setenforce
permission was checked due to a change to the enforcing status. One
could add an additional auxiliary audit data type to avc_audit_data and
change the caller to supply the old and new states, but that would
require a patch to the SELinux kernel module, and I'm not sure it is
worthwhile. You can already have userspace receive notifications of
enforcing status changes, including the new value via netlink socket
messages; the userspace AVC in libselinux does this to detect changes in
permissive/enforcing status.
--
Stephen Smalley <sds epoch ncsc mil>
National Security Agency
