login
Search
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 ...> +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? -
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 -
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. -
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 ...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 -
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 ...
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 ...
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 ...
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 -
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 -
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 ...
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. -
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 -
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 -
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 -
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 ...
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 -
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 -
/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).
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 -
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 -
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 ...
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
-
Any progress on this? Casey Schaufler casey@schaufler-ca.com -
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 -
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 -
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 -
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 -
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 -
class LinkedList {} for example. Just look how simple the linux
kernel does it ;-)
Jan
--
-
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
--
-
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 -
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
--
-
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 -
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 -
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 -
> Entries are never deleted, although they can be modified. The modification case still seems racy then. -Andi -
Fair enough. I'll look into real list management. Casey Schaufler casey@schaufler-ca.com -
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 -
Thank you. You have no idea how helpful that little suggestion was. Casey Schaufler casey@schaufler-ca.com -
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? -
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 -
