From: Casey Schaufler <casey@schaufler-ca.com>

Smack is the Simplified Mandatory Access Control Kernel.

Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC,
and other tasks. Smack is a kernel based scheme that requires
an absolute minimum of application support and a very small
amount of configuration data.

Smack is implemented as a clean LSM. It requires no external
code changes and the patch modifies only the Kconfig and Makefile
in the security directory. Smack uses extended attributes and
provides a set of general mount options, borrowing technics used
elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides
a pseudo-filesystem smackfs that is used for manipulation of
system Smack attributes.

Smack provides mandatory access controls based on the label attached
to a task and the label attached to the object it is attempting to
access. Smack labels are deliberately short (1-7 characters) text
strings. Single character labels using special characters are reserved
for system use. The only operation applied to Smack labels is equality
comparison. No wildcards or expressions, regular or otherwise, are
used.

A file always gets the Smack label of the task that created it.

Smack defines and uses these labels:

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

The access rules enforced by Smack are, in order:

1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^"
   is permitted.
3. A read or execute access requested on an object labeled "_"
   is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same
   label is permitted.
6. Any access requested that is explicitly defined in the loaded
   rule set is permitted.
7. Any other access is denied.

Rules may be explicitly defined by ...
[ message continues ]

> +extern struct smk_list_entry *smack_list;





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



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



-

[ message continues ]

The list.h mechanisms are fine, but heavier than I require.

Paul Moore, the developer of netlabel, promised to work out
the right solution for this with me at a future date. He


It's really early in start-up and if you're out of memory at that


Yup.

Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

foo.c has

#include "netlabel_domainhash.h"

Makefile has CFLAGS_foo.o += -I$(srctree)/net/netlabel

I prefer to use -I $(srctree)/net/netlabel for readability but '-I '
breaks on SuSE builds for some reason that I cannot be bothered working

Not to mention that you might end up running with an insecure system.
Security must be failsafe.

-

[ message continues ]

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... ##
')



## 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)

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

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

bool foo_can_do_logging true;
if ...
[ message continues ]

I am not going to argue that SELinux is not a capable
labelling system. SELinux is a fine implementation of




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

I would be interested to see the attempt made, but I have no interest
in doing so myself. I think that some of the reasons will come out

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




Maybe. It would at least be educational for comparisons by those


And that's a good thing, but you still have to compile and reload


The MLS systems of the 1990s did that, and having done MLS X
myself I can assure you that although it has an interesting
set of issues to address (object definition in particular)
and a programming model that is very different from the kernel




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

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


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

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  

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  

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  

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  ...
[ message continues ]

Err, that wasn't the claim I was refuting. I was refuting the claim
that performing those actions required complexity. The claim I was
refering to said nothing about any of those features or anything about

That's fine, but hardly relevent to the fact that the 1990's systems

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.

I will be happy to consider your arguement when you are willing


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.

I don't. Accept happens after a TCP connection has been established.
The access control is all mediated long before the accept'er finds

There certainly isn't in SELinux. I don't subscribe the the list
of SELinux object classes. We can argue a long time over whether a
socket is an object or not, and it won't help any real world application

Well, I'm interested in seeing the actual code, not "the same kind


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

I'm sorry, but again, I don't know what you mean by "changing the

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

Heavens, I should ...
[ message continues ]

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


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  

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  

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  

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  ...
[ message continues ]

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.

I respect the design decisions that SELinux has made regarding

Heaven forbid I should put all those firewall writers out of work.

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


That's why it's never a good idea to teach the Pointy Haired One

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

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


MAC systems have been behaving this way for decades. SELinux is


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.


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


Privilege granularity is a seperate issue. Smack uses Linux

I grew up believing that downgrading classified information






Why?


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

It isn't even an exclusive decision: both design points can be "right",
but aimed at different use cases. Which is why LSM exists, so users can
decide on an appropriate mechanism.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor

-

[ message continues ]

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

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,  

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  

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,  

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  

How does it require more forethought?  When I want to turn it on, I  
write ...
[ message continues ]

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.

-

[ message continues ]

