Root/
1 | |
2 | |
3 | "Good for you, you've decided to clean the elevator!" |
4 | - The Elevator, from Dark Star |
5 | |
6 | Smack is the the Simplified Mandatory Access Control Kernel. |
7 | Smack is a kernel based implementation of mandatory access |
8 | control that includes simplicity in its primary design goals. |
9 | |
10 | Smack is not the only Mandatory Access Control scheme |
11 | available for Linux. Those new to Mandatory Access Control |
12 | are encouraged to compare Smack with the other mechanisms |
13 | available to determine which is best suited to the problem |
14 | at hand. |
15 | |
16 | Smack consists of three major components: |
17 | - The kernel |
18 | - A start-up script and a few modified applications |
19 | - Configuration data |
20 | |
21 | The kernel component of Smack is implemented as a Linux |
22 | Security Modules (LSM) module. It requires netlabel and |
23 | works best with file systems that support extended attributes, |
24 | although xattr support is not strictly required. |
25 | It is safe to run a Smack kernel under a "vanilla" distribution. |
26 | Smack kernels use the CIPSO IP option. Some network |
27 | configurations are intolerant of IP options and can impede |
28 | access to systems that use them as Smack does. |
29 | |
30 | The startup script etc-init.d-smack should be installed |
31 | in /etc/init.d/smack and should be invoked early in the |
32 | start-up process. On Fedora rc5.d/S02smack is recommended. |
33 | This script ensures that certain devices have the correct |
34 | Smack attributes and loads the Smack configuration if |
35 | any is defined. This script invokes two programs that |
36 | ensure configuration data is properly formatted. These |
37 | programs are /usr/sbin/smackload and /usr/sin/smackcipso. |
38 | The system will run just fine without these programs, |
39 | but it will be difficult to set access rules properly. |
40 | |
41 | A version of "ls" that provides a "-M" option to display |
42 | Smack labels on long listing is available. |
43 | |
44 | A hacked version of sshd that allows network logins by users |
45 | with specific Smack labels is available. This version does |
46 | not work for scp. You must set the /etc/ssh/sshd_config |
47 | line: |
48 | UsePrivilegeSeparation no |
49 | |
50 | The format of /etc/smack/usr is: |
51 | |
52 | username smack |
53 | |
54 | In keeping with the intent of Smack, configuration data is |
55 | minimal and not strictly required. The most important |
56 | configuration step is mounting the smackfs pseudo filesystem. |
57 | |
58 | Add this line to /etc/fstab: |
59 | |
60 | smackfs /smack smackfs smackfsdef=* 0 0 |
61 | |
62 | and create the /smack directory for mounting. |
63 | |
64 | Smack uses extended attributes (xattrs) to store file labels. |
65 | The command to set a Smack label on a file is: |
66 | |
67 | # attr -S -s SMACK64 -V "value" path |
68 | |
69 | NOTE: Smack labels are limited to 23 characters. The attr command |
70 | does not enforce this restriction and can be used to set |
71 | invalid Smack labels on files. |
72 | |
73 | If you don't do anything special all users will get the floor ("_") |
74 | label when they log in. If you do want to log in via the hacked ssh |
75 | at other labels use the attr command to set the smack value on the |
76 | home directory and it's contents. |
77 | |
78 | You can add access rules in /etc/smack/accesses. They take the form: |
79 | |
80 | subjectlabel objectlabel access |
81 | |
82 | access is a combination of the letters rwxa which specify the |
83 | kind of access permitted a subject with subjectlabel on an |
84 | object with objectlabel. If there is no rule no access is allowed. |
85 | |
86 | A process can see the smack label it is running with by |
87 | reading /proc/self/attr/current. A privileged process can |
88 | set the process smack by writing there. |
89 | |
90 | Look for additional programs on http://schaufler-ca.com |
91 | |
92 | From the Smack Whitepaper: |
93 | |
94 | The Simplified Mandatory Access Control Kernel |
95 | |
96 | Casey Schaufler |
97 | casey@schaufler-ca.com |
98 | |
99 | Mandatory Access Control |
100 | |
101 | Computer systems employ a variety of schemes to constrain how information is |
102 | shared among the people and services using the machine. Some of these schemes |
103 | allow the program or user to decide what other programs or users are allowed |
104 | access to pieces of data. These schemes are called discretionary access |
105 | control mechanisms because the access control is specified at the discretion |
106 | of the user. Other schemes do not leave the decision regarding what a user or |
107 | program can access up to users or programs. These schemes are called mandatory |
108 | access control mechanisms because you don't have a choice regarding the users |
109 | or programs that have access to pieces of data. |
110 | |
111 | Bell & LaPadula |
112 | |
113 | From the middle of the 1980's until the turn of the century Mandatory Access |
114 | Control (MAC) was very closely associated with the Bell & LaPadula security |
115 | model, a mathematical description of the United States Department of Defense |
116 | policy for marking paper documents. MAC in this form enjoyed a following |
117 | within the Capital Beltway and Scandinavian supercomputer centers but was |
118 | often sited as failing to address general needs. |
119 | |
120 | Domain Type Enforcement |
121 | |
122 | Around the turn of the century Domain Type Enforcement (DTE) became popular. |
123 | This scheme organizes users, programs, and data into domains that are |
124 | protected from each other. This scheme has been widely deployed as a component |
125 | of popular Linux distributions. The administrative overhead required to |
126 | maintain this scheme and the detailed understanding of the whole system |
127 | necessary to provide a secure domain mapping leads to the scheme being |
128 | disabled or used in limited ways in the majority of cases. |
129 | |
130 | Smack |
131 | |
132 | Smack is a Mandatory Access Control mechanism designed to provide useful MAC |
133 | while avoiding the pitfalls of its predecessors. The limitations of Bell & |
134 | LaPadula are addressed by providing a scheme whereby access can be controlled |
135 | according to the requirements of the system and its purpose rather than those |
136 | imposed by an arcane government policy. The complexity of Domain Type |
137 | Enforcement and avoided by defining access controls in terms of the access |
138 | modes already in use. |
139 | |
140 | Smack Terminology |
141 | |
142 | The jargon used to talk about Smack will be familiar to those who have dealt |
143 | with other MAC systems and shouldn't be too difficult for the uninitiated to |
144 | pick up. There are four terms that are used in a specific way and that are |
145 | especially important: |
146 | |
147 | Subject: A subject is an active entity on the computer system. |
148 | On Smack a subject is a task, which is in turn the basic unit |
149 | of execution. |
150 | |
151 | Object: An object is a passive entity on the computer system. |
152 | On Smack files of all types, IPC, and tasks can be objects. |
153 | |
154 | Access: Any attempt by a subject to put information into or get |
155 | information from an object is an access. |
156 | |
157 | Label: Data that identifies the Mandatory Access Control |
158 | characteristics of a subject or an object. |
159 | |
160 | These definitions are consistent with the traditional use in the security |
161 | community. There are also some terms from Linux that are likely to crop up: |
162 | |
163 | Capability: A task that possesses a capability has permission to |
164 | violate an aspect of the system security policy, as identified by |
165 | the specific capability. A task that possesses one or more |
166 | capabilities is a privileged task, whereas a task with no |
167 | capabilities is an unprivileged task. |
168 | |
169 | Privilege: A task that is allowed to violate the system security |
170 | policy is said to have privilege. As of this writing a task can |
171 | have privilege either by possessing capabilities or by having an |
172 | effective user of root. |
173 | |
174 | Smack Basics |
175 | |
176 | Smack is an extension to a Linux system. It enforces additional restrictions |
177 | on what subjects can access which objects, based on the labels attached to |
178 | each of the subject and the object. |
179 | |
180 | Labels |
181 | |
182 | Smack labels are ASCII character strings, one to twenty-three characters in |
183 | length. Single character labels using special characters, that being anything |
184 | other than a letter or digit, are reserved for use by the Smack development |
185 | team. Smack labels are unstructured, case sensitive, and the only operation |
186 | ever performed on them is comparison for equality. Smack labels cannot |
187 | contain unprintable characters, the "/" (slash), the "\" (backslash), the "'" |
188 | (quote) and '"' (double-quote) characters. |
189 | Smack labels cannot begin with a '-', which is reserved for special options. |
190 | |
191 | There are some predefined labels: |
192 | |
193 | _ Pronounced "floor", a single underscore character. |
194 | ^ Pronounced "hat", a single circumflex character. |
195 | * Pronounced "star", a single asterisk character. |
196 | ? Pronounced "huh", a single question mark character. |
197 | @ Pronounced "Internet", a single at sign character. |
198 | |
199 | Every task on a Smack system is assigned a label. System tasks, such as |
200 | init(8) and systems daemons, are run with the floor ("_") label. User tasks |
201 | are assigned labels according to the specification found in the |
202 | /etc/smack/user configuration file. |
203 | |
204 | Access Rules |
205 | |
206 | Smack uses the traditional access modes of Linux. These modes are read, |
207 | execute, write, and occasionally append. There are a few cases where the |
208 | access mode may not be obvious. These include: |
209 | |
210 | Signals: A signal is a write operation from the subject task to |
211 | the object task. |
212 | Internet Domain IPC: Transmission of a packet is considered a |
213 | write operation from the source task to the destination task. |
214 | |
215 | Smack restricts access based on the label attached to a subject and the label |
216 | attached to the object it is trying to access. The rules enforced are, in |
217 | order: |
218 | |
219 | 1. Any access requested by a task labeled "*" is denied. |
220 | 2. A read or execute access requested by a task labeled "^" |
221 | is permitted. |
222 | 3. A read or execute access requested on an object labeled "_" |
223 | is permitted. |
224 | 4. Any access requested on an object labeled "*" is permitted. |
225 | 5. Any access requested by a task on an object with the same |
226 | label is permitted. |
227 | 6. Any access requested that is explicitly defined in the loaded |
228 | rule set is permitted. |
229 | 7. Any other access is denied. |
230 | |
231 | Smack Access Rules |
232 | |
233 | With the isolation provided by Smack access separation is simple. There are |
234 | many interesting cases where limited access by subjects to objects with |
235 | different labels is desired. One example is the familiar spy model of |
236 | sensitivity, where a scientist working on a highly classified project would be |
237 | able to read documents of lower classifications and anything she writes will |
238 | be "born" highly classified. To accommodate such schemes Smack includes a |
239 | mechanism for specifying rules allowing access between labels. |
240 | |
241 | Access Rule Format |
242 | |
243 | The format of an access rule is: |
244 | |
245 | subject-label object-label access |
246 | |
247 | Where subject-label is the Smack label of the task, object-label is the Smack |
248 | label of the thing being accessed, and access is a string specifying the sort |
249 | of access allowed. The Smack labels are limited to 23 characters. The access |
250 | specification is searched for letters that describe access modes: |
251 | |
252 | a: indicates that append access should be granted. |
253 | r: indicates that read access should be granted. |
254 | w: indicates that write access should be granted. |
255 | x: indicates that execute access should be granted. |
256 | |
257 | Uppercase values for the specification letters are allowed as well. |
258 | Access mode specifications can be in any order. Examples of acceptable rules |
259 | are: |
260 | |
261 | TopSecret Secret rx |
262 | Secret Unclass R |
263 | Manager Game x |
264 | User HR w |
265 | New Old rRrRr |
266 | Closed Off - |
267 | |
268 | Examples of unacceptable rules are: |
269 | |
270 | Top Secret Secret rx |
271 | Ace Ace r |
272 | Odd spells waxbeans |
273 | |
274 | Spaces are not allowed in labels. Since a subject always has access to files |
275 | with the same label specifying a rule for that case is pointless. Only |
276 | valid letters (rwxaRWXA) and the dash ('-') character are allowed in |
277 | access specifications. The dash is a placeholder, so "a-r" is the same |
278 | as "ar". A lone dash is used to specify that no access should be allowed. |
279 | |
280 | Applying Access Rules |
281 | |
282 | The developers of Linux rarely define new sorts of things, usually importing |
283 | schemes and concepts from other systems. Most often, the other systems are |
284 | variants of Unix. Unix has many endearing properties, but consistency of |
285 | access control models is not one of them. Smack strives to treat accesses as |
286 | uniformly as is sensible while keeping with the spirit of the underlying |
287 | mechanism. |
288 | |
289 | File system objects including files, directories, named pipes, symbolic links, |
290 | and devices require access permissions that closely match those used by mode |
291 | bit access. To open a file for reading read access is required on the file. To |
292 | search a directory requires execute access. Creating a file with write access |
293 | requires both read and write access on the containing directory. Deleting a |
294 | file requires read and write access to the file and to the containing |
295 | directory. It is possible that a user may be able to see that a file exists |
296 | but not any of its attributes by the circumstance of having read access to the |
297 | containing directory but not to the differently labeled file. This is an |
298 | artifact of the file name being data in the directory, not a part of the file. |
299 | |
300 | IPC objects, message queues, semaphore sets, and memory segments exist in flat |
301 | namespaces and access requests are only required to match the object in |
302 | question. |
303 | |
304 | Process objects reflect tasks on the system and the Smack label used to access |
305 | them is the same Smack label that the task would use for its own access |
306 | attempts. Sending a signal via the kill() system call is a write operation |
307 | from the signaler to the recipient. Debugging a process requires both reading |
308 | and writing. Creating a new task is an internal operation that results in two |
309 | tasks with identical Smack labels and requires no access checks. |
310 | |
311 | Sockets are data structures attached to processes and sending a packet from |
312 | one process to another requires that the sender have write access to the |
313 | receiver. The receiver is not required to have read access to the sender. |
314 | |
315 | Setting Access Rules |
316 | |
317 | The configuration file /etc/smack/accesses contains the rules to be set at |
318 | system startup. The contents are written to the special file /smack/load. |
319 | Rules can be written to /smack/load at any time and take effect immediately. |
320 | For any pair of subject and object labels there can be only one rule, with the |
321 | most recently specified overriding any earlier specification. |
322 | |
323 | The program smackload is provided to ensure data is formatted |
324 | properly when written to /smack/load. This program reads lines |
325 | of the form |
326 | |
327 | subjectlabel objectlabel mode. |
328 | |
329 | Task Attribute |
330 | |
331 | The Smack label of a process can be read from /proc/<pid>/attr/current. A |
332 | process can read its own Smack label from /proc/self/attr/current. A |
333 | privileged process can change its own Smack label by writing to |
334 | /proc/self/attr/current but not the label of another process. |
335 | |
336 | File Attribute |
337 | |
338 | The Smack label of a filesystem object is stored as an extended attribute |
339 | named SMACK64 on the file. This attribute is in the security namespace. It can |
340 | only be changed by a process with privilege. |
341 | |
342 | Privilege |
343 | |
344 | A process with CAP_MAC_OVERRIDE is privileged. |
345 | |
346 | Smack Networking |
347 | |
348 | As mentioned before, Smack enforces access control on network protocol |
349 | transmissions. Every packet sent by a Smack process is tagged with its Smack |
350 | label. This is done by adding a CIPSO tag to the header of the IP packet. Each |
351 | packet received is expected to have a CIPSO tag that identifies the label and |
352 | if it lacks such a tag the network ambient label is assumed. Before the packet |
353 | is delivered a check is made to determine that a subject with the label on the |
354 | packet has write access to the receiving process and if that is not the case |
355 | the packet is dropped. |
356 | |
357 | CIPSO Configuration |
358 | |
359 | It is normally unnecessary to specify the CIPSO configuration. The default |
360 | values used by the system handle all internal cases. Smack will compose CIPSO |
361 | label values to match the Smack labels being used without administrative |
362 | intervention. Unlabeled packets that come into the system will be given the |
363 | ambient label. |
364 | |
365 | Smack requires configuration in the case where packets from a system that is |
366 | not smack that speaks CIPSO may be encountered. Usually this will be a Trusted |
367 | Solaris system, but there are other, less widely deployed systems out there. |
368 | CIPSO provides 3 important values, a Domain Of Interpretation (DOI), a level, |
369 | and a category set with each packet. The DOI is intended to identify a group |
370 | of systems that use compatible labeling schemes, and the DOI specified on the |
371 | smack system must match that of the remote system or packets will be |
372 | discarded. The DOI is 3 by default. The value can be read from /smack/doi and |
373 | can be changed by writing to /smack/doi. |
374 | |
375 | The label and category set are mapped to a Smack label as defined in |
376 | /etc/smack/cipso. |
377 | |
378 | A Smack/CIPSO mapping has the form: |
379 | |
380 | smack level [category [category]*] |
381 | |
382 | Smack does not expect the level or category sets to be related in any |
383 | particular way and does not assume or assign accesses based on them. Some |
384 | examples of mappings: |
385 | |
386 | TopSecret 7 |
387 | TS:A,B 7 1 2 |
388 | SecBDE 5 2 4 6 |
389 | RAFTERS 7 12 26 |
390 | |
391 | The ":" and "," characters are permitted in a Smack label but have no special |
392 | meaning. |
393 | |
394 | The mapping of Smack labels to CIPSO values is defined by writing to |
395 | /smack/cipso. Again, the format of data written to this special file |
396 | is highly restrictive, so the program smackcipso is provided to |
397 | ensure the writes are done properly. This program takes mappings |
398 | on the standard input and sends them to /smack/cipso properly. |
399 | |
400 | In addition to explicit mappings Smack supports direct CIPSO mappings. One |
401 | CIPSO level is used to indicate that the category set passed in the packet is |
402 | in fact an encoding of the Smack label. The level used is 250 by default. The |
403 | value can be read from /smack/direct and changed by writing to /smack/direct. |
404 | |
405 | Socket Attributes |
406 | |
407 | There are two attributes that are associated with sockets. These attributes |
408 | can only be set by privileged tasks, but any task can read them for their own |
409 | sockets. |
410 | |
411 | SMACK64IPIN: The Smack label of the task object. A privileged |
412 | program that will enforce policy may set this to the star label. |
413 | |
414 | SMACK64IPOUT: The Smack label transmitted with outgoing packets. |
415 | A privileged program may set this to match the label of another |
416 | task with which it hopes to communicate. |
417 | |
418 | Smack Netlabel Exceptions |
419 | |
420 | You will often find that your labeled application has to talk to the outside, |
421 | unlabeled world. To do this there's a special file /smack/netlabel where you can |
422 | add some exceptions in the form of : |
423 | @IP1 LABEL1 or |
424 | @IP2/MASK LABEL2 |
425 | |
426 | It means that your application will have unlabeled access to @IP1 if it has |
427 | write access on LABEL1, and access to the subnet @IP2/MASK if it has write |
428 | access on LABEL2. |
429 | |
430 | Entries in the /smack/netlabel file are matched by longest mask first, like in |
431 | classless IPv4 routing. |
432 | |
433 | A special label '@' and an option '-CIPSO' can be used there : |
434 | @ means Internet, any application with any label has access to it |
435 | -CIPSO means standard CIPSO networking |
436 | |
437 | If you don't know what CIPSO is and don't plan to use it, you can just do : |
438 | echo 127.0.0.1 -CIPSO > /smack/netlabel |
439 | echo 0.0.0.0/0 @ > /smack/netlabel |
440 | |
441 | If you use CIPSO on your 192.168.0.0/16 local network and need also unlabeled |
442 | Internet access, you can have : |
443 | echo 127.0.0.1 -CIPSO > /smack/netlabel |
444 | echo 192.168.0.0/16 -CIPSO > /smack/netlabel |
445 | echo 0.0.0.0/0 @ > /smack/netlabel |
446 | |
447 | |
448 | Writing Applications for Smack |
449 | |
450 | There are three sorts of applications that will run on a Smack system. How an |
451 | application interacts with Smack will determine what it will have to do to |
452 | work properly under Smack. |
453 | |
454 | Smack Ignorant Applications |
455 | |
456 | By far the majority of applications have no reason whatever to care about the |
457 | unique properties of Smack. Since invoking a program has no impact on the |
458 | Smack label associated with the process the only concern likely to arise is |
459 | whether the process has execute access to the program. |
460 | |
461 | Smack Relevant Applications |
462 | |
463 | Some programs can be improved by teaching them about Smack, but do not make |
464 | any security decisions themselves. The utility ls(1) is one example of such a |
465 | program. |
466 | |
467 | Smack Enforcing Applications |
468 | |
469 | These are special programs that not only know about Smack, but participate in |
470 | the enforcement of system policy. In most cases these are the programs that |
471 | set up user sessions. There are also network services that provide information |
472 | to processes running with various labels. |
473 | |
474 | File System Interfaces |
475 | |
476 | Smack maintains labels on file system objects using extended attributes. The |
477 | Smack label of a file, directory, or other file system object can be obtained |
478 | using getxattr(2). |
479 | |
480 | len = getxattr("/", "security.SMACK64", value, sizeof (value)); |
481 | |
482 | will put the Smack label of the root directory into value. A privileged |
483 | process can set the Smack label of a file system object with setxattr(2). |
484 | |
485 | len = strlen("Rubble"); |
486 | rc = setxattr("/foo", "security.SMACK64", "Rubble", len, 0); |
487 | |
488 | will set the Smack label of /foo to "Rubble" if the program has appropriate |
489 | privilege. |
490 | |
491 | Socket Interfaces |
492 | |
493 | The socket attributes can be read using fgetxattr(2). |
494 | |
495 | A privileged process can set the Smack label of outgoing packets with |
496 | fsetxattr(2). |
497 | |
498 | len = strlen("Rubble"); |
499 | rc = fsetxattr(fd, "security.SMACK64IPOUT", "Rubble", len, 0); |
500 | |
501 | will set the Smack label "Rubble" on packets going out from the socket if the |
502 | program has appropriate privilege. |
503 | |
504 | rc = fsetxattr(fd, "security.SMACK64IPIN, "*", strlen("*"), 0); |
505 | |
506 | will set the Smack label "*" as the object label against which incoming |
507 | packets will be checked if the program has appropriate privilege. |
508 | |
509 | Administration |
510 | |
511 | Smack supports some mount options: |
512 | |
513 | smackfsdef=label: specifies the label to give files that lack |
514 | the Smack label extended attribute. |
515 | |
516 | smackfsroot=label: specifies the label to assign the root of the |
517 | file system if it lacks the Smack extended attribute. |
518 | |
519 | smackfshat=label: specifies a label that must have read access to |
520 | all labels set on the filesystem. Not yet enforced. |
521 | |
522 | smackfsfloor=label: specifies a label to which all labels set on the |
523 | filesystem must have read access. Not yet enforced. |
524 | |
525 | These mount options apply to all file system types. |
526 | |
527 | Smack auditing |
528 | |
529 | If you want Smack auditing of security events, you need to set CONFIG_AUDIT |
530 | in your kernel configuration. |
531 | By default, all denied events will be audited. You can change this behavior by |
532 | writing a single character to the /smack/logging file : |
533 | 0 : no logging |
534 | 1 : log denied (default) |
535 | 2 : log accepted |
536 | 3 : log denied & accepted |
537 | |
538 | Events are logged as 'key=value' pairs, for each event you at least will get |
539 | the subjet, the object, the rights requested, the action, the kernel function |
540 | that triggered the event, plus other pairs depending on the type of event |
541 | audited. |
542 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9