aboutsummaryrefslogtreecommitdiffstats
path: root/security/smack/smack_access.c
diff options
context:
space:
mode:
authorCasey Schaufler <casey@schaufler-ca.com>2014-08-27 14:51:27 -0700
committerCasey Schaufler <casey@schaufler-ca.com>2014-08-28 13:11:56 -0700
commitd166c8024d620d654b12834fac354fb4203c6c22 (patch)
treed804064cb7fce9448071691ae5a6260dc35674db /security/smack/smack_access.c
parentSmack: Fix setting label on successful file open (diff)
downloadlinux-dev-d166c8024d620d654b12834fac354fb4203c6c22.tar.xz
linux-dev-d166c8024d620d654b12834fac354fb4203c6c22.zip
Smack: Bring-up access mode
People keep asking me for permissive mode, and I keep saying "no". Permissive mode is wrong for more reasons than I can enumerate, but the compelling one is that it's once on, never off. Nonetheless, there is an argument to be made for running a process with lots of permissions, logging which are required, and then locking the process down. There wasn't a way to do that with Smack, but this provides it. The notion is that you start out by giving the process an appropriate Smack label, such as "ATBirds". You create rules with a wide range of access and the "b" mode. On Tizen it might be: ATBirds System rwxalb ATBirds User rwxalb ATBirds _ rwxalb User ATBirds wb System ATBirds wb Accesses that fail will generate audit records. Accesses that succeed because of rules marked with a "b" generate log messages identifying the rule, the program and as much object information as is convenient. When the system is properly configured and the programs brought in line with the labeling scheme the "b" mode can be removed from the rules. When the system is ready for production the facility can be configured out. This provides the developer the convenience of permissive mode without creating a system that looks like it is enforcing a policy while it is not. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Diffstat (limited to 'security/smack/smack_access.c')
-rw-r--r--security/smack/smack_access.c24
1 files changed, 21 insertions, 3 deletions
diff --git a/security/smack/smack_access.c b/security/smack/smack_access.c
index f97d0842e621..9f02cb0ac85e 100644
--- a/security/smack/smack_access.c
+++ b/security/smack/smack_access.c
@@ -178,16 +178,27 @@ int smk_access(struct smack_known *subject_known, char *object_label,
&subject_known->smk_rules);
rcu_read_unlock();
- if (may > 0 && (request & may) == request)
+ if (may <= 0 || (request & may) != request) {
+ rc = -EACCES;
goto out_audit;
+ }
+#ifdef CONFIG_SECURITY_SMACK_BRINGUP
+ /*
+ * Return a positive value if using bringup mode.
+ * This allows the hooks to identify checks that
+ * succeed because of "b" rules.
+ */
+ if (may & MAY_BRINGUP)
+ rc = MAY_BRINGUP;
+#endif
- rc = -EACCES;
out_audit:
#ifdef CONFIG_AUDIT
if (a)
smack_log(subject_known->smk_known, object_label, request,
rc, a);
#endif
+
return rc;
}
@@ -214,7 +225,7 @@ int smk_tskacc(struct task_smack *subject, char *obj_label,
* Check the global rule list
*/
rc = smk_access(skp, obj_label, mode, NULL);
- if (rc == 0) {
+ if (rc >= 0) {
/*
* If there is an entry in the task's rule list
* it can further restrict access.
@@ -328,6 +339,13 @@ void smack_log(char *subject_label, char *object_label, int request,
struct smack_audit_data *sad;
struct common_audit_data *a = &ad->a;
+#ifdef CONFIG_SECURITY_SMACK_BRINGUP
+ /*
+ * The result may be positive in bringup mode.
+ */
+ if (result > 0)
+ result = 0;
+#endif
/* check if we have to log the current event */
if (result != 0 && (log_policy & SMACK_AUDIT_DENIED) == 0)
return;