Smack: Simplified Mandatory Access Control Kernel

+extern struct smk_list_entry *smack_list;

Quoted 1 line

+extern struct smk_list_entry *smack_list;

any reason to invent your own list rather than just using list.h?

security/smack/smackfs.c line 23

Quoted 7 lines

security/smack/smackfs.c +7 -0

+
+#include <linux/kernel.h>
+#include <linux/vmalloc.h>
+#include <linux/security.h>
+#include <linux/mutex.h>
+#include <net/netlabel.h>
+#include "../../net/netlabel/netlabel_domainhash.h"

can't you move this header to include/ instead?

security/smack/smackfs.c line 240

Quoted 5 lines

security/smack/smackfs.c +5 -0

+
+static struct file_operations smk_load_ops = {
+	.read		= smk_read_load,
+	.write		= smk_write_load,
+};

make that a const please

Quoted 5 lines

security/smack/smackfs.c +5 -0

+
+	doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
+	if (doip == NULL)
+		panic("smack:  Failed to initialize cipso DOI.\n");
+	doip->map.std = NULL;

security/smack/smackfs.c line 279

Quoted 4 lines

security/smack/smackfs.c +4 -0

+
+	ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
+	if (ndmp == NULL)
+		panic("smack:  Failed to initialize cipso ndmp.\n");

is panic() really the right thing here? It's usually considered quite rude ;)

security/smack/smackfs.c line 478

Quoted 4 lines

security/smack/smackfs.c +4 -0

+static struct file_operations smk_cipso_ops = {
+	.read		= smk_read_cipso,
+	.write		= smk_write_cipso,
+};

another candidate for const

Quoted 1 line

+static void *smackfs_follow_link(struct dentry *dentry, struct nameidata

*nd)

Quoted 1 line

