diff options
author | Casey Schaufler <casey@schaufler-ca.com> | 2015-03-21 18:26:40 -0700 |
---|---|---|
committer | Casey Schaufler <casey@schaufler-ca.com> | 2015-03-23 13:21:34 -0700 |
commit | bf4b2fee99799780ea3dbb6d79d1909b3e32be13 (patch) | |
tree | 70224834f619caa3bf5abd39a7334f5b77bf5656 /security/smack/smack.h | |
parent | 7fc5f36e980a8f4830efdae3858f6e64eee538b7 (diff) | |
download | linux-bf4b2fee99799780ea3dbb6d79d1909b3e32be13.tar.bz2 |
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.h | 8 |
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; |