Yeah, I figured this out a couple minutes ago.  Turns out you can get  
a similar effect with a little properly labeled shell script though  
(text included in my last email), but it does decrease overall system  
security.

Cheers,
Kyle Moffett

-

[ message continues ]

Those that refer to object accesses and those that do not. The former
are generally interesting, the latter are generally not. That's a
rule of thumb, mind you. Anyway, have a look at the hook table, it's

As above, that's smack_lsm.c, a little over 2000 lines of good old




HeeHee. Don't think heart monitor, think in-car trip recorder.
The games can only be used when the car's at rest. It's a strange

I don't think we're debating the same issues any more. I can see
that you are well versed in the nuances of SELinux behavior. I
understand what SELinux does, and the arguements in it's favor.
I don't see that the complexity it requires is necessary in many

That sword cuts both ways, you know. And if a complex system
is intractable for an environment it cannot make you feel 
more secure.

I think that below here it's all philosophical differences based
on significantly different experiance and goals. Can you run
SELinux successfully on an 2 megahertz ARM processor with 8 meg
of ram, and no labeled file systems? I don't know that Smack
will ever be as appropriate for an enterprise server as SELinux is
today, but time will tell.




Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

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)

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-

[ message continues ]

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. Another point that I
think is important, and the rationale behind my being a butt
on this (sorry, Kyle, I knew some one would come after me like
this, I wasn't aiming at you) is that I have seen several cases
where the flexability and capability of SELinux policy has been
asserted but the followthrough was missing. I am interested in
seeing what an SELinux policy to do what Smack does would look
like. I personally though it would be easier to write an LSM

I acknowledge that I do not know how to prove that there is no
way, using any and all of the facilities of SELinux, to duplicate
any particular facility of Smack.

I do not acknowledge it as a superset. I am not convinced that
all of the proposed SELinux eqivalence claims would actually

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.

I was actually quite pleased to see the beginings of an ...
[ message continues ]

Btw, at:

diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/smack/Kconfig
linux-2.6.22/security/smack/Kconfig
--- linux-2.6.22-base/security/smack/Kconfig    1969-12-31
16:00:00.000000000 -0800
+++ linux-2.6.22/security/smack/Kconfig 2007-07-10 01:08:05.000000000 -0700
@@ -0,0 +1,10 @@
+config SECURITY_SMACK
+       bool "Simplified Mandatory Access Control Kernel Support"
+       depends on NETLABEL && SECURITY_NETWORK
+       default n
+       help
+         This selects the Simplified Mandatory Access Control Kernel.
+         SMACK is useful for sensitivity, integrity, and a variety
+          of other madatory security schemes.
+         If you are unsure how to answer this question, answer N.
+

change:

+          of other madatory security schemes.

to:

+          of other mandatory security schemes.

-- 
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm
-

[ message continues ]

Finally moved back in and with internet.  Yay!


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  

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

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  

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.


Cheers,
Kyle Moffett



-

[ message continues ]

/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).
[ message continues ]

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  

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.

Cheers,
Kyle Moffett
-

[ message continues ]

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

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

Sounds like more of what SELinux is good for.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

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  

"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,  

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.


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:
   *  pthreads on top of clone()
   *  open(some_string) on top of all the complex VFS machinery
   *  "netcat" on top of the vast Linux network stack including  
support for arbitrary packet filtering and transformation.

In addition, "simple" is undesirable if it makes the implementation  
less generic for no good reason.  Would you want to use the "simple"  
MS Windows disk-drive model under Linux?  Every disk is its own  
letter and has its files under it.  Oh, you wanted to mount a  
filesystem over C:\tmp?  Sorry, we don't support that, too bad.   
Under Linux we have a very flexible and powerful VFS which lets you  
do very crazy things, and then for ...
[ message continues ]

OK, that's perfectly reasonable. If the client has been sold
on the concept of SELinux the client will get warm fuzzies


Well, I find that hard to believe. Maybe I'm only thinking of what


Err, no. By unit count such systems are extremely rare. There is
tremendous concern for security in your cell phone, your DVR,


Indeed. Total control over the software on your phone is not


It's easy to get simpler than that:
    (A) Labels on all objects and subjects
    (B) Access rules for subjects and objects