+{

this one deserves a comment; are you implementing magic symlinks here?

Quoted 8 lines · --- Arjan van de Ven

security/smack/smackfs.c line 23

Quoted 6 lines

security/smack/smackfs.c +6 -0

+#include <linux/kernel.h>
+#include <linux/vmalloc.h>
+#include <linux/security.h>
+#include <linux/mutex.h>
+#include <net/netlabel.h>
+#include "../../net/netlabel/netlabel_domainhash.h"

can't you move this header to include/ instead?

Paul Moore, the developer of netlabel, promised to work out the right solution for this with me at a future date. He doesn't want to move the header, and I respect that.

Quoted 4 lines

Quoted 4 lines

security/smack/smackfs.c +4 -0

+	doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
+	if (doip == NULL)
+		panic("smack:  Failed to initialize cipso DOI.\n");
+	doip->map.std = NULL;

Quoted 8 lines

security/smack/smackfs.c line 279

Quoted 4 lines

security/smack/smackfs.c +4 -0

+
+	ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
+	if (ndmp == NULL)
+		panic("smack:  Failed to initialize cipso ndmp.\n");

is panic() really the right thing here? It's usually considered quite rude ;)

It's really early in start-up and if you're out of memory at that point you are not going very far into the future.

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 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.

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 aswell 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.

Quoted 5 lines · Casey Schaufler

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.

For starters, we would appear to already have a very capable labelling system

which can do *all* of this, completely and without exceptions,

in a much more flexible way.

Admittedly it's more complicated,

but one does have to have complexity in order to handle everything from CD burning in X, to Apache daemons, to only allowing Top-Secret-level logins over the IPsec tunnel on the Top Secret network, etc.

Do you see any particular reason this couldn't be implemented as a very *very* simplified SELinux wrapper?

For
example, this set of rules basically defines your described "read-vs- write-vs-exec" policy as best I can figure out:

user uu roles rr;

role rr types { star floor hat huh };

define(r',
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg }; allow $1 $2:ipc { getattr read associate unix_read };
## List of more "read" allow rules for different types of objects... ## ')

define(w',
allow $1 $2:file { ioctl write create setattr lock append unlink link rename swapon quotaon mounton };
allow $1 $2:socket { ioctl write create setattr lock append bind connect listen accept setopt shutdown sendto send_msg name_bind }; allow $1 $2:ipc { create destroy setattr write unix_write }; ## List of more "write" allow rules for different types of objects... ## ')

define(x',
allow $1 $2:file { execute };
allow $1 $2:dir { search };
## List of more "execute" allow rules for different types of objects... ##
')

And now to describe these rules:

Quoted 8 lines

Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"

The access rules enforced by Smack are, in order:

Quoted 11 lines

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.

## These are calls to the above macros which plug in the necessary arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##

Quoted 2 lines

Rules may be explicitly defined by writing subject,object,access triples to /smack/load.

Maybe worth a little utility to convert a file full of "subject,object,access" triples to an appropriate SELinux policy would be appropriate?

Quoted 5 lines

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.

SELinux can do this as well. It even includes support for conditional policy:

bool foo_can_do_logging true;

if (foo_can_do_logging) {
	allow foo_t foo_log_t:file { create read getattr append };
}

The SELinux tools also have support for policy modules, so you can extend the policy without modifying the base system.

Plus the stuff has been very heavily tested

and even supports X (as soon as the beta
X code gets improved and merged in the upstream X.org codebase).

Quoted 14 lines

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

Quoted 4 lines

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.

The big problem here is the duplication. Say you have a locked-down Apache configuration and you want to run 2 apache processes, one at Secret and one at Top-Secret. Under your model you have to copy- paste the policy and make sure to apply fixes/changes to both places.

Under SELinux, you can have processes as:
system_u:system_r:httpd_t:Secret:UFOSightings,AlienDissection system_u:system_r:httpd_t:TopSecret:NukeTests

They can only read and write objects for which multiple conditions are true: First, the object must match the Bell-Padula model with respect to the sensitivities and categories ("Secret:UFOSightings,AlienDissection", etc) *and* it must also be objects that httpd_t is allowed to read/write. That also includes network traffic, and your firewall can appropriately label data over a given IPsec link as one classification level while data over the raw network is labeled as another. Oh, and you can tweak the MLS constraints of the Bell-Padula model as necessary too.

Quoted 5 lines

Another case that I especially like:

SatData Guard w
Guard Publish w

Quoted 8 lines

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 aswell as write.

This is exactly what my company does, but the ability to restrict *exactly* what mechanisms are used is important. You restrict against file-system access implicitly, whereas SELinux does it explicitly:

   allow foo_t foo_sock_t:socket { .... };
versus:
   allow foo_t foo_log_t:file { ... };

With SELinux you can also allow your program to create files labelled as "log files" in one directory in one type and "transfer files" in another directory in a completely different type.

Quoted 5 lines

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.

I'm proud to say that the software of the company I work for does not need any extra privilege at all (aside from binding to ports <1024) to run under SELinux with strict MLS.

Under Trusted Solaris and such
we needed all sorts of dirty privilege hacks to relabel the files consistently, but under SELinux the policy does all the relabeling for us, we don't need to do a thing.

Quoted 1 line

[SELinux...] which can do *all* of this, completely and without exceptions,

That's quite a strong assertion.

Quoted 1 line

but one does have to have complexity in order to handle everything from CD burning in X, to Apache daemons, to only allowing Top-Secret-level logins over the IPsec tunnel on the Top Secret network, etc.

I do not agree with you. The MLS systems from the 1990's could do all that (except the IPsec tunnel, the function of which was preceeded by TSIG interfaces and protocols) without the complexity required by SELinux policy.

Quoted 6 lines

For example, this set of rules basically defines your described "read-vs-write-vs-exec" policy as best I can figure out:

user uu roles rr;

role rr types { star floor hat huh };

Quoted 6 lines

define(r',
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg }; allow $1 $2:ipc { getattr read associate unix_read };
## List of more "read" allow rules for different types of objects... ## ')

It would be instructive for those who are not well versed in the nuances of SELinux policy if you actually spelled out the whole thing, rather than using "## and more ##". Part of the point of Smack is the makeup of the full list that would be required here.

Quoted 22 lines

And now to describe these rules:

Quoted 8 lines

Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"

The access rules enforced by Smack are, in order:

Quoted 11 lines

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.

Quoted 13 lines

## These are calls to the above macros which plug in the necessary arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##

What would that look like?

Quoted 8 lines

Quoted 1 line

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.

SELinux can do this as well. It even includes support for conditional policy:

bool foo_can_do_logging true;

if (foo_can_do_logging) {
	allow foo_t foo_log_t:file { create read getattr append };
}

You have to build the booleans into the policy in advance.

Quoted 1 line

The SELinux tools also have support for policy modules, so you can extend the policy without modifying the base system.

And that's a good thing, but you still have to compile and reload your policy, and maybe relabel you filesystem when you do so.

Quoted 11 lines

Quoted 11 lines

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

Quoted 3 lines

Quoted 1 line

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.

The big problem here is the duplication. Say you have a locked-down Apache configuration and you want to run 2 apache processes, one at Secret and one at Top-Secret. Under your model you have to copy-paste the policy and make sure to apply fixes/changes to both places.

I'm sorry, but I don't understand your point at all.

Quoted 6 lines

This is exactly what my company does, but the ability to restrict *exactly* what mechanisms are used is important. You restrict against file-system access implicitly, whereas SELinux does it explicitly:

   allow foo_t foo_sock_t:socket { .... };
versus:
   allow foo_t foo_log_t:file { ... };

With SELinux you can also allow your program to create files labelled as "log files" in one directory in one type and "transfer files" in another directory in a completely different type.

I would be very interested to see the policy that your guard box uses.

Quoted 1 line

I'm proud to say that the software of the company I work for does not need any extra privilege at all (aside from binding to ports <1024) to run under SELinux with strict MLS.

That is an aspect of SELinux that has its dark side. While you are not explicitly violating a policy (e.g. requiring a capability) you are doing things that some of us would argue ought to require a capability. SELinux integrates privilege into the policy mechanism.

Smack does not. Smack is designed to use traditional Linux mechanisms for privilege.

Quoted 1 line

Under Trusted Solaris and such we needed all sorts of dirty privilege hacks to relabel the files consistently, but under SELinux the policy does all the relabeling for us, we don't need to do a thing.

Yeah. Well, you won't like Smack then. Implicit relabeling of processes and files does not happen. This is a major philisophical difference.

Quoted 4 lines · Casey Schaufler

Quoted 2 lines

[SELinux...] which can do *all* of this, completely and without exceptions,

That's quite a strong assertion.

It is, but I stand by it. If anyone can point out some portion of this which *cannot* be implemented as SELinux policy I will humbly step completely out of this discussion.

Quoted 5 lines

Quoted 4 lines

but one does have to have complexity in order to handle everything from CD burning in X, to Apache daemons, to only allowing Top- Secret-level logins over the IPsec tunnel on the Top Secret network, etc.

Quoted 4 lines

I do not agree with you. The MLS systems from the 1990's could do all that (except the IPsec tunnel, the function of which was preceeded by TSIG interfaces and protocols) without the complexity required by SELinux policy.

No, most/all of the MLS systems from the 1990s did not integrate Bell- LaPadula, Type Enforcement, and Role-Based-Access-Control together.

In addition, none of the MLS systems from the 1990s had modifiable constraints the way SELinux does (for example I can modify the fundamental policy to allow a process whose domain has the "i_am_special" attribute to override the BLP model for certain target types in certain special situations, all depending on how I apply that attribute and those types).

Quoted 15 lines

Quoted 14 lines

For example, this set of rules basically defines your described "read-vs-write-vs-exec" policy as best I can figure out:

user uu roles rr;

role rr types { star floor hat huh };

define(r',
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg }; allow $1 $2:ipc { getattr read associate unix_read }; ## List of more "read" allow rules for different types of objects... ##
')

Quoted 4 lines

It would be instructive for those who are not well versed in the nuances of SELinux policy if you actually spelled out the whole thing, rather than using "## and more ##". Part of the point of Smack is the makeup of the full list that would be required here.

Well, yes, but how exactly do you define "read", "write", and "execute" for the full list of SELinux object classes found here:
http://www.tresys.com/selinux/obj_perms_help.html

I was considering compiling the complete list, but such an exercise would take me at least an hour to do properly and which categories individual permissions should be placed in could be argued for weeks.

The SELinux reference policy doesn't even completely qualify all of those things with MLS restrictions, and they're the ones who got the hooks implemented originally.

Specifically, do you classify the bind() syscall as a "read" or a "write" operation.

How would you classify accept()?

In order to
support the full range of security controls that Linux has hooks for, you would need to identify a list of how to define "read", "write", and "execute" for every object-class in that massive list. Furthermore you would need to ensure that the definitions work for every process. From the variations between different portions of the SELinux ref policy, I contend that there is no single definition of "read", or "write" which works for all usages of a given object-class.

Quoted 36 lines

Quoted 35 lines

And now to describe these rules:

Quoted 8 lines

Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"

The access rules enforced by Smack are, in order:

Quoted 11 lines

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.

## These are calls to the above macros which plug in the necessary arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##

Quoted 1 line

What would that look like?

The same kind of thing as the r, x, and w above, with occasional "type my_type_t; role rr types my_type_t;" to declare a type before use. If you wanted to add support for attributes which apply to multiple types, you could put those after a comma after the "type my_type_t" portion of the type declaration.

Quoted 9 lines

Quoted 9 lines

Quoted 5 lines

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.

SELinux can do this as well. It even includes support for conditional policy:

Quoted 6 lines

Quoted 4 lines

bool foo_can_do_logging true;

if (foo_can_do_logging) {
	allow foo_t foo_log_t:file { create read getattr append };
}

You have to build the booleans into the policy in advance.

Well, yes, but a policy which completely ignores

Quoted 5 lines

Quoted 2 lines

The SELinux tools also have support for policy modules, so you can extend the policy without modifying the base system.

And that's a good thing, but you still have to compile and reload your policy, and maybe relabel you filesystem when you do so.

What exactly prevents you from having to "reload" and "relabel the filesystem" when using your system?

When you change the meaning of
new types, you clearly would need to first reload the policy then relaunch programs or relabel files to take advantage of the new types, otherwise they would be categorically ignored by the system.

The only difference is the "compile" step, which converts from a reasonably modifiable language into a binary format which the kernel can efficiently parse.

I suspect you'd get shot down instantly if
you tried to stuff the policy compiler in the kernel too.

Quoted 19 lines

Quoted 19 lines

Quoted 18 lines

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.

Quoted 7 lines

Quoted 5 lines

The big problem here is the duplication. Say you have a locked- down Apache configuration and you want to run 2 apache processes, one at Secret and one at Top-Secret. Under your model you have to copy-paste the policy and make sure to apply fixes/changes to both places.

I'm sorry, but I don't understand your point at all.

Ok, let's say you want to use your model to restrict Apache and MySQL running at the same classification level. You have to define combined labels, such as:
S_Apache S_MySQL rx
[...]

Now if you want to run an apache/mysql pair at TS, you have to copy all those rules and substitute "S_" with "TS_".

With SELinux, you
don't have to do anything other than define new labels for the secret- web-docs and the top-secret-web-docs folders,

because the Apache
*type-enforcement* policy is completely independent from the MLS levels. You can write a 5-line policy to label 2 slightly different initscripts with different range-transitions. The only difference between them will be the paths inside and the labels on them. The rest of apache's policy stays the same.

Quoted 12 lines

Quoted 11 lines

This is exactly what my company does, but the ability to restrict *exactly* what mechanisms are used is important. You restrict against file-system access implicitly, whereas SELinux does it explicitly:

   allow foo_t foo_sock_t:socket { .... };
versus:
   allow foo_t foo_log_t:file { ... };

With SELinux you can also allow your program to create files labelled as "log files" in one directory in one type and "transfer files" in another directory in a completely different type.

Quoted 1 line

I would be very interested to see the policy that your guard box uses.

Unfortunately that's still considered company-proprietary information at the moment, although that's likely to change at some point in the future. We're not all that different from the httpd policies and similar stuff found in the SELinux "refpolicy" available from tresys' website.

Quoted 8 lines

Quoted 3 lines

I'm proud to say that the software of the company I work for does
not need any extra privilege at all (aside from binding to ports
<1024) to run under SELinux with strict MLS.

That is an aspect of SELinux that has its dark side. While you are not explicitly violating a policy (e.g. requiring a capability) you are doing things that some of us would argue ought to require a capability. SELinux integrates privilege into the policy mechanism.

How does "moving data around a system" require root privileges?

Why should it? Admittedly, moving data from "TopSecret" to "Secret" requires a process labeled with a range including at least "S-TS" *and* with the MLS "read-to-clearance" attribute, but you can be as stingy with that attribute as you like.

That attribute is explicitly
given its magic abilities in the mlsconstrain rules defined in the policy file itself, so it's also possible to do information flow analysis on it.

Quoted 8 lines

Smack does not. Smack is designed to use traditional Linux mechanisms for privilege.

Quoted 4 lines

Under Trusted Solaris and such we needed all sorts of dirty privilege hacks to relabel the files consistently, but under SELinux the policy does all the relabeling for us, we don't need to do a thing.

Quoted 3 lines

Yeah. Well, you won't like Smack then. Implicit relabeling of processes and files does not happen. This is a major philisophical difference.

Here's an argument for why implicit labeling is good and explicit labeling is bad: If your process wants to label things explicitly it needs special privileges to do so, and it can abuse those privileges.

Under SELinux the labeling is implicit *AND* the transitions are entirely within the policy. This means that you can do information flow analysis (as I described above) and it *ALSO* means that the program cannot possibly "abuse" its privileges because it has none.

When httpd creates a file in its log directory that
file is created with httpd_log_t and it is limited to being able to append to the file *only*. So when your apache gets compromised, the attacker has NO WAY to modify the logs, and you can prove this with a 60-second study of the policy. In fact, on my companies productions systems I can *PROVE* that the only way to get audit data out of the

system is via a local TTY by interacting with system_u:object_r:local_login_t:SystemLow-SystemHigh to log in with a process of someluser:auditreview_r:auditreview_t:SystemHigh, which may read the audit files, or otherluser:auditadmin_r:auditadmin_t:SystemHigh, which may read and delete the audit files. I can even prove that no process on the system is allowed to modify the files after they are created, barring a kernel-level vulnerability.

So the implicit labeling of files actually restricts every process *FURTHER*. They no longer have even an inkling of a choice about file labeling, and that's a GOOD thing.

The only remaining extension
we need to really thoroughly lock down our systems is to allow last- path-component matching in type-transitions and allow rules (EG:
When "vipw" creates a file named "passwd" in an "etc_t" directory, it is automatically labeled "etc_passwd_t")

From what I understand
Stephen Smalley and others are thinking that over even now. I'll do it myself as soon as I get time at work beyond prepping systems for shipping to clients if they haven't finished it by them.

Quoted 4 lines · --- Kyle Moffett

Quoted 1 line · Casey Schaufler

It would be instructive for those who are not well versed in the nuances of SELinux policy if you actually spelled out the whole thing, rather than using "## and more ##". Part of the point of Smack is the makeup of the full list that would be required here.

Well, yes, but how exactly do you define "read", "write", and "execute" for the full list of SELinux object classes found here: http://www.tresys.com/selinux/obj_perms_help.html

Smack is designed to treat objects as consistantly as is reasonable. The list of object classes defined by SELinux is great for a system designed to treat accesses with the highest possible granularity. This is not a design goal for Smack.

Quoted 1 line

I was considering compiling the complete list, but such an exercise would take me at least an hour to do properly and which categories individual permissions should be placed in could be argued for weeks.

I will be happy to consider your arguement when you are willing to present the complete argument.

Quoted 1 line

Specifically, do you classify the bind() syscall as a "read" or a "write" operation.

Neither. Bind attaches a name (port number) to a socket (which is a data structure that is part of your process) from a global namespace. No objects are involved, hence no accesses.

Quoted 31 lines

Quoted 31 lines

Quoted 30 lines

And now to describe these rules:

Quoted 8 lines

Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"

The access rules enforced by Smack are, in order:

Quoted 7 lines

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.

## These are calls to the above macros which plug in the necessary arguments r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##

Quoted 3 lines

Quoted 1 line

What would that look like?

The same kind of thing as the r, x, and w above, with occasional "type my_type_t; role rr types my_type_t;" to declare a type before use. If you wanted to add support for attributes which apply to multiple types, you could put those after a comma after the "type my_type_t" portion of the type declaration.

Well, I'm interested in seeing the actual code, not "the same kind of thing" as arguement.

C        Unclass rx
S        C       rx
S        Unclass rx
TS       S       rx
TS       C       rx
TS       Unclass rx

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

Quoted 1 line

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.

SELinux can do this as well. It even includes support for conditional policy:

bool foo_can_do_logging true;

if (foo_can_do_logging) {
	allow foo_t foo_log_t:file { create read getattr append };
}

Quoted 3 lines

Quoted 1 line

You have to build the booleans into the policy in advance.

Well, yes, but a policy which completely ignores

This sentence no verb.

Quoted 4 lines

Quoted 3 lines

Quoted 1 line

The SELinux tools also have support for policy modules, so you can extend the policy without modifying the base system.

And that's a good thing, but you still have to compile and reload your policy, and maybe relabel you filesystem when you do so.

Quoted 1 line

What exactly prevents you from having to "reload" and "relabel the filesystem" when using your system?

Good question. First, changing Smack rules is no big deal. They can be added or changed one by one as required while the system is running, and there are uses that exploit that. One example is to put the label "Game" on certain programs and:

at 8:00am "Worker Game no"
at 5:00pm "Worker Game x"

Thus Worker processes can access Game files only during off hours.

As far as relabeling the file system goes, the rules apply to processes and objects, not to programs. The label on a program describes who can access it, it will run with the label of the process that exec's it. A change in the rules does not require a change to the labels on the file system for things to work according to the rules of engagement.

Quoted 1 line

When you change the meaning of new types, you clearly would need to first reload the policy then relaunch programs or relabel files to take advantage of the new types, otherwise they would be categorically ignored by the system.

I'm sorry, but again, I don't know what you mean by "changing the meaning of new types".

I think you may be making assumptions about the behavior of Smack based on what SELinux does that don't hold. I hesitate to call a Smack rule list a language.

Quoted 1 line

I suspect you'd get shot down instantly if you tried to stuff the policy compiler in the kernel too.

Smack rule specifications are really really basic, just the subject label, the object label, and the access permitted. There are no wildcards, no expressions (regular or otherwise) and they apply to all objects. Only the labels are taken into account on an access check, not the userid, the current directory, the time of day, or the binary involved. Oh, there is a capability to override the check, but that's just basic Linux behavior and I wouldn't want to muck that up.

Quoted 5 lines

Ok, let's say you want to use your model to restrict Apache and MySQL running at the same classification level. You have to define combined labels, such as:
S_Apache S_MySQL rx
[...]

Now if you want to run an apache/mysql pair at TS, you have to copy all those rules and substitute "S_" with "TS_".

There is only one rule to copy. I think most sysadmins can insert a "T" with sufficient confidence that this is not going to be a major issue.

Quoted 1 line

With SELinux, you don't have to do anything other than define new labels for the secret-web-docs and the top-secret-web-docs folders,

Which if you actually write out the change is going to require more than inserting a "T".

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

This is exactly what my company does, but the ability to restrict *exactly* what mechanisms are used is important. You restrict against file-system access implicitly, whereas SELinux does it explicitly:

   allow foo_t foo_sock_t:socket { .... };
versus:
   allow foo_t foo_log_t:file { ... };

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

With SELinux you can also allow your program to create files labelled as "log files" in one directory in one type and "transfer files" in another directory in a completely different type.

I would be very interested to see the policy that your guard box uses.

Unfortunately that's still considered company-proprietary information at the moment, although that's likely to change at some point in the future. We're not all that different from the httpd policies and similar stuff found in the SELinux "refpolicy" available from tresys' website.

I think there's a rule against using proprietary information that you can't share in a friendly debate on the LKML.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

I'm proud to say that the software of the company I work for does not need any extra privilege at all (aside from binding to ports <1024) to run under SELinux with strict MLS.

That is an aspect of SELinux that has its dark side. While you are not explicitly violating a policy (e.g. requiring a capability) you are doing things that some of us would argue ought to require a capability. SELinux integrates privilege into the policy mechanism.

How does "moving data around a system" require root privileges?

Hmm. You snuck the adjective "root" into the discussion when it wasn't there before.

Quoted 1 line

Why should it? Admittedly, moving data from "TopSecret" to "Secret" requires a process labeled with a range including at least "S-TS" *and* with the MLS "read-to-clearance" attribute, but you can be as stingy with that attribute as you like.

Yup. And plenty of people like you think that is really spiffy.

Quoted 1 line

That attribute is explicitly given its magic abilities in the mlsconstrain rules defined in the policy file itself, so it's also possible to do information flow analysis on it.

I much prefer strait-up process capabilities to magic attributes. Call me old fashioned if you want to.

Quoted 1 line

Under SELinux the labeling is implicit *AND* the transitions are entirely within the policy. This means that you can do information flow analysis (as I described above) and it *ALSO* means that the program cannot possibly "abuse" its privileges because it has none.

It means you have not only the program to worry about being written correctly, but the policy as well.

Quoted 1 line

So the implicit labeling of files actually restricts every process *FURTHER*. They no longer have even an inkling of a choice about file labeling, and that's a GOOD thing.

That's true about Smack, you know. The process has no choice about the label that the files get.

Quoted 1 line

The only remaining extension we need to really thoroughly lock down our systems is to allow last-path-component matching in type-transitions and allow rules (EG: When "vipw" creates a file named "passwd" in an "etc_t" directory, it is automatically labeled "etc_passwd_t")

Hey, and AppArmor does that today!

Quoted 2 lines

From what I understand Stephen Smalley and others are thinking that over even now. I'll do it myself as soon as I get time at work beyond prepping systems for shipping to clients if they haven't finished it by them.

You might want to review the archives on how that experiment ended up before saying much more about it.

Thank you for your comments. I hope that I have made the behavior and value of Smack clearer in responding to them.

Linus and AKPM pulled from CC, I'm sure they're bored to tears by now ;-).

Quoted 16 lines

Quoted 9 lines · --- Kyle Moffett

Quoted 4 lines · Casey Schaufler

It would be instructive for those who are not well versed in the nuances of SELinux policy if you actually spelled out the whole thing, rather than using "## and more ##". Part of the point of Smack is the makeup of the full list that would be required here.

Well, yes, but how exactly do you define "read", "write", and "execute" for the full list of SELinux object classes found here:
http://www.tresys.com/selinux/obj_perms_help.html

Smack is designed to treat objects as consistantly as is reasonable. The list of object classes defined by SELinux is great for a system designed to treat accesses with the highest possible granularity. This is not a design goal for Smack.

Quoted 7 lines

Quoted 4 lines

I was considering compiling the complete list, but such an exercise would take me at least an hour to do properly and which categories individual permissions should be placed in could be argued for weeks.

I will be happy to consider your arguement when you are willing to present the complete argument.

Here's my complete argument:

Regardless of how you categorize "read", "write", "execute", and "doesnt-need-protection" in your policy language, I can write an SELinux policy and a list of labels which expresses that policy. Moreover, without too much work I can probably write a Perl script to do it for you. On the other hand I can only do that if you tell me exactly how you want to categorize those things, though. In my personal opinion they cannot be reasonably categorized without breaking all sorts of tools or leaving gaping holes; precisely the reason that SELinux uses such a fine-grained list.

Quoted 6 lines

Quoted 2 lines

Specifically, do you classify the bind() syscall as a "read" or a "write" operation.

Neither. Bind attaches a name (port number) to a socket (which is a data structure that is part of your process) from a global namespace. No objects are involved, hence no accesses.

So "bind()" doesn't present a security hole at all and any program may bind to any port? Sounds fun! I'm sure lots of crackers would love to get ahold of an account on such a web-server; what havoc they could wreak! Even the <1024 restriction doesn't sufficiently limit things these days, as many critical services use ports >=1024.

Quoted 38 lines

Quoted 38 lines

Quoted 37 lines

Quoted 22 lines

And now to describe these rules:

Quoted 8 lines

Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"

The access rules enforced by Smack are, in order:

Quoted 11 lines

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.

Quoted 13 lines

## These are calls to the above macros which plug in the necessary arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##

What would that look like?

Quoted 8 lines

Quoted 5 lines

The same kind of thing as the r, x, and w above, with occasional "type my_type_t; role rr types my_type_t;" to declare a type before use. If you wanted to add support for attributes which apply to multiple types, you could put those after a comma after the "type my_type_t" portion of the type declaration.

Well, I'm interested in seeing the actual code, not "the same kind of thing" as arguement.

Ok, you want sample policy to match your "MLS" sample? For convenience here's one more macro:
define(rx',r($1',$2') x($1',$2')')

type unclass;
type c;
type s;
type ts;
rx(c, unclass)
rx(s, c)
rx(s, unclass)
rx(ts, s)
rx(ts, c)
rx(ts, unclass)

In case you don't have the policy you typed into your email, it looks almost identical with a few exceptions for slightly modified syntax:

Quoted 6 lines

C        Unclass rx
S        C       rx
S        Unclass rx
TS       S       rx
TS       C       rx
TS       Unclass rx

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Quoted 13 lines

Quoted 5 lines

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.

SELinux can do this as well. It even includes support for conditional policy:

bool foo_can_do_logging true;

if (foo_can_do_logging) {
	allow foo_t foo_log_t:file { create read getattr append };
}

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

You have to build the booleans into the policy in advance.

Well, yes, but a policy which completely ignores

This sentence no verb.

Whoops, I think I must have smashed the delete key or something while sending. Here's the paragraphs which got elided:

Well, yes, but a policy which completely ignores future expandability can't be expanded upon regardless. It would also be very hard to add new policy without a lot of duplication under your system. On the other hand, with SELinux you can very easily add attribute-based policy so adding new capabilities is as simple as sticking existing attributes on newly defined types. For example:

type my_log_t, file_type, log_file;
type my_log_daemon, daemon;

Right there I just gave permission for the logrotate to recycle files labelled my_log_t, which the sysadmin and audit admin can also read (and the audit admin can delete). I also gave permission for my daemon to send SIGCHLD to init, and for init/initscripts to send it a SIGTERM/SIGQUIT. All without writing a SINGLE policy rule. Basically all of those existing behaviors are found in allow rules built on the "file_type", "log_file", and "daemon" attributes.

Quoted 17 lines

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

The SELinux tools also have support for policy modules, so you can extend the policy without modifying the base system.

And that's a good thing, but you still have to compile and reload your policy, and maybe relabel you filesystem when you do so.

What exactly prevents you from having to "reload" and "relabel the filesystem" when using your system?

Good question. First, changing Smack rules is no big deal. They can be added or changed one by one as required while the system is running, and there are uses that exploit that. One example is to put the label "Game" on certain programs and:

at 8:00am "Worker Game no"
at 5:00pm "Worker Game x"

Quoted 1 line

Thus Worker processes can access Game files only during off hours.

This is fundamentally broken: First of all we have no fd revoke support yet, so all a user has to do is start the game at 5:05pm just before they leave, then leave it running in the background during the day for them to play at leisure.

Secondly, you can already do the
same thing with DAC and a PAM groups-from-time-of-day module, I don't see why such a thing is special enough to need MAC. Thirdly, I could do exactly the same thing with an SELinux boolean and a cronjob (once we get proper revoke support):

## Rule to allow cron to tweak the "can_play_games" boolean value if (can_play_games) {
## Insert game-playing allow rules here
}

Then in cron:
0 8 * * * root setsebool can_play_games false
0 17 * * * root setsebool can_play_games true

Quoted 6 lines

As far as relabeling the file system goes, the rules apply to processes and objects, not to programs. The label on a program describes who can access it, it will run with the label of the process that exec's it. A change in the rules does not require a change to the labels on the file system for things to work according to the rules of engagement.

By this logic, every program will always have the same label, unless you recode every program to explicitly change it when it starts; precisely the thing that the SELinux type transitions were designed to avoid.

Quoted 7 lines

Quoted 4 lines

When you change the meaning of new types, you clearly would need to first reload the policy then relaunch programs or relabel files to take advantage of the new types, otherwise they would be categorically ignored by the system.

I'm sorry, but again, I don't know what you mean by "changing the meaning of new types".

Oh, say something like "Oh, drat, I wanted this daemon to run as some other type".

Unless you relabel the files and relaunch the daemon
the system will have no idea how the system will change. And if you let arbitrary root processes relabel things on the fly then you've lost all the security advantages to a MAC system.

Quoted 3 lines

I think you may be making assumptions about the behavior of Smack based on what SELinux does that don't hold. I hesitate to call a Smack rule list a language.

Well, it's a syntactic construction to describe an idea, ergo it's a language.

Quoted 11 lines

Quoted 2 lines

I suspect you'd get shot down instantly if you tried to stuff the policy compiler in the kernel too.

Smack rule specifications are really really basic, just the subject label, the object label, and the access permitted. There are no wildcards, no expressions (regular or otherwise) and they apply to all objects. Only the labels are taken into account on an access check, not the userid, the current directory, the time of day, or the binary involved. Oh, there is a capability to override the check, but that's just basic Linux behavior and I wouldn't want to muck that up.

I think you may be making assumptions about the behaviour of SELinux based on what other OSes do which don't hold:

(a) SELinux does not care about user id, current directory, time of day, etc. It cares solely about 3 things:
the Subject, the Object, and the Action. For example, if an init script attempts to execute the apache binary then SELinux gets the following data for parameters:
subject="system_u:system_r:initrc_t:SystemLow-SystemHigh" object="system_u:object_r:httpd_exec_t:SystemLow" action="file-

Quoted 1 line

execute".

(b) SELinux does NOT have a capability which overrides it. If you want to do something that the policy categorically does not allow, you have 2 choices: change the policy or disable SELinux. You can also use a policy which disables both of those options

Quoted 9 lines

Quoted 8 lines

Ok, let's say you want to use your model to restrict Apache and MySQL running at the same classification level. You have to define combined labels, such as:
S_Apache S_MySQL rx
[...]

Now if you want to run an apache/mysql pair at TS, you have to copy all those rules and substitute "S_" with "TS_".

Quoted 3 lines

There is only one rule to copy. I think most sysadmins can insert a "T" with sufficient confidence that this is not going to be a major issue.

Which means that for every new category/level-alteration you have to modify a significant portion of your policy. With SELinux I get to either add 2 lines to a local policy module or run a couple "semanage" commands.

Quoted 5 lines

Quoted 2 lines

With SELinux, you don't have to do anything other than define new labels for the secret-web-docs and the top-secret-web-docs folders,

Which if you actually write out the change is going to require more than inserting a "T".

Umm, how so? Any of these will work:
* The security administrator creates my /www_S and /www_TS
folders, labels them, and remembers not to run "restorecon" on those folders.

* The security administrator loads a local policy module with just
an fc file containing:

       /www_S(/.*)?  system_u:object_r:web_docs_t:Secret
       /www_TS(/.*)? system_u:object_r:web_docs_t:TopSecret

* The security administrator runs these commands:
semanage fcontext -a -r Secret-Secret -s system_u -t
web_docs_t '/www_S(/.*)?'
semanage fcontext -a -r TopSecret-TopSecret -s system_u -t
web_docs_t '/www_TS(/.*)?'

Quoted 22 lines

Quoted 21 lines

Quoted 8 lines

Quoted 8 lines

This is exactly what my company does, but the ability to restrict *exactly* what mechanisms are used is important. You restrict against file-system access implicitly, whereas SELinux does it explicitly:

   allow foo_t foo_sock_t:socket { .... };
versus:
   allow foo_t foo_log_t:file { ... };

Quoted 7 lines

Quoted 4 lines

With SELinux you can also allow your program to create files labelled as "log files" in one directory in one type and "transfer files" in another directory in a completely different type.

I would be very interested to see the policy that your guard box uses.

Unfortunately that's still considered company-proprietary information at the moment, although that's likely to change at some point in the future. We're not all that different from the httpd policies and similar stuff found in the SELinux "refpolicy" available from tresys' website.

Quoted 2 lines

I think there's a rule against using proprietary information that you can't share in a friendly debate on the LKML.

Well, you were the one who asked. It's mostly irrelevant to the discussion since the *same* kind of stuff is found in almost every module in the tresys-distributed refpolicy.

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

I'm proud to say that the software of the company I work for does not need any extra privilege at all (aside from binding to ports <1024) to run under SELinux with strict MLS.

That is an aspect of SELinux that has its dark side. While you are not explicitly violating a policy (e.g. requiring a capability) you are doing things that some of us would argue ought to require a capability. SELinux integrates privilege into the policy mechanism.

Quoted 4 lines

Quoted 1 line

How does "moving data around a system" require root privileges?

Hmm. You snuck the adjective "root" into the discussion when it wasn't there before.

Ok, fine, how does "moving data around a system" require anything more than bog-standard user-level privileges? Normal users under Linux are not permitted to change "security.*" attributes at all, but they may bind to sockets, etc. You can define a "capability" which lets you do all that, but then you're just blindly giving processes more privileges than they need to complete an operation. Why should you get the "rename all files" priv when all you need is "Make my log files get $LABEL when I put them in /var/log/mydaemon/"?

Quoted 6 lines

Quoted 4 lines

Why should it? Admittedly, moving data from "TopSecret" to "Secret" requires a process labeled with a range including at least "S-TS" *and* with the MLS "read-to-clearance" attribute, but you can be as stingy with that attribute as you like.

Yup. And plenty of people like you think that is really spiffy.

Please explain why you think it isn't?

Quoted 6 lines

Quoted 3 lines

That attribute is explicitly given its magic abilities in the mlsconstrain rules defined in the policy file itself, so it's also possible to do information flow analysis on it.

I much prefer strait-up process capabilities to magic attributes. Call me old fashioned if you want to.

You can call them "process capabilities" or "magic attributes", they're the same thing, just more fine-grained. Instead of (Note: r1 == subject role, r2 == target role, t2 == target type):

   mlsconstrain process transition ( (r1 == r2) || (t1 ==  

i_am_a_role_changing_capability) )

you have (Note: t1 == subject type):

   mlsconstrain process transition ( (r1 == r2) || (r1 == system_r &&  

t1 == i_am_a_login_process && t2 == i_am_a_user_entrypoint) )

The latter is like the former, except instead of one single ultimate "change-any-role" capability, you have a capability which allows a system login process to change roles *ONLY* if it's also changing to a user entrypoint. Please tell me which you think is more secure.

Quoted 6 lines

Quoted 5 lines

Under SELinux the labeling is implicit *AND* the transitions are entirely within the policy. This means that you can do information flow analysis (as I described above) and it *ALSO* means that the program cannot possibly "abuse" its privileges because it has none.

Quoted 2 lines

It means you have not only the program to worry about being written correctly, but the policy as well.

If your security policy sucks then you might as well not have MAC at all. At least under SELinux the absolute worst possible case is that you always fall back to DAC-based security.

Quoted 4 lines

Quoted 3 lines

So the implicit labeling of files actually restricts every process *FURTHER*. They no longer have even an inkling of a choice about file labeling, and that's a GOOD thing.

Quoted 2 lines

That's true about Smack, you know. The process has no choice about the label that the files get.

So how do you selectively label files based on criteria such as "where did I get put"? How do you distinguish between a "log file" which is create-and-append-only, a "database file" which I can modify however I want to, and a "unix socket" which I can bind in /var/run and get connections from user processes?

Quoted 7 lines

Quoted 5 lines

The only remaining extension we need to really thoroughly lock down our systems is to allow last-path-component matching in type- transitions and allow rules (EG: When "vipw" creates a file named "passwd" in an "etc_t" directory, it is automatically labeled "etc_passwd_t")

Hey, and AppArmor does that today!

No, AppArmor doesn't. It says: "/usr/sbin/httpd may not access /etc/ shadow", for example, whereas SELinux with the proposed extension
says: "Only the 'passwd' program or 'vipw' by a sysadmin may modify *ANY* password shadow file, and if I create a "shadow" file in *ANY* etc_t directory then it's automatically a shadow file. The difference is also in the treatment of hard-links. Under SELinux I can guarantee that the data in the shadow_t file is secure, no matter where somebody manages to get it linked to, and in addition I can guarantee that nobody can spoof me and make me create the shadow file elsewhere or with the wrong label.

Quoted 6 lines

Quoted 5 lines

From what I understand Stephen Smalley and others are thinking that over even now. I'll do it myself as soon as I get time at work beyond prepping systems for shipping to clients if they haven't finished it by them.

Quoted 2 lines

You might want to review the archives on how that experiment ended up before saying much more about it.

Hmm, I haven't seen anything pass LKML and digging in the [email protected] archives (as well as google) doesn't seem to be turning up anything even vaguely related. Do you happen to have the link handy?

Quoted 2 lines

Thank you for your comments. I hope that I have made the
behavior and value of Smack clearer in responding to them.

You're welcome. I endeavor to poke my nose into every little LSM- related corner in the kernel, this one included.

I respect the design decisions that SELinux has made regarding granularity without agreeing with them myself.

Quoted 4 lines · --- Kyle Moffett

Quoted 3 lines · Casey Schaufler

Quoted 1 line · --- Kyle Moffett

I was considering compiling the complete list, but such an exercise would take me at least an hour to do properly and which categories individual permissions should be placed in could be argued for weeks.

Quoted 5 lines

Quoted 1 line

I will be happy to consider your arguement when you are willing to present the complete argument.

Here's my complete argument:

Regardless of how you categorize "read", "write", "execute", and "doesnt-need-protection" in your policy language, I can write an SELinux policy and a list of labels which expresses that policy. Moreover, without too much work I can probably write a Perl script to do it for you. On the other hand I can only do that if you tell me exactly how you want to categorize those things, though. In my personal opinion they cannot be reasonably categorized without breaking all sorts of tools or leaving gaping holes; precisely the reason that SELinux uses such a fine-grained list.

This identifies an important design philosophy issue, that being what granularity is appropriate. I have no interest in composing a description of Smack at the granularity that SELinux uses.

The point you make, that you need to have that in order to create a policy description, is one of the reasons for Smack. Simplified.

Quoted 15 lines

Ok, you want sample policy to match your "MLS" sample? For convenience here's one more macro:
define(rx',r($1',$2') x($1',$2')')

type unclass;
type c;
type s;
type ts;
rx(c, unclass)
rx(s, c)
rx(s, unclass)
rx(ts, s)
rx(ts, c)
rx(ts, unclass)

In case you don't have the policy you typed into your email, it looks almost identical with a few exceptions for slightly modified syntax:

Quoted 6 lines

Quoted 6 lines

C        Unclass rx
S        C       rx
S        Unclass rx
TS       S       rx
TS       C       rx
TS       Unclass rx

Yup. Your macro invocations look very much like the Smack specification. Your macro definitions are of course unnecessary in Smack, and you really ought to be using the MLS labels SELinux supports, and you need a base policy underneath this.

Quoted 8 lines

Whoops, I think I must have smashed the delete key or something while sending. Here's the paragraphs which got elided:

Well, yes, but a policy which completely ignores future expandability can't be expanded upon regardless. It would also be very hard to add new policy without a lot of duplication under your system. On the other hand, with SELinux you can very easily add attribute-based policy so adding new capabilities is as simple as sticking existing attributes on newly defined types. For example:

type my_log_t, file_type, log_file;
type my_log_daemon, daemon;

Right there I just gave permission for the logrotate to recycle files labelled my_log_t, which the sysadmin and audit admin can also read (and the audit admin can delete). I also gave permission for my daemon to send SIGCHLD to init, and for init/initscripts to send it a SIGTERM/SIGQUIT. All without writing a SINGLE policy rule. Basically all of those existing behaviors are found in allow rules built on the "file_type", "log_file", and "daemon" attributes.

Ah, now you're refering to the reference policy, right?

Quoted 5 lines

Quoted 5 lines

They can be added or changed one by one as required while the system is running, and there are uses that exploit that. One example is to put the label "Game" on certain programs and:

at 8:00am "Worker Game no"
at 5:00pm "Worker Game x"

Quoted 5 lines

Quoted 1 line

Thus Worker processes can access Game files only during off hours.

This is fundamentally broken:
[...]
Secondly, you can already do the same thing with DAC and a PAM groups-from-time-of-day module, I don't see why such a thing is special enough to need MAC. Thirdly, I could do exactly the same thing with an SELinux boolean and a cronjob (once we get proper revoke support):

There is usually a way to address any particular problem using DAC, it's often sufficiently painful that MAC looks like a better approach.

Your boolean solution requires more forthought than the Smack rule solution, but I'll give it to you once you've fleshed out your "##" lines.

Quoted 1 line

## Rule to allow cron to tweak the "can_play_games" boolean value

Quoted 3 lines

if (can_play_games) {
## Insert game-playing allow rules here
}

Quoted 3 lines

Quoted 1 line

As far as relabeling the file system goes, the rules apply to processes and objects, not to programs. The label on a program describes who can access it, it will run with the label of the process that exec's it. A change in the rules does not require a change to the labels on the file system for things to work according to the rules of engagement.

By this logic, every program will always have the same label, unless you recode every program to explicitly change it when it starts; precisely the thing that the SELinux type transitions were designed to avoid.

Yes. This is the way it should be. A small set of very carefully analysed programs that change labels under carefully controlled circumstances is what I want. login, sshd, cron, special purpose launchers. Written with the assumption that they will be attacked.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

When you change the meaning of new types, you clearly would need to first reload the policy then relaunch programs or relabel files to take advantage of the new types, otherwise they would be categorically ignored by the system.

I'm sorry, but again, I don't know what you mean by "changing the meaning of new types".

Oh, say something like "Oh, drat, I wanted this daemon to run as some other type".

Sorry, "type" is a meaningless attribute in Smack.

Quoted 1 line

Unless you relabel the files and relaunch the daemon the system will have no idea how the system will change. And if you let arbitrary root processes relabel things on the fly then you've lost all the security advantages to a MAC system.

MAC systems have been behaving this way for decades. SELinux is the exception, not the rule on this.

Quoted 3 lines

I think you may be making assumptions about the behaviour of SELinux based on what other OSes do which don't hold:

(a) SELinux does not care about user id, current directory, time of day, etc. It cares solely about 3 things: the Subject, the Object, and the Action. For example, if an init script attempts to execute the apache binary then SELinux gets the following data for parameters: subject="system_u:system_r:initrc_t:SystemLow-SystemHigh" object="system_u:object_r:httpd_exec_t:SystemLow" action="file->execute".

Yes, and each of the components of the subject and object contexts is dependent on a more circumstances than I'd care to deal with. You've demonstrated that SELinux implements fine granularity.

Quoted 1 line

(b) SELinux does NOT have a capability which overrides it. If you want to do something that the policy categorically does not allow, you have 2 choices: change the policy or disable SELinux. You can also use a policy which disables both of those options

Yup. I think that's bad.

And Bell & LaPadula using a combination of levels and categories is probably the Smack worst case. But guess what? The dig against that policy has always been that no one wanted to combine levels and categories.

Quoted 1 line

Ok, fine, how does "moving data around a system" require anything more than bog-standard user-level privileges? Normal users under Linux are not permitted to change "security.*" attributes at all, but they may bind to sockets, etc. You can define a "capability" which lets you do all that, but then you're just blindly giving processes more privileges than they need to complete an operation. Why should you get the "rename all files" priv when all you need is "Make my log files get $LABEL when I put them in /var/log/mydaemon/"?

Privilege granularity is a seperate issue. Smack uses Linux privilege machanisms and is happy to do so.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

Why should it? Admittedly, moving data from "TopSecret" to "Secret" requires a process labeled with a range including at least "S-TS" *and* with the MLS "read-to-clearance" attribute, but you can be as stingy with that attribute as you like.

Yup. And plenty of people like you think that is really spiffy.

Please explain why you think it isn't?

I grew up believing that downgrading classified information should always be an explicit, concious act.

Quoted 9 lines

You can call them "process capabilities" or "magic attributes", they're the same thing, just more fine-grained. Instead of (Note: r1 == subject role, r2 == target role, t2 == target type):

   mlsconstrain process transition ( (r1 == r2) || (t1 ==   

i_am_a_role_changing_capability) )

you have (Note: t1 == subject type):

   mlsconstrain process transition ( (r1 == r2) || (r1 == system_r  

&& t1 == i_am_a_login_process && t2 == i_am_a_user_entrypoint) )

The latter is like the former, except instead of one single ultimate "change-any-role" capability, you have a capability which allows a system login process to change roles *ONLY* if it's also changing to a user entrypoint. Please tell me which you think is more secure.

Don't look at me. A well written program could do fine with either.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

So the implicit labeling of files actually restricts every process *FURTHER*. They no longer have even an inkling of a choice about file labeling, and that's a GOOD thing.

That's true about Smack, you know. The process has no choice about the label that the files get.

So how do you selectively label files based on criteria such as "where did I get put"? How do you distinguish between a "log file" which is create-and-append-only, a "database file" which I can modify however I want to, and a "unix socket" which I can bind in /var/run and get connections from user processes?

I don't. They're all objects.

Quoted 3 lines

Quoted 1 line

Thank you for your comments. I hope that I have made the behavior and value of Smack clearer in responding to them.

You're welcome. I endeavor to poke my nose into every little LSM-related corner in the kernel, this one included.

Why?

Quoted 1 line · Casey Schaufler

Your boolean solution requires more forthought than the Smack rule solution, but I'll give it to you once you've fleshed out your "##" lines.

How does it require more forethought? When I want to turn it on, I write and load the 5 line policy then add the cronjobs. Yours involves giving cron unconditional permission to write to your security database (always a bad idea) and then adding similar cronjobs.

Quoted 4 lines · Kyle Moffett

Quoted 1 line · Casey Schaufler

Your boolean solution requires more forthought than the Smack rule solution, but I'll give it to you once you've fleshed out your "##" lines.

How does it require more forethought? When I want to turn it on, I write and load the 5 line policy then add the cronjobs. Yours involves giving cron unconditional permission to write to your security database (always a bad idea) and then adding similar cronjobs.

nit: without the selinux policy server (which is not production ready by any means) we have to grant the same to cron in this case (or at least to the domain that cron runs the cronjobs in). SELinux and Smack alike need special permissions to modify the running policy, no surprises there.

<really big snip>

If you have no interest in categorizing the SELinux access vectors, then how do you expect to categorize the LSM hooks, which are almost 1-to-1 mapped with the SELinux access vectors?

Quoted 2 lines

The point you make, that you need to have that in order to create a policy description, is one of the reasons for Smack. Simplified.

Well yes, but a simplified policy is useless if it uses no LSM hooks.

I will write you a Perl script which will generate a complete and functionally equivalent SELinux policy (assuming I have enough free time) given a file with your policy language. But I can do this if and only if you tell me which of the SELinux access vectors you care about (In other words, which of the LSM hooks you want to require "read", "write", or "execute" privileges for). With such a little script you could write all the "simplified" policy you want, without having to change the kernel code at all.

<another major snip>

My point is your policy format is SO simple it doesn't even need the SELinux MLS code to handle it. From the way you've described it the base policy (~200 lines) would be *identical* regardless of the entries in your policy language, and the rest could be generated by a script directly from the "C Unclass rx"-type stuff.

Quoted 22 lines

Quoted 13 lines

Whoops, I think I must have smashed the delete key or something while sending. Here's the paragraphs which got elided:

Well, yes, but a policy which completely ignores future expandability can't be expanded upon regardless. It would also be very hard to add new policy without a lot of duplication under your system. On the other hand, with SELinux you can very easily add attribute-based policy so adding new capabilities is as simple as sticking existing attributes on newly defined types. For example:

type my_log_t, file_type, log_file;
type my_log_daemon, daemon;

Quoted 8 lines

Right there I just gave permission for the logrotate to recycle files labelled my_log_t, which the sysadmin and audit admin can also read (and the audit admin can delete). I also gave permission for my daemon to send SIGCHLD to init, and for init/ initscripts to send it a SIGTERM/SIGQUIT. All without writing a SINGLE policy rule. Basically all of those existing behaviors are found in allow rules built on the "file_type", "log_file", and "daemon" attributes.

Quoted 1 line

Ah, now you're refering to the reference policy, right?

Yes, precisely. For most of that functionality there are existing attributes and types defined in the reference policy to make custom policy much easier. Furthermore, there are interface files which allow me to say something like "Let this program spawn an Apache daemon in the right domain" with a single line. If I only want to do that when the "httpd" module is loaded I can put the line in an "optional" block. A policy for a basic network daemon with a couple log files, a config file, and a little database is all of 30 lines, maybe 50 if you throw in comments.

Quoted 17 lines

Quoted 9 lines

Quoted 8 lines

They can be added or changed one by one as required while the system is running, and there are uses that exploit that. One example is to put the label "Game" on certain programs and:

at 8:00am "Worker Game no"
at 5:00pm "Worker Game x"

Thus Worker processes can access Game files only during off hours.

Quoted 7 lines

This is fundamentally broken:
[...]
Secondly, you can already do the same thing with DAC and a PAM groups-from-time-of-day module, I don't see why such a thing is special enough to need MAC. Thirdly, I could do exactly the same thing with an SELinux boolean and a cronjob (once we get proper revoke support):

Quoted 2 lines

There is usually a way to address any particular problem using DAC, it's often sufficiently painful that MAC looks like a better approach.

No, generally the only reason to use MAC is when it's security- critical (system compromise, classified data, critical infrastructure, etc). Denying users access to games during the workday is hardly "security-critical". If that system's CPU time was exclusively needed for a life support machine during the day then maybe, but that's what renice or realtime scheduling are for and why the hell are you installing games on a heart monitor?

<Another big snip>

Quoted 4 lines

Yes. This is the way it should be. A small set of very carefully analysed programs that change labels under carefully controlled circumstances is what I want. login, sshd, cron, special purpose launchers. Written with the assumption that they will be attacked.

Well, under SELinux, all 3 of those processes go through the special purpose PAM module to get their labels changed. Are you planning to modify *every* daemon to have special type-changing code? Hell, most don't even have setuid/chroot support and that's all of 15 lines of code and is supported in every UNIX/Linux distro released in the last 10 years (or more). Besides, why allow the program (say, "ping") to change its own label when the policy could forcibly change it for you. The label change is NOT just to *give* permissions, it's also to take them away. For example, when I run "ping", the process gains raw network access but loses access to almost every user file and disables LD_PRELOAD, etc, making it a thousand times harder to compromise it from the inside too.

Quoted 7 lines

Quoted 4 lines

Unless you relabel the files and relaunch the daemon the system will have no idea how the system will change. And if you let arbitrary root processes relabel things on the fly then you've lost all the security advantages to a MAC system.

MAC systems have been behaving this way for decades. SELinux is the exception, not the rule on this.

"People have been burning witches for decades, that must be the right thing to do"

The fact that something is commonly done does not make it right, especially when there is a significantly more secure alternative available.

Quoted 8 lines

I will write you a Perl script which will generate a complete and functionally equivalent SELinux policy (assuming I have enough free time) given a file with your policy language. But I can do this if and only if you tell me which of the SELinux access vectors you care about (In other words, which of the LSM hooks you want to require "read", "write", or "execute" privileges for). With such a little script you could write all the "simplified" policy you want, without having to change the kernel code at all.

It's all spelled out in the module. Go wild.

Hi!

Quoted 9 lines

Quoted 8 lines

I will write you a Perl script which will generate a complete and functionally equivalent SELinux policy (assuming I have enough free time) given a file with your policy language. But I can do this if and only if you tell me which of the SELinux access vectors you care about (In other words, which of the LSM hooks you want to require "read", "write", or "execute" privileges for). With such a little script you could write all the "simplified" policy you want, without having to change the kernel code at all.

Quoted 1 line

It's all spelled out in the module. Go wild.

Kyle claims he can emulate SMACK with SELinux + perl script, but I don't think it is fair to force him to write that perl.

You want the
code merged, so it should be up to you to do the work... or acknowledge that selinux ineed is smack supperset

and argue that SMACK
is better, anyway, because of its simplicity / speed / something.

Or maybe that perl script is impossible to write for some reason? Tell us if so...

Pavel
(who is no security expert)

It would not surprise me particularly much if Kyle or someone like him could produce a perl script that could generate an SELinux policy that, when added to the reference policy on a system described by the reference policy, could do a fair imitation of the Smack scheme.

One point that I would like to make clear however is that the requirement for a 400,000 line reference policy for a jumping off point is one of the reasons for Smack.

Quoted 1 line

and argue that SMACK is better, anyway, because of its simplicity / speed / something.

My understanding of the current SELinux philosophy is that policy should only be written by professionals, and that this was "always" the intention. I respect that, and for policy that requires the level of sophistication that SELinux does I would have a hard time arguing otherwise.

One of the things that limited the widespread adoption of MLS systems was that the policy, even one as simple as Bell & LaPadula, was considered to complex for most uses. I do not see that SELinux, or AppArmor for that matter, addresses this fundimental impediment to the use of mandatory access control. Yes, you can do just about anything with the right combination of classes, booleans, and other interesting facilities, but you can't do simple things directly.

XFCE. If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner.

Quoted 1 line · Kyle Moffett

If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner.

/me hands Kyle a dunce cap. :)

