Version2 Smack: Simplified Mandatory Access Control Kernel
Subsystems (2)
Casey Schaufler
maintainerPATCH 1/1 Version2 Smack: Simplified Mandatory Access Control Kernel
From: Casey Schaufler <[email protected]>
Smack is the Simplified Mandatory Access Control Kernel.
Smack implements mandatory access control (MAC) using labels attached to tasks and data containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that requires an absolute minimum of application support and a very small amount of configuration data.
Smack is implemented as a clean LSM. It requires no external code changes and the patch modifies only the Kconfig and Makefile in the security directory. Smack uses extended attributes and provides a set of general mount options, borrowing technics used elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides a pseudo-filesystem smackfs that is used for manipulation of system Smack attributes.
The patch, patches for ls and sshd, a README, a startup script, and x86 binaries for ls and sshd are also available on
http:/www.schaufler-ca.com
The patch has been tested with 2.6.22, 2.6.23-rc3, and 2.6.23-rc3-mm1. Development has been done using Fedora Core 7 in a virtual machine environment.
Smack provides mandatory access controls based on the label attached to a task and the label attached to the object it is attempting to access. Smack labels are deliberately short (1-7 characters) text strings. Single character labels using special characters are reserved for system use. The only operation applied to Smack labels is equality comparison. No wildcards or expressions, regular or otherwise, are used.
A file always gets the Smack label of the task that created it.
Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^" is permitted.
3. A read or execute access requested on an object labeled "_" is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same label is permitted.
6. Any access requested that is explicitly defined in the loaded rule set is permitted.
7. Any other access is denied.
Rules may be explicitly defined by writing subject,object,access triples to /smack/load.
Smack rule sets can be easily defined that describe Bell&LaPadula sensitivity, Biba integrity, and a variety of interesting configurations. Smack rule sets can be modified on the fly to accomodate changes in the operating environment or even the time of day.
Some practical use cases:
Hierarchical levels. The less common of the two usual uses for MLS systems is to define hierarchical levels, often unclassified, confidential, secret, and so on. To set up smack to support this, these rules could be defined:
C Unclass rx S C rx S Unclass rx TS S rx TS C rx TS Unclass rx
A TS process can read S, C, and Unclass data, but cannot write it. An S process can read C and Unclass. Note that specifying that TS can read S and S can read C does not imply TS can read C, it has to be explicitly stated.
Non-hierarchical categories. This is the more common of the usual uses for an MLS system. Since the default rule is that a subject cannot access an object with a different label no access rules are required to implement compartmentalization.
A case that the Bell & LaPadula policy does not allow is demonstrated with this Smack access rule:
A case that Bell&LaPadula does not allow that Smack does:
ESPN ABC r
ABC ESPN rOn my portable video device I have two applications, one that shows ABC programming and the other ESPN programming. ESPN wants to show me sport stories that show up as news, and ABC will only provide minimal information about a sports story if ESPN is covering it. Each side can look at the other's info, neither can change the other. Neither can see what FOX is up to, which is just as well all things considered.
Another case that I especially like:
SatData Guard w
Guard Publish w
A program running with the Guard label opens a UDP socket and accepts messages sent by a program running with a SatData label. The Guard program inspects the message to ensure it is wholesome and if it is sends it to a program running with the Publish label. This program then puts the information passed in an appropriate place. Note that the Guard program cannot write to a Publish file system object because file system semanitic require read as well as write.
The four cases (categories, levels, mutual read, guardbox) here are all quite real, and problems I've been asked to solve over the years. The first two are easy to do with traditonal MLS systems while the last two you can't without invoking privilege, at least for a while.
--- security/Kconfig | 1 security/Makefile | 2 security/smack/Kconfig | 10 security/smack/Makefile | 9 security/smack/smack.h | 232 ++ security/smack/smack_access.c | 310 +++ security/smack/smack_lsm.c | 2618 ++++++++++++++++++++++++++++++++ security/smack/smackfs.c | 1206 ++++++++++++++ 8 files changed, 4388 insertions(+)
Changes since the previous version:
- The model for storing Smack labels has been changed to help resolve some locking issues. Instead of allocating Smack labels as needed and then throwing them away they are allocated once and stored on a master list. The security blobs don't have their own copies, they point to elements in the list. Blob changes are atomic pointer assignments now.
- The optional CIPSO mapping table has been merged into the master label list. That required some locking work, too.
- The label list includes an entry for a secid in support of future audit integration.
- Added bunches of header comments.
- Fixed errors in key handling.
- A process can only change it's own smack label, it can not change the label of another process. Privilege is still required.
security/Kconfig +1 -0
@@ -94,6 +94,7 @@ config SECURITY_ROOTPLUG If you are unsure how to answer this question, answer N. source security/selinux/Kconfig +source security/smack/Kconfig endmenu
security/Makefile +2 -0
@@ -4,6 +4,7 @@ obj-$(CONFIG_KEYS) += keys/ subdir-$(CONFIG_SECURITY_SELINUX) += selinux +subdir-$(CONFIG_SECURITY_SMACK) += smack # if we don't select a security model, use the default capabilities ifneq ($(CONFIG_SECURITY),y)
@@ -14,5 +15,6 @@ endif obj-$(CONFIG_SECURITY) += security.o dummy.o inode.o # Must precede capability.o in order to stack properly. obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o +obj-$(CONFIG_SECURITY_SMACK) += commoncap.o smack/built-in.o obj-$(CONFIG_SECURITY_CAPABILITIES) += commoncap.o capability.o obj-$(CONFIG_SECURITY_ROOTPLUG) += commoncap.o root_plug.o
security/smack/Kconfig +10 -0
@@ -0,0 +1,10 @@ +config SECURITY_SMACK + bool "Simplified Mandatory Access Control Kernel Support" + depends on NETLABEL && SECURITY_NETWORK + default n + help + This selects the Simplified Mandatory Access Control Kernel. + Smack is useful for sensitivity, integrity, and a variety + of other mandatory security schemes. + If you are unsure how to answer this question, answer N. +
security/smack/Makefile +9 -0
@@ -0,0 +1,9 @@ +# +# Makefile for the SMACK LSM +# + +obj-$(CONFIG_SECURITY_SMACK) := smack.o + +smack-y := smack_lsm.o smack_access.o smackfs.o + +EXTRA_CFLAGS += -Inet/netlabel
security/smack/smack_access.c +310 -0
310 lines not on this page · raw message
security/smack/smackfs.c +1206 -0
1,206 lines not on this page · raw message
security/smack/smack.h +232 -0
232 lines not on this page · raw message
security/smack/smack_lsm.c +2618 -0
1,213 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Part of the diff is not shown here. View the raw message.
Quoted 17 lines · Casey Schaufler
Smack is the Simplified Mandatory Access Control Kernel.
Smack implements mandatory access control (MAC) using labels attached to tasks and data containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that requires an absolute minimum of application support and a very small amount of configuration data.
Smack is implemented as a clean LSM. It requires no external code changes and the patch modifies only the
KconfigandMakefilein the security directory. Smack uses extended attributes and provides a set of general mount options, borrowing technics used elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides a pseudo-filesystem smackfs that is used for manipulation of system Smack attributes.
Quoted 4 lines
The patch, patches for ls and sshd, a README, a startup script, and x86 binaries for ls and sshd are also available on
http:/www.schaufler-ca.com
I like the general idea of this LSM.
One question about your security model, though:
If I understand your LSM correctly, MAC override is based on capabilities, specifically on CAP_LINUX_IMMUTABLE. So any root process which doesn't explicitly give up this capability is effectively unconfined, right?
If so, this is a serious limitation that should be mentioned in the docs. File capabilities should alleviate this problem, but they first need to be configured correctly...
Some other comments below:
security/smack/Kconfig line 9
Quoted 12 lines
security/smack/Kconfig +9
-0@@ -0,0 +1,10 @@ +config SECURITY_SMACK + bool "Simplified Mandatory Access Control Kernel Support" + depends on NETLABEL && SECURITY_NETWORK + default n + help + This selects the Simplified Mandatory Access Control Kernel. + Smack is useful for sensitivity, integrity, and a variety + of other mandatory security schemes. + If you are unsure how to answer this question, answer N.
I think a link to further documentation would be nice. Maybe you could include the README from your site in Documentation/?
BTW: Some documentation missing there:
* the various mount options
* how to enable cipso (Do I have to enable it explicitly? Most people won't even know what cipso is)
Quoted 10 lines
security/smack/Kconfig +10
-0+/** + * smack_syslog - Smack approval on syslog + * @type: message type + * + * Require that the task has the floor label + * + * Returns 0 on success, error code otherwise. + */ +static int smack_syslog(int type) +{
security/smack/Kconfig
Quoted 10 lines
security/smack/Kconfig +10
-0+ int rc; + smack_t *sp = current->security; + + rc = cap_syslog(type); + if (rc == 0) + if (*sp != SMK_FLOOR) + rc = -EACCES; + + return rc; +}
Can you explain why you limit syslog that way?
Quoted 2 lines
+/**
+ *smackfs_follow_link- follow a smackfs symlink
^^^^^^^^^^^ should be put_link
Quoted 8 lines
+ * @dentry: unused
+ * @nd: name entry
+ * @ptr: unused
+ *
+ * free the buffer used in following the link.
+ */security/smack/Kconfig +2
-0+static void smackfs_put_link(struct dentry *dentry, struct nameidata *nd, void *ptr) +{
security/smack/Kconfig
Quoted 10 lines
security/smack/Kconfig +8
-0+ kfree(nd_get_link(nd)); +} + for (cp = data - 1; cp != NULL; cp = strchr(cp + 1, '\n')) { + if (*++cp == '\0') + break; + if (sscanf(cp, "%14s %30s\n", name, target) != 2) { + printk("%s:%d bad scan\n", + __func__, __LINE__);
Leftover debugging printk? Otherwise, a level would be nice.
security/smack/Kconfig
Quoted 5 lines
security/smack/Kconfig +5
-0+ break; + } + smk_add_symlink(name, target); + printk("%s:%d add %s -> %s\n", + __func__, __LINE__, name, target);
Ditto.
Quoted 12 lines
security/smack/Kconfig +10
-0+ } +/** + * smackfs_follow_link - follow a smackfs symlink + * @dentry: name cache entry + * @nd: name entry + * + * A symlink on smackfs has unusual semantics. + * + * The Smack value of the task is appended to the link string. + * Thus, if a task labeled "Gentoo" does chdir("/smack/tmp")
security/smack/Kconfig
Quoted 10 lines
security/smack/Kconfig +10
-0+ * it will use "/moldy/Gentoo". + * + * The expected usage is the /tmp is a symlink to /smack/tmp + * which is itself a symlink to /moldy. /moldy should have a + * directory for each label in use to accomodate the value + * appended on the redirection. + * + * An interesting addition would be a file system that automatically + * creates directories as needed, at the appropriate label. + */
I'm not very versed in the VFS, so I don't think I understand the code fully there, but shouldn't the above read /smack/links?
security/smack/Kconfig
Quoted 3 lines
security/smack/Kconfig +3
-0+ static struct tree_descr smack_files[] = { + [SMK_LOAD] = {"load", &smk_load_ops, S_IRUGO|S_IWUSR}, + [SMK_LINKS] = {"links", &smk_links_ops, S_IRUGO|S_IWUSR},
I really don't understand your symlink code (not because it's bad, I just don't know this area), so this is just a question:
Wouldn't S_IRUGO be enough for the links entry?
Quoted 17 lines
security/smack/Kconfig +17
-0+ [SMK_CIPSO] = {"cipso", &smk_cipso_ops, S_IRUGO|S_IWUSR}, + [SMK_DOI] = {"doi", &smk_doi_ops, S_IRUGO|S_IWUSR}, + [SMK_DIRECT] = {"direct", &smk_direct_ops, S_IRUGO|S_IWUSR}, + [SMK_AMBIENT] = {"ambient", &smk_ambient_ops,S_IRUGO|S_IWUSR}, + [SMK_NLTYPE] = {"nltype", &smk_nltype_ops, S_IRUGO|S_IWUSR}, + /* last one */ {""} + }; + + /* + * There will be only one smackfs. Casey says so. + */ + smk_sb = sb; + + rc = simple_fill_super(sb, SMACK_MAGIC, smack_files); + if (rc != 0) { + printk(KERN_ERR "%s failed %d while creating inodes\n", + __func__, rc);
security/smack/Kconfig
Quoted 10 lines
security/smack/Kconfig +10
-0+ return rc; + } + + root_inode = sb->s_root->d_inode; + root_inode->i_security = new_inode_smack(&smack_known_floor.smk_known); + + /* + * Create a directory for /smack/tmp + */ + smk_add_symlink("tmp", SMK_TMPPATH_ROOT);
Ah, so you dynamically add symlinks here. Can the user do this, too? If so, how? A little documentation might be nice.
Thomas
Casey Schaufler
maintainerQuoted 18 lines · --- Thomas Bleher
Quoted 17 lines · Casey Schaufler
Smack is the Simplified Mandatory Access Control Kernel.
Smack implements mandatory access control (MAC) using labels attached to tasks and data containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that requires an absolute minimum of application support and a very small amount of configuration data.
Smack is implemented as a clean LSM. It requires no external code changes and the patch modifies only the
KconfigandMakefilein the security directory. Smack uses extended attributes and provides a set of general mount options, borrowing technics used elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides a pseudo-filesystem smackfs that is used for manipulation of system Smack attributes.
Quoted 6 lines
Quoted 4 lines
The patch, patches for ls and sshd, a README, a startup script, and x86 binaries for ls and sshd are also available on
http:/www.schaufler-ca.com
I like the general idea of this LSM.
Thank you.
Quoted 5 lines
One question about your security model, though:
If I understand your LSM correctly, MAC override is based on capabilities, specifically onCAP_LINUX_IMMUTABLE. So any root process which doesn't explicitly give up this capability is effectively unconfined, right?
That is correct. This is consistant with the traditional and current linux mainstream model.
Quoted 2 lines
If so, this is a serious limitation that should be mentioned in the docs.
The superuser has been an issue since the first Security Expert looked at the Unix kernel in the 1970's. I am not out to solve that issue as Linux has the capability mechanism in place to do that, and active development (as you point out) is in progress to make that mechanism useful.
Quoted 2 lines
File capabilities should alleviate this problem, but they first need to be configured correctly...
They need to get upstream, too.
Yes, program capability setting is an issue. I have done it before on a Unix system and while it is a pain in the bum it's not actually that hard when you have an audit trail and the source. It's the same technic that the SELinux folks use with audit2allow, but directed at a smaller set of choices.
Quoted 6 lines
Some other comments below:
Quoted 1 line
--- linux-2.6.22-base/security/smack/Kconfig 1969-12-31 16:00:00.000000000
-0800
Quoted 1 line
+++ linux-2.6.22-smack/security/smack/Kconfig 2007-08-22 02:18:55.000000000
-0700
Quoted 13 lines
security/smack/Kconfig line 9
Quoted 10 lines
security/smack/Kconfig +9
-0@@ -0,0 +1,10 @@ +config SECURITY_SMACK + bool "Simplified Mandatory Access Control Kernel Support" + depends on NETLABEL && SECURITY_NETWORK + default n + help + This selects the Simplified Mandatory Access Control Kernel. + Smack is useful for sensitivity, integrity, and a variety + of other mandatory security schemes. + If you are unsure how to answer this question, answer N.I think a link to further documentation would be nice. Maybe you could include the README from your site in
Documentation/?
An idea with merit. I'll do it.
Quoted 3 lines
BTW: Some documentation missing there:
* the various mount options
* how to enable cipso
I'll add those
Quoted 2 lines
(Do I have to enable it explicitly? Most people
won't even know what cipso is)
Nope. CIPSO is native to Smack. The touchy bit is turning it off when talking off the box. So far it looks like most of the world is sufficiently ignorant of CIPSO that it gets ignored enough for communication to occur at the ambient label.
Quoted 14 lines
Quoted 14 lines
security/smack/smack_lsm.c +14
-0+/** +* smack_syslog - Smack approval on syslog +* @type: message type +* +* Require that the task has the floor label +* +* Returns 0 on success, error code otherwise. +*/ +static int smack_syslog (int type) +{ +int rc; +smack_t *sp = current->security; + + rc =cap_syslog (type);
Quoted 8 lines
security/smack/smack_lsm.c line 154
Quoted 6 lines
security/smack/smack_lsm.c +6
-0+if (rc ==0 ) +if (*sp !=SMK_FLOOR ) + rc = -EACCES ; + +return rc; +}Can you explain why you limit syslog that way?
Indeed I can. In the end the syslog data is going to get put into a file and may get displayed on consoles. You can argue that the right thing to do is make the Smack label on those files and devices hat ("^") and allow anyone (Smackwise) write to the syslog. That disallows casual viewing of the syslog, and everyone would hate that.
It would make sense to allow this if the caller has appropriate privilege. I think that I will make that change.
Quoted 3 lines
Quoted 2 lines
+/**
+ *smackfs_follow_link- follow a smackfs symlink^^^^^^^^^^^ should be put_link
Whoops.
Quoted 13 lines
Quoted 7 lines
+ * @dentry: unused
+ * @nd: name entry
+ * @ptr: unused
+ *
+ * free the buffer used in following the link.
+ */
+static void smackfs_put_link(struct dentry *dentry, struct nameidata *nd,void *ptr)
Quoted 3 lines
security/smack/smackfs.c +3
-0+{ +kfree (nd_get_link (nd)); +}
Quoted 8 lines
security/smack/smackfs.c line 1088
Quoted 6 lines
security/smack/smackfs.c +6
-0+for (cp = data -1 ; cp !=NULL ; cp =strchr (cp +1 ,'\n' )) { +if (*++cp =='\0' ) +break ; +if (sscanf (cp,"%14s %30s\n" , name, target) !=2 ) { +printk ("%s:%d bad scan\n" , + __func__, __LINE__);Leftover debugging printk? Otherwise, a level would be nice.
Nuts, I thought I'd gotten all of those.
Quoted 7 lines
security/smack/smackfs.c line 1093
Quoted 5 lines
security/smack/smackfs.c +5
-0+break ; + } +smk_add_symlink (name, target); +printk ("%s:%d add %s -> %s\n" , + __func__, __LINE__, name, target);Ditto.
Ditto.
Quoted 23 lines
Quoted 12 lines
security/smack/smackfs.c +10
-0+ } +/** +* smackfs_follow_link - follow a smackfs symlink +* @dentry: name cache entry +* @nd: name entry +* +* A symlink on smackfs has unusual semantics. +* +* The Smack value of the task is appended to the link string. +* Thus, if a task labeled "Gentoo" does chdir("/smack/tmp") security/smack/smackfs.c line 858
Quoted 10 lines
security/smack/smackfs.c +10
-0+* it will use "/moldy/Gentoo". +* +* The expected usage is the /tmp is a symlink to /smack/tmp +* which is itself a symlink to /moldy. /moldy should have a +* directory for each label in use to accomodate the value +* appended on the redirection. +* +* An interesting addition would be a file system that automatically +* creates directories as needed, at the appropriate label. +*/
Quoted 2 lines
I'm not very versed in the VFS, so I don't think I understand the code fully there, but shouldn't the above read /smack/links?
It does.
Quoted 5 lines
security/smack/smackfs.c line 1123
Quoted 3 lines
security/smack/smackfs.c +3
-0+static struct tree_descr smack_files[] = { + [SMK_LOAD ] = {"load" , &smk_load_ops,S_IRUGO |S_IWUSR }, + [SMK_LINKS ] = {"links" , &smk_links_ops,S_IRUGO |S_IWUSR },I really don't understand your symlink code
It's ... unconventional.
Quoted 3 lines
(not because it's bad, I just
don't know this area), so this is just a question:
Wouldn'tS_IRUGObe enough for the links entry?
Nope.
Quoted 22 lines
Quoted 22 lines
security/smack/smackfs.c +22
-0+ [SMK_CIPSO] = {"cipso", &smk_cipso_ops, S_IRUGO|S_IWUSR}, + [SMK_DOI] = {"doi", &smk_doi_ops, S_IRUGO|S_IWUSR}, + [SMK_DIRECT] = {"direct", &smk_direct_ops, S_IRUGO|S_IWUSR}, + [SMK_AMBIENT] = {"ambient", &smk_ambient_ops,S_IRUGO|S_IWUSR}, + [SMK_NLTYPE] = {"nltype", &smk_nltype_ops, S_IRUGO|S_IWUSR}, + /* last one */ {""} + }; + +/* +* There will be only one smackfs. Casey says so. +*/ + smk_sb = sb; + + rc =simple_fill_super (sb,SMACK_MAGIC , smack_files); +if (rc !=0 ) { +printk (KERN_ERR "%s failed %d while creating inodes\n" , + __func__, rc); +return rc; + } + + root_inode = sb->s_root->d_inode; + root_inode->i_security =new_inode_smack (&smack_known_floor.smk_known);
Quoted 8 lines
security/smack/smackfs.c line 1150
Quoted 5 lines
security/smack/smackfs.c +5
-0+ +/* +* Create a directory for /smack/tmp +*/ +smk_add_symlink ("tmp" ,SMK_TMPPATH_ROOT );Ah, so you dynamically add symlinks here. Can the user do this, too? If so, how? A little documentation might be nice.
The addition of symlinks in /smack is limited to root. Since the content of smackfs is volitile making it user writeable could add some opportunities for abuse.
More documentation wouldn't hurt.
Thank you.
Casey Schaufler
[email protected]
Quoted 8 lines · Thomas Bleher
security/smack/smackfs.c line 1088
Quoted 6 lines
security/smack/smackfs.c +6
-0+for (cp = data -1 ; cp !=NULL ; cp =strchr (cp +1 ,'\n' )) { +if (*++cp =='\0' ) +break ; +if (sscanf (cp,"%14s %30s\n" , name, target) !=2 ) { +printk ("%s:%d bad scan\n" , + __func__, __LINE__);Leftover debugging printk? Otherwise, a level would be nice.
Or even pr_debug.
(pr_debug("%s...
Quoted 1 line
security/smack/smackfs.c line 1121
Quoted 1 line
security/smack/smackfs.c +1
-0+static struct tree_descr smack_files[] = {
Hey, can we make this const, if it does not change at runtime?
Jan
Casey Schaufler
maintainerQuoted 10 lines · --- Jan Engelhardt
Quoted 7 lines · Thomas Bleher
Quoted 6 lines
security/smack/smackfs.c +6
-0+for (cp = data -1 ; cp !=NULL ; cp =strchr (cp +1 ,'\n' )) { +if (*++cp =='\0' ) +break ; +if (sscanf (cp,"%14s %30s\n" , name, target) !=2 ) { +printk ("%s:%d bad scan\n" , + __func__, __LINE__);
Quoted 5 lines
Quoted 1 line
Leftover debugging printk? Otherwise, a level would be nice.
Or even
pr_debug.(pr_debug("%s...
I'm taking out the printk.
Quoted 3 lines
Quoted 1 line
security/smack/smackfs.c line 1121
Quoted 1 line
security/smack/smackfs.c +1
-0+static struct tree_descr smack_files[] = {Hey, can we make this const, if it does not change at runtime?
simple_fill_super() is unhappy with a const.
Casey Schaufler
[email protected]