Curse that day job!

Thank you.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

Any progress on this?


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

Ok. I've been a developement manager, so I'll expect it Thursday.


Well, that's what the exercise is out to demonstrate. I admit to



Now you see, I don't agree with that. It's simpler than an SELinux
policy. It's not simpler than a Bell & LaPadula (once we were able
to get past the initial resistance to MAC and get someone a three
day training class they were able to do some cool things) and it's

If only security professionals can use the system you have failed
to provide a general purpose facility. It may have value in limited

It is my position that the SELinux reference policy fails the
"small enough to analyze" clause of the TCB principle.
As a result SELinux does not help me feel secure. Restating
the complexity of the applications in the policy is arguably an
improvement, but I can't help but think the effort would be better
put into fixing the applications.

So long as your definition of "secure" allows for something other
than "runs SELinux", and so long as you are willing to accept the
conclusions of "security professionals", I can point to several
examples of systems that have been evaluated using other mechanisms.
There aren't other mechanisms upstream in Linux yet.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

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).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-

[ message continues ]

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.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

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

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-

[ message continues ]

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. If you want to maintain an SELinux policy
that looks like it does smackish things in addition to the reference
policy that's OK by me.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

class LinkedList {} for example. Just look how simple the linux
kernel does it ;-)


	Jan
-- 
-

[ message continues ]

I just remember MechWarrior2 (game from Activison), where SMK stood for their

Redundant parentheses, be gone.

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

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


Whatever it tries to do, this is not endian-safe. Except if @str




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]


__FUNCTION__ is a GNU extension, C99 uses __func__.




sprintf returns the number of bytes it has written, so
	cp += sprintf(cp, ...)


80 is plenty for a 11 char string.

Look, they've got funny ideas! :)









Uh...

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






Whitespace broken.


[attention span ran out]

Nice.




	Jan
-- 
-

[ message continues ]

Smack uses netlabel to communicate label information even locally.
Without this only processes running with the ambient label would







Small string stuck in a large integer. The only operation is
comparison. Big or little endian the string will come out right,

I have to look into that for the configuration values. I don't


























Thank you.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

Evil optimization ;-)



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,

static int smack_task_kill(struct stask_struct *p, struct siginfo *info,
    int sig, u32 secid)
{
	/* Comment */
	return smk_curacc(smk_of_task(p), MAY_WRITE);
}



	Jan
-- 
-

[ message continues ]

Sorry, I meant that my code was excessive, not your comment.
Your comment was fine and most welcome. I'm sorry that I was
unclear and sounded defensive.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

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)

-Andi
-

[ message continues ]

Individual entries can be modified without changing the whole

I put some thought into clever schemes for supporting large rule sets
well but decided to go ahead with the simplest possible mechanism
because I expect that in real deployments the number of rules will
be small. In fact, experiance says that virtually all access choices
will be covered either by the subject==object case or the subject can
read floor case. Cacheing, hashing, and 2D structures are all


Thank you for your comments. I think the next version will be improved.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

> Entries are never deleted, although they can be modified.

The modification case still seems racy then.

-Andi

-

[ message continues ]

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


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

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])

-Andi

-

[ message continues ]

Thank you. You have no idea how helpful that little suggestion was.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

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?

-

[ message continues ]

A task labeled star would create files labeled star, which would be
readable and writable by everyone (rule 4). This would be bad.

Over the past three decade I've seen a lot of secure installations
but I have never seen one where they really wanted to deny any
real application access to "/". That's a major reason for chrooted
environments.

Remember also that a process labeled Coffee would have read access
to floor files, all access to star files (e.g. /dev/null), read and
write access to Coffee objects, and no others unless specified. If
you are serious about reducing the programs a Coffee process can run
you can do so by moving them off the floor, that is, giving them
a different label, say "Tea". There is a cost to doing this, which
is that you now have to give other labels explicit access to Tea
objects. This is how you would implement a Biba integrity policy.

So, can you give me an example where you don't want access to any
file system objects (no read or execute access on floor) and are still
doing something useful? Remember that you can't exec a program if
you can't access it.

I think that access to the file system namespace is universally
required. I'm open to education.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]