Unfortunately, I have to agree that both AppArmor and Smack have at least the potential of qualifying as "securing the 2M lines of code".

The part that Kyle forgot was what most evals these days call the "protection profile" - What's the threat model, who are you defending against, and just how good a job does it have to do? I'll posit that for a computer that is (a) not networked, (b) doesn't process sensitive information, and (c) has reasonable physical security, a security policy of "return(permitted);" for everything may be quite sufficient.

(Of course, I also have boxes where "the SELinux reference policy with all the MCS extensions plus all the LSPP work" is someplace I'm trying to get to).

Quoted 12 lines · On Aug 19, 2007, at 17:12:41, [email protected] wrote:

Quoted 5 lines · Kyle Moffett

If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner.

/me hands Kyle a dunce cap. :)

Unfortunately, I have to agree that both AppArmor and Smack have at least the potential of qualifying as "securing the 2M lines of code".

Quoted 7 lines

The part that Kyle forgot was what most evals these days call the "protection profile" - What's the threat model, who are you defending against, and just how good a job does it have to do? I'll posit that for a computer that is (a) not networked, (b) doesn't process sensitive information, and (c) has reasonable physical security, a security policy of "return(permitted);" for everything may be quite sufficient.

Well, in this case the "box" I want to secure will eventually be running multi-user X on a multi-level-with-IPsec network. For that kind of protection profile, there is presently no substitute for SELinux with some X11 patches. AppArmor certainly doesn't meet the confidentiality requirements (no data labelling), and SMACK has no way of doing the very tight per-syscall security requirements we have to meet.

