summaryrefslogtreecommitdiff
path: root/security/smack/smack.h
diff options
context:
space:
mode:
authorCasey Schaufler <casey@schaufler-ca.com>2015-03-22 04:26:40 +0300
committerCasey Schaufler <casey@schaufler-ca.com>2015-03-23 23:21:34 +0300
commitbf4b2fee99799780ea3dbb6d79d1909b3e32be13 (patch)
tree70224834f619caa3bf5abd39a7334f5b77bf5656 /security/smack/smack.h
parent7fc5f36e980a8f4830efdae3858f6e64eee538b7 (diff)
downloadlinux-bf4b2fee99799780ea3dbb6d79d1909b3e32be13.tar.xz
Smack: Allow an unconfined label in bringup mode
I have vehemently opposed adding a "permissive" mode to Smack for the simple reasons that it would be subject to massive abuse and that developers refuse to turn it off come product release. I still believe that this is true, and still refuse to add a general "permissive mode". So don't ask again. Bumjin Im suggested an approach that addresses most of the concerns, and I have implemented it here. I still believe that we'd be better off without this sort of thing, but it looks like this minimizes the abuse potential. Firstly, you have to configure Smack Bringup Mode. That allows for "release" software to be ammune from abuse. Second, only one label gets to be "permissive" at a time. You can use it for debugging, but that's about it. A label written to smackfs/unconfined is treated specially. If either the subject or object label of an access check matches the "unconfined" label, and the access would not have been allowed otherwise an audit record and a console message are generated. The audit record "request" string is marked with either "(US)" or "(UO)", to indicate that the request was granted because of an unconfined label. The fact that an inode was accessed by an unconfined label is remembered, and subsequent accesses to that "impure" object are noted in the log. The impurity is not stored in the filesystem, so a file mislabled as a side effect of using an unconfined label may still cause concern after a reboot. So, it's there, it's dangerous, but so many application developers seem incapable of living without it I have given in. I've tried to make it as safe as I can, but in the end it's still a chain saw. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Diffstat (limited to 'security/smack/smack.h')
-rw-r--r--security/smack/smack.h8
1 files changed, 8 insertions, 0 deletions
diff --git a/security/smack/smack.h b/security/smack/smack.h
index 67ccb7b2b89b..49eada6266ec 100644
--- a/security/smack/smack.h
+++ b/security/smack/smack.h
@@ -105,6 +105,7 @@ struct task_smack {
#define SMK_INODE_INSTANT 0x01 /* inode is instantiated */
#define SMK_INODE_TRANSMUTE 0x02 /* directory is transmuting */
#define SMK_INODE_CHANGED 0x04 /* smack was transmuted */
+#define SMK_INODE_IMPURE 0x08 /* involved in an impure transaction */
/*
* A label access rule.
@@ -193,6 +194,10 @@ struct smk_port_label {
#define MAY_LOCK 0x00002000 /* Locks should be writes, but ... */
#define MAY_BRINGUP 0x00004000 /* Report use of this rule */
+#define SMACK_BRINGUP_ALLOW 1 /* Allow bringup mode */
+#define SMACK_UNCONFINED_SUBJECT 2 /* Allow unconfined label */
+#define SMACK_UNCONFINED_OBJECT 3 /* Allow unconfined label */
+
/*
* Just to make the common cases easier to deal with
*/
@@ -254,6 +259,9 @@ extern int smack_cipso_mapped;
extern struct smack_known *smack_net_ambient;
extern struct smack_known *smack_onlycap;
extern struct smack_known *smack_syslog_label;
+#ifdef CONFIG_SECURITY_SMACK_BRINGUP
+extern struct smack_known *smack_unconfined;
+#endif
extern struct smack_known smack_cipso_option;
extern int smack_ptrace_rule;