I didn't make this clear initially but that is the kind of system I'm talking about wanting to secure some 50 million lines of code on.

Quoted 3 lines

(Of course, I also have boxes where "the SELinux reference policy with all the MCS extensions plus all the LSPP work" is someplace I'm trying to get to).

Well, for some of the systems we distribute, "all the MCS extensions plus all the LSPP work" is nowhere near enough security; we need full- fledged multi-level-security, role-based-access-control, and specific per-daemon MAC restrictions.

Quoted 1 line · --- Kyle Moffett

Well, in this case the "box" I want to secure will eventually be running multi-user X on a multi-level-with-IPsec network. For that kind of protection profile, there is presently no substitute for SELinux with some X11 patches. AppArmor certainly doesn't meet the confidentiality requirements (no data labelling), and SMACK has no way of doing the very tight per-syscall security requirements we have to meet.

And what requirements would those be? Seriously, I've done Common Criteria and TCSEC evaluations on systems with less flexibility and granularity than Smack that included X, NFSv3, NIS, clusters, and all sorts of spiffy stuff.

I mean, if the requirement is anything short of "runs SELinux" I have good reason to believe that a Smack based system is up to it.

Quoted 1 line

I didn't make this clear initially but that is the kind of system I'm talking about wanting to secure some 50 million lines of code on.

Cool. SELinux provides one approach to dealing with that, and the huge multiuser general purpose machine chuck full of legacy software hits the SELinux sweet spot.

Quoted 1 line

but you written it in wrong language. You written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend).

I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around.

Quoted 9 lines · Casey Schaufler

Quoted 7 lines · --- Kyle Moffett

Well, in this case the "box" I want to secure will eventually be running multi-user X on a multi-level-with-IPsec network. For that kind of protection profile, there is presently no substitute for SELinux with some X11 patches. AppArmor certainly doesn't meet the confidentiality requirements (no data labelling), and SMACK has no way of doing the very tight per-syscall security requirements we have to meet.

Quoted 4 lines

And what requirements would those be? Seriously, I've done Common Criteria and TCSEC evaluations on systems with less flexibility and granularity than Smack that included X, NFSv3, NIS, clusters, and all sorts of spiffy stuff.

These are requirements more of the "give the client warm fuzzies".

On the other hand, when designing a box that could theoretically be run on a semi-public unclassified network and yet still be safe enough to run classified data over IPsec links, you want to give the client all the warm fuzzies they ask for and more.

Quoted 2 lines

I mean, if the requirement is anything short of "runs SELinux" I have good reason to believe that a Smack based system is up to it.

"up to it", yes, but I think you'll find that beyond the simplest policies, an SELinux policy that properly uses the SELinux infrastructure will be much shorter than the equivalent SMACK policy,

not even including all the things that SELinux does and SMACK doesn't.

Quoted 6 lines

Quoted 2 lines

I didn't make this clear initially but that is the kind of system I'm talking about wanting to secure some 50 million lines of code on.

Cool. SELinux provides one approach to dealing with that, and the huge multiuser general purpose machine chuck full of legacy software hits the SELinux sweet spot.

Well, given that 99.9% of the systems people are really concerned about security on are multi-user general-purpose machines chuck full of legacy software, that seems to work just fine.

If it's a single-
user box then you don't even need MAC, just a firewall, a good locked rack/case/keyboard/etc, and decent physical security.

If it's
entirely custom-controlled software then you can just implement the "MAC" entirely in your own software. "General-purpose" vs "special- purpose" is debatable, so I'll just leave that one lie.

Replying to another email:

Quoted 7 lines

Quoted 3 lines

but you written it in wrong language. You written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend).

I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around.

There is no "one answer" to this question in software development.

Generally you prioritize things based on maximizing maintainability and speed and minimizing code, bugs, and complexity. Those are often both conflicting and in agreement. Here are a few common examples of simple-thing-on-complex-thing:
...

Look at the SELinux model again; it has the following things:
(A) Labels on almost-all user-visible kernel objects
(B) Individual access rules for almost every operation on those
objects
(C) "Transition" rules to set the label on newly created objects.
(D) Fundamental "constraints" which enforce hard limits on what
may be permitted with "allow" rules

From a fundamental standpoint it's harder to get much simpler than
that.

On top of that model, we also have a bit of additional
*flexibility* for MLS/RBAC, although that flexibility may be ignored completely.
(1) You can define "users" which may only assume some "roles"
(2) You can define "roles" may only run in some "types"
(3) There's a simple way of declaring multiple "levels" and
"dominance".

So you see, SELinux is a pretty fundamental description of the degrees of flexibility needed to secure everything. That kind of FUNDAMENTAL description is what belongs in the kernel. Anything else can and should be built on top with better libraries and/or user interfaces.

As for the script, I'm partway through debugging it but my time is all chewed up with other stuff now, so it may take me an extra couple days.

...

As for the script, I'm partway through debugging it but my time is all chewed up with other stuff now, so it may take me an extra couple days.

Finally moved back in and with internet. Yay!

Quoted 5 lines · Casey Schaufler

It would not surprise me particularly much if Kyle or someone like him could produce a perl script that could generate an SELinux policy that, when added to the reference policy on a system described by the reference policy, could do a fair imitation of the Smack scheme.

Umm, when did I ever say "emulate smack on top of the reference policy"? I state categorically that I can write an estimated 500 line perl script which will generate a standalone SELinux policy based directly on a smack ruleset.

It would require no additional
policy beyond what the script outputs, and the script would be only roughly 500 lines so it can't contain all that much direct source-to- output text.

I've started tinkering with that perl script, though I probably won't get it finished till tomorrow or sunday.

Quoted 3 lines

One point that I would like to make clear however is that the requirement for a 400,000 line reference policy for a jumping off point is one of the reasons for Smack.

There is no "requirement" for a 400,000-line reference policy to reproduce exactly the behavior of SMACK. The SMACK architecture is trivial

and therefore the SELinux policy is also simple.

Quoted 8 lines

Quoted 2 lines

and argue that SMACK is better, anyway, because of its simplicity / speed / something.

My understanding of the current SELinux philosophy is that policy should only be written by professionals, and that this was "always" the intention. I respect that, and for policy that requires the level of sophistication that SELinux does I would have a hard time arguing otherwise.

I can also state categorically that given the set of all admins, users, and software developers, hardly a fraction of them are qualified to write security policy at all.

Hell, most admins and
software developers can't get SUID binaries right,

and that's a
thousand times simpler than a MAC security policy.

Ergo the only
people who should be writing security policy for deployment are those people who have studied and trained in the stuff. Those people are also known as "security professionals".

Quoted 7 lines

One of the things that limited the widespread adoption of MLS systems was that the policy, even one as simple as Bell & LaPadula, was considered to complex for most uses. I do not see that SELinux, or AppArmor for that matter, addresses this fundimental impediment to the use of mandatory access control. Yes, you can do just about anything with the right combination of classes, booleans, and other interesting facilities, but you can't do simple things directly.

Neither security nor your average distro nowadays is "simple" by any stretch of the imagination. Hell, my desktop system hits at least 2 million unique lines of code during boot, let alone logging in to XFCE. If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner.

Quoted 4 lines

Ergo the only
people who should be writing security policy for deployment are those people who have studied and trained in the stuff. Those people are also known as "security professionals".

If only security professionals can use the system you have failed to provide a general purpose facility. It may have value in limited circumstances but it is not for everybody.

Hi!

Quoted 5 lines

Quoted 4 lines

Ergo the only
people who should be writing security policy for deployment are those people who have studied and trained in the stuff. Those people are also known as "security professionals".

Quoted 3 lines

If only security professionals can use the system you have failed to provide a general purpose facility. It may have value in limited circumstances but it is not for everybody.

But that's okay. Maybe SElinux is not simple enough to use for everyone, but that does not mean you can't auto-generate policy from something else, "easy to understand". IOW smack may be great idea,

but you written it in wrong language. You
written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend).

Quoted 4 lines

but you written it in wrong language. You
written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend).

I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around.

Quoted 8 lines

Quoted 4 lines

but you written it in wrong language. You
written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend).

I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around.

As we have to maintain selinux, anyway, I don't see why simplification layer is a problem.

Quoted 2 lines

As we have to maintain selinux, anyway, I don't see why simplification layer is a problem.

It's an issue if you want to do simple things, have the resources to do simple things, but go over budget because the simple things are built on top of complex things that you don't need. I see this crop up frequently with IT infrastructures, where simple problems get solved using completely unnecessary components just because those components are available.

   "*" - pronounced "star"

"_" - pronounced "floor"

   "^" - pronounced "hat"

   "?" - pronounced "huh"

+/*
+ * 'ssssssss oooooooo mmmm\n\0'
+ */

security/smack/smackfs.c +4 -0

+struct inode_smack *new_inode_smack(smack_t smack)
+{
+	struct inode_smack *isp;
+

security/smack/smackfs.c +30 -0

+
+static int smack_task_kill(struct task_struct *p, struct siginfo *info,
+			   int sig, u32 secid)
+{
+	smack_t *tsp = smk_of_task(p);
+	int rc;
+
+	/*
+	 * Sending a signal requires that the sender
+	 * can write the receiver.
+	 */
+	rc = smk_curacc(tsp, MAY_WRITE);
+
+	return rc;
+}
+
+static int smack_sb_statfs(struct dentry *dentry)
+{
+	struct superblock_smack *sbp;
+
+	if (dentry == NULL || dentry->d_sb == NULL ||
+	    dentry->d_sb->s_security == NULL)
+		return 0;
+
+	sbp = dentry->d_sb->s_security;
+
+	return smk_curacc(&sbp->smk_floor, MAY_READ);
+}
 
+/*
+ * Inode hooks

Quoted 2 lines · Casey Schaufler

   "*" - pronounced "star"

wall

Quoted 1 line

"_" - pronounced "floor"

floor

Quoted 1 line

   "^" - pronounced "hat"

roof

Quoted 1 line

   "?" - pronounced "huh"

it's dark in here :)

security/smack/Kconfig line 3

Quoted 3 lines

security/smack/Kconfig +3 -0

+config SECURITY_SMACK
+	bool "Simplified Mandatory Access Control Kernel Support"
+	depends on NETLABEL && SECURITY_NETWORK

Is this a hard dependency, or can this work without network sec labels?

security/smack/Kconfig line 9

Quoted 6 lines

security/smack/Kconfig +6 -0

+	default n
+	help
+	  This selects the Simplified Mandatory Access Control Kernel.
+	  SMACK is useful for sensitivity, integrity, and a variety
+          of other madatory security schemes.
+	  If you are unsure how to answer this question, answer N.

I smell broken tabs.

security/smack/Makefile line 7

Quoted 9 lines

+++ linux-2.6.22/security/smack/Makefile 2007-07-10 01:08:05.000000000 -0700

security/smack/Makefile +7 -0

@@ -0,0 +1,8 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o

smack-objs :=

Review line 8

Quoted 1 line

(quoted diff) +1 -0

+++ linux-2.6.22/security/smack/smack_access.c	2007-07-24 15:36:18.000000000

-0700

security/smack/smack_access.c line 5

Quoted 6 lines

security/smack/smack_access.c +5 -0

@@ -0,0 +1,113 @@
+extern struct smk_list_entry *smack_list;
+
+static int smk_get_access(smack_t sub, smack_t obj)
+{
+	struct smk_list_entry *sp = smack_list;

proposes const struct. should be used elsewhere too.

security/smack/smack_access.c line 43

Quoted 1 line

security/smack/smack_access.c +1 -0

+	if (sub == SMK_STAR)

I just remember MechWarrior2 (game from Activison), where SMK stood for their movie format... it's also a nice abbreviation for Seamonkey (browser suite).

security/smack/smack_access.c line 64

Quoted 5 lines

security/smack/smack_access.c +5 -0

+	if (sub == SMK_HAT && ((request & MAY_ANYREAD) == request))
+		return 0;
+
+	if (obj == SMK_FLOOR && ((request & MAY_ANYREAD) == request))
+		return 0;

Redundant parentheses, be gone.

Never was it easier to say what ^ is called in your language :)

	if (sub == '^' && ...)
		return 0;
	if (obj == '_' && ...)

security/smack/smack_access.c line 100

Quoted 7 lines

security/smack/smack_access.c +7 -0

+/*
+ * The value that this adds is that everything after any
+ * character that's not allowed in a smack will be null
+ */
+smack_t smk_from_string(char *str)
+{
+	smack_t smack = 0LL;

"smack_t smack = 0;" is enough here.

security/smack/smack_access.c line 104

Quoted 4 lines

security/smack/smack_access.c +4 -0

+	char *cp;
+	int i;
+
+	for (cp = (char *)&smack, i = 0; i < sizeof(smack_t); str++,cp++,i++) {

Whatever it tries to do, this is not endian-safe. Except if @str actually points to another smack_t. Yuck.

Quoted 10 lines

security/smack/smack_access.c +9 -0

+		if (*str <= ' ' || *str > '~')
+			return smack;
+		*cp = *str;
+	}
+	/*
+	 * Too long.
+	 */
+	return SMK_INVALID;
+}

diff -uprN -X linux-2.6.22-base/Documentation/dontdiff

linux-2.6.22-base/security/smack/smackfs.c
linux-2.6.22/security/smack/smackfs.c

Quoted 1 line

--- linux-2.6.22-base/security/smack/smackfs.c 1969-12-31 16:00:00.000000000

-0800

Quoted 1 line

+++ linux-2.6.22/security/smack/smackfs.c 2007-07-24 21:51:30.000000000

-0700

Can't securityfs and/or sysfs be used?

Quoted 5 lines

security/smack/smackfs.c +5 -0

+enum smk_inos {
+	SMK_ROOT_INO =	2,
+	SMK_LOAD =	3,	/* load policy */
+	SMK_LINKS = 	4,	/* symlinks */
+	SMK_CIPSO = 	5,	/* load label -> CIPSO mapping */

security/smack/smackfs.c line 42

Quoted 6 lines

security/smack/smackfs.c +6 -0

+	SMK_DOI = 	6,	/* CIPSO DOI */
+	SMK_DIRECT = 	7,	/* CIPSO level indicating direct label */
+	SMK_AMBIENT = 	8,	/* internet ambient label */
+	SMK_NLTYPE = 	9,	/* label scheme to use by default */
+	SMK_TMP =	100,	/* MUST BE LAST! /smack/tmp */
+};

Generally, =s are aligned too.

security/smack/smackfs.c line 70

Quoted 6 lines

security/smack/smackfs.c +6 -0

+static struct smk_cipso_entry smack_cipso_floor = {
+        .smk_next = NULL,
+        .smk_smack = SMK_FLOOR,
+        .smk_level = 0,
+        .smk_catset = 0LL,
+};

const me.

Quoted 3 lines

+/*
+ * 'ssssssss oooooooo mmmm\n\0'
+ */

I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t). uhm.. are you trying to tell me that smack_t [typedef'ed to u64] are actually meant as a char[8]? (/me scrathces head)

security/smack/smackfs.c line 104

Quoted 4 lines

security/smack/smackfs.c +4 -0

+	for (cp = result; slp != NULL; slp = slp->smk_next) {
+		srp = &slp->smk_rule;
+		sprintf(cp, "%-8s %-8s",
+			(char *)&srp->smk_subject, (char *)&srp->smk_object);

I like (const char *).

Review

Quoted 2 lines

(quoted diff) +2 -0

+			printk("%s:%d bad scan\n",
+				__FUNCTION__, __LINE__);

__FUNCTION__ is a GNU extension, C99 uses __func__.

Not sure what they've got for __LINE__.

security/smack/smackfs.c line 224

Quoted 8 lines

security/smack/smackfs.c +8 -0

+		if (strchr(modestr, 'r') || strchr(modestr, 'R'))
+			rule.smk_access |= MAY_READ;
+		if (strchr(modestr, 'w') || strchr(modestr, 'W'))
+			rule.smk_access |= MAY_WRITE;
+		if (strchr(modestr, 'x') || strchr(modestr, 'X'))
+			rule.smk_access |= MAY_EXEC;
+		if (strchr(modestr, 'a') || strchr(modestr, 'A'))
+			rule.smk_access |= MAY_APPEND;

There's strpbrk() available for you.

security/smack/smackfs.c line 249

Quoted 8 lines

security/smack/smackfs.c +8 -0

+static char *smk_digit(char *cp)
+{
+	for (; *cp != '\0'; cp++)
+		if (*cp >= '0' && *cp <= '9')
+			return cp;
+
+	return NULL;
+}

strpbrk again.

security/smack/smackfs.c line 252

Quoted 2 lines

security/smack/smackfs.c +2 -0

+static int smk_cipso_doied;
+static int smk_cipso_written;

Votes for unsigned int if it {can never be, is not intended to be} negative.

security/smack/smackfs.c line 329

Quoted 3 lines

security/smack/smackfs.c +3 -0

+	for (slp = smack_cipso; slp != NULL; slp = slp->smk_next) {
+		sprintf(cp, "%-8s %3d", (char *)&slp->smk_smack,slp->smk_level);
+		cp += strlen(cp);

sprintf returns the number of bytes it has written, so

	cp += sprintf(cp, ...)

might be used. [Can sprintf even return -1 here?]

Review

Quoted 1 line

(quoted diff) +1 -0

+	*(data + count) = '\0';

data[count] = '\0';

security/smack/smackfs.c line 490

Quoted 8 lines

security/smack/smackfs.c +8 -0

+	char temp[80];
+	ssize_t rc;
+
+	if (*ppos != 0)
+		return 0;
+
+	sprintf(temp, "%d", smk_cipso_doi_value);
+	rc = simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));

80 is plenty for a 11 char string.

Look, they've got funny ideas! :) net/ipv4/netfilter/nf_nat_irc.c:char buffer[sizeof("4294967296 65635")];

security/smack/smackfs.c line 631

Quoted 13 lines

security/smack/smackfs.c +13 -0

+static struct option_names netlbl_choices[] = {
+	{ NETLBL_NLTYPE_RIPSO,
+		NETLBL_NLTYPE_RIPSO_NAME,	"ripso" },
+	{ NETLBL_NLTYPE_CIPSOV4,
+		NETLBL_NLTYPE_CIPSOV4_NAME,	"cipsov4" },
+	{ NETLBL_NLTYPE_CIPSOV4,
+		NETLBL_NLTYPE_CIPSOV4_NAME,	"cipso" },
+	{ NETLBL_NLTYPE_CIPSOV6,
+		NETLBL_NLTYPE_CIPSOV6_NAME,	"cipsov6" },
+	{ NETLBL_NLTYPE_UNLABELED,
+		NETLBL_NLTYPE_UNLABELED_NAME,	"unlabeled" },
+};
+#define NCHOICES (sizeof(netlbl_choices) / sizeof(struct option_names))

ARRAY_SIZE()..

security/smack/smackfs.c line 650

Quoted 3 lines

security/smack/smackfs.c +3 -0

+	for (i = 0; i < NCHOICES; i++)
+		if (smack_net_nltype == netlbl_choices[i].o_number) {
+			sprintf(bound, "%s", netlbl_choices[i].o_name);

looks dangerous; to overflow.

security/smack/smackfs.c line 685

Quoted 3 lines

security/smack/smackfs.c +3 -0

+	for (i = 0; i < NCHOICES; i++)
+		if ((strcmp(bound, netlbl_choices[i].o_name) == 0) ||
+		    (strcmp(bound, netlbl_choices[i].o_alias) == 0)) {

redundant ()

security/smack/smackfs.c line 704

Quoted 2 lines

security/smack/smackfs.c +2 -0

+#define SMK_TMPPATH_SIZE        32
+#define SMK_TMPPATH_ROOT        "/moldy/"

What is going to be mold?

Review

Quoted 2 lines

(quoted diff) +2 -0

+	if (slp == NULL) {
+		printk("%s:%d failed\n", __FUNCTION__, __LINE__);

KERN_<level> is missing. (Check other places too)

security/smack/smack_lsm.c line 37

Quoted 11 lines

security/smack/smack_lsm.c +9 -0

+#define SMK_MAXLEN	(sizeof(smack_t) - 1)	/* NULL terminated */
 
+
+/*
+ * I hope these are the hokeyist lines of code in the module. Casey.
+ */
+#define DEVPTS_SUPER_MAGIC	0x1cd1
+#define SOCKFS_MAGIC		0x534F434B
+#define PIPEFS_MAGIC		0x50495045
+#define TMPFS_MAGIC		0x01021994

Try moving them to linux/magic.h.

security/smack/smack_lsm.c line 45

Quoted 3 lines

security/smack/smack_lsm.c +3 -0

+extern int smack_net_nltype;
+extern int smack_cipso_direct;
+extern struct smk_cipso_entry *smack_cipso;

for consistency reasons, add extern to the other vars too...

Quoted 8 lines

security/smack/smack_lsm.c +8 -0

+struct inode_smack *new_inode_smack(smack_t smack)
+{
+	struct inode_smack *isp;
+
+        isp = kzalloc(sizeof(struct inode_smack), GFP_KERNEL);
+        if (isp == NULL)
+                return NULL;
+

security/smack/smack_lsm.c line 85

Quoted 6 lines

security/smack/smack_lsm.c +6 -0

+	isp->smk_inode = smack;
+	isp->smk_flags = 0;
+	mutex_init(&isp->smk_lock);
+
+	return isp;
+}

Tabs or so.

security/smack/smack_lsm.c line 197

Quoted 7 lines

security/smack/smack_lsm.c +7 -0

+static int smack_task_movememory(struct task_struct *p)
+{
+	int rc;
+
+	rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+	return rc;
+}

Uh...

{
	return smk_curacc(smk_of_task(p), MAY_WRITE);
}

(also others)

Quoted 28 lines

security/smack/smack_lsm.c +28 -0

+
+static int smack_task_kill(struct task_struct *p, struct siginfo *info,
+			   int sig, u32 secid)
+{
+	smack_t *tsp = smk_of_task(p);
+	int rc;
+
+	/*
+	 * Sending a signal requires that the sender
+	 * can write the receiver.
+	 */
+	rc = smk_curacc(tsp, MAY_WRITE);
+
+	return rc;
+}
+
+static int smack_sb_statfs(struct dentry *dentry)
+{
+	struct superblock_smack *sbp;
+
+	if (dentry == NULL || dentry->d_sb == NULL ||
+	    dentry->d_sb->s_security == NULL)
+		return 0;
+
+	sbp = dentry->d_sb->s_security;
+
+	return smk_curacc(&sbp->smk_floor, MAY_READ);
+}

security/smack/smack_lsm.c line 394

Quoted 12 lines

security/smack/smack_lsm.c +12 -0

+/*
+ * Inode hooks
+ */
+static int smack_inode_alloc_security(struct inode *inode)
+{
+	smack_t *csp = smk_of_task(current);
+
+        inode->i_security = new_inode_smack(*csp);
+        if (inode->i_security == NULL)
+                return -ENOMEM;
+	return 0;
+}

Tabz.

Quoted 1 line

+static int smack_inode_init_security(struct inode *inode, struct inode

*dir,

security/smack/smack_lsm.c line 411

Quoted 9 lines

security/smack/smack_lsm.c +9 -0

+                               char **name, void **value, size_t *len)
+{
+	smack_t *isp = smk_of_inode(inode);
+
+	if (name && (*name = kstrdup(XATTR_SMACK_SUFFIX, GFP_KERNEL)) == NULL)
+		return -ENOMEM;
+
+	if (value && (*value = kstrdup((char *)isp, GFP_KERNEL)) == NULL)
+		return -ENOMEM;

Try not to do big assignments in if.

security/smack/smack_lsm.c line 585

Quoted 4 lines

security/smack/smack_lsm.c +4 -0

+static const char *smack_inode_xattr_getsuffix(void)
+{
+	return XATTR_SMACK_SUFFIX;
+}

inline it, or opencode.

security/smack/smack_lsm.c line 639

Quoted 9 lines

security/smack/smack_lsm.c +9 -0

+static int smack_inode_setsecurity(struct inode *inode, const char *name,
+				   const void *value, size_t size, int flags)
+{
+	smack_t smack;
+	smack_t *isp = smk_of_inode(inode);
+	struct socket_smack *ssp;
+	struct socket *sock;
+	struct super_block *sbp;
+	struct inode *ip = (struct inode *)inode;

This cast is really pointless.

security/smack/smack_lsm.c line 677

Quoted 2 lines

security/smack/smack_lsm.c +2 -0

+static int smack_inode_listsecurity(struct inode *inode, char *buffer,
+				    size_t buffer_size)

Whitespace broken.

[attention span ran out]

Nice.

Quoted 10 lines

security/smack/Makefile line 7

Quoted 8 lines

security/smack/Makefile +7 -0

@@ -0,0 +1,8 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o

smack-objs :=

Added.

Quoted 7 lines

security/smack/smackfs.c line 80

Quoted 3 lines

security/smack/smackfs.c +3 -0

+/*
+ * 'ssssssss oooooooo mmmm\n\0' 
+ */

I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t). uhm.. are you trying to tell me that smack_t [typedef'ed to u64] are actually meant as a char[8]? (/me scrathces head)

Yes. "s == o" vs "strcmp(s,o) == 0".

Quoted 11 lines

security/smack/smackfs.c line 490

Quoted 8 lines

security/smack/smackfs.c +8 -0

+	char temp[80];
+	ssize_t rc;
+
+	if (*ppos != 0)
+		return 0;
+
+	sprintf(temp, "%d", smk_cipso_doi_value);
+	rc = simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));

80 is plenty for a 11 char string.

Quoted 2 lines

Look, they've got funny ideas! :) net/ipv4/netfilter/nf_nat_irc.c:char buffer[sizeof("4294967296 65635")];

Quoted 5 lines

security/smack/smack_lsm.c line 45

Quoted 3 lines

security/smack/smack_lsm.c +3 -0

+extern int smack_net_nltype;
+extern int smack_cipso_direct;
+extern struct smk_cipso_entry *smack_cipso;

for consistency reasons, add extern to the other vars too...

the others?

Quoted 10 lines

security/smack/smack_lsm.c line 197

Quoted 7 lines

security/smack/smack_lsm.c +7 -0

+static int smack_task_movememory(struct task_struct *p)
+{
+	int rc;
+
+	rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+	return rc;
+}

Uh...

Quoted 5 lines

{
	return smk_curacc(smk_of_task(p), MAY_WRITE);
}

(also others)

That was a little excessive, wasn't it?

Quoted 6 lines

Quoted 6 lines

security/smack/smack_lsm.c +6 -0

+static int smack_task_kill(struct task_struct *p, struct siginfo *info,
+			   int sig, u32 secid)
+{
+	smack_t *tsp = smk_of_task(p);
+	int rc;
+

Quoted 8 lines

security/smack/smack_lsm.c line 212

Quoted 8 lines

security/smack/smack_lsm.c +8 -0

+	/*
+	 * Sending a signal requires that the sender
+	 * can write the receiver.
+	 */
+	rc = smk_curacc(tsp, MAY_WRITE);
+
+	return rc;
+}

Quoted 14 lines

Quoted 14 lines

security/smack/smack_lsm.c line 197

Quoted 7 lines

security/smack/smack_lsm.c +7 -0

+static int smack_task_movememory(struct task_struct *p)
+{
+	int rc;
+
+	rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+	return rc;
+}

Uh...

{
	return smk_curacc(smk_of_task(p), MAY_WRITE);
}

Quoted 3 lines

Quoted 1 line

(also others)

That was a little excessive, wasn't it?

How do you mean? I was just suggesting to collapse the three [four] lines into
one, getting rid of the tempotemporaries in a lot of these functions, for example,

Smack is the Simplified Mandatory Access Control Kernel.

Quoted 1 line · Casey Schaufler

Smack is the Simplified Mandatory Access Control Kernel.

I like the simplified part.

security/smack/smack_access.c line 27

Quoted 8 lines

security/smack/smack_access.c +8 -0

+static int smk_get_access(smack_t sub, smack_t obj)
+{
+	struct smk_list_entry *sp = smack_list;
+
+	for (; sp != NULL; sp = sp->smk_next)
+		if (sp->smk_rule.smk_subject == sub &&
+		    sp->smk_rule.smk_object == obj)
+			return sp->smk_rule.smk_access;

Do I miss something, or is there really no locking for the reader side of the list? That looks dangerous. Of course a global lock for readers would be likely a scaling disaster. You could use RCU.

Or if you assume rules are changed only very infrequently it might be more cache friendly to compile all the rules into a linear buffer and then just replace the whole buffer atomically with a RCU grace period on cahnges.

It doesn't look like it would scale to larger numbers of rules though. Is that intended? Would caching of decisions fit into the design?

Also in general code style would need some improvements; e.g. no externs in .c; no ../.. include hacks etc. You also seem weak on the Documentation front.

Other than that it looks reasonably clean (haven't read all of it)

Entries are never deleted, although they can be modified.

Quoted 1 line

Entries are never deleted, although they can be modified.

The modification case still seems racy then.

Quoted 3 lines · --- Andi Kleen

Quoted 1 line

Entries are never deleted, although they can be modified.

The modification case still seems racy then.

Fair enough. I'll look into real list management.

Quoted 8 lines · Casey Schaufler

Quoted 3 lines · --- Andi Kleen

Quoted 1 line

Entries are never deleted, although they can be modified.

The modification case still seems racy then.

Fair enough. I'll look into real list management.

You don't necessarily need more list management if you don't plan to remove entries, but just replace them.

e.g. what could work to atomically replace is:

- Make the buffer a pointer to an allocated buffer that also contains a struct rcu_head.
- Reader: Does rcu_read_lock() around list walk (that just disables preemption on preemptible kernels and is otherwise a nop). Also uses rcu_reference for reading the pointer.
- Writer: Continues using the mutex to protect against other writers. When changing an entry allocate a new buffer + rcu_head. Initialize buffer. Replace pointer. Free old buffer using call_rcu()

The RCU would just make sure the buffer is not freed while other CPUs are still accessing it. It also means they can use stale rules for a time, but it is a strictly bounded time (bounded to max time walking the list plus max time any interrupt handlers inbetween run [admittedly that can be very long in theory, but it's all logically only a single rule check])

Smack is the Simplified Mandatory Access Control Kernel.

[snip]

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.

Quoted 13 lines · Casey Schaufler (on Sat, 11 Aug 2007 10:57:31 -0700) wrote:

Smack is the Simplified Mandatory Access Control Kernel.

[snip]

Smack defines and uses these labels:

   "*" - pronounced "star"
   "_" - pronounced "floor"
   "^" - pronounced "hat"
   "?" - pronounced "huh"

The access rules enforced by Smack are, in order:

Quoted 11 lines

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.

Some security systems that have the concept of "no default access" (task labeled "*") also allow access by those tasks but only if there is an explicit rule giving access to the task. IOW, rule 6 is applied before rule 1. In my experience this simplifies special cases where a task should only have access to a very small set of resources. I'm curious why smack goes the other way?