Commit | Line | Data |
---|---|---|
e114e473 CS |
1 | |
2 | ||
3 | "Good for you, you've decided to clean the elevator!" | |
4 | - The Elevator, from Dark Star | |
5 | ||
df5cbb27 | 6 | Smack is the Simplified Mandatory Access Control Kernel. |
e114e473 CS |
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 | |
f7112e6c | 18 | - Basic utilities, which are helpful but not required |
e114e473 CS |
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. | |
f7112e6c | 26 | |
e114e473 CS |
27 | Smack kernels use the CIPSO IP option. Some network |
28 | configurations are intolerant of IP options and can impede | |
29 | access to systems that use them as Smack does. | |
30 | ||
78a0d8f5 | 31 | The current git repository for Smack user space is: |
e114e473 | 32 | |
78a0d8f5 | 33 | git://github.com/smack-team/smack.git |
e114e473 | 34 | |
78a0d8f5 | 35 | This should make and install on most modern distributions. |
f7112e6c | 36 | There are three commands included in smackutil: |
e114e473 | 37 | |
f7112e6c CS |
38 | smackload - properly formats data for writing to /smack/load |
39 | smackcipso - properly formats data for writing to /smack/cipso | |
40 | chsmack - display or set Smack extended attribute values | |
e114e473 CS |
41 | |
42 | In keeping with the intent of Smack, configuration data is | |
43 | minimal and not strictly required. The most important | |
44 | configuration step is mounting the smackfs pseudo filesystem. | |
f7112e6c CS |
45 | If smackutil is installed the startup script will take care |
46 | of this, but it can be manually as well. | |
e114e473 CS |
47 | |
48 | Add this line to /etc/fstab: | |
49 | ||
50 | smackfs /smack smackfs smackfsdef=* 0 0 | |
51 | ||
52 | and create the /smack directory for mounting. | |
53 | ||
f7112e6c CS |
54 | Smack uses extended attributes (xattrs) to store labels on filesystem |
55 | objects. The attributes are stored in the extended attribute security | |
56 | name space. A process must have CAP_MAC_ADMIN to change any of these | |
57 | attributes. | |
58 | ||
59 | The extended attributes that Smack uses are: | |
60 | ||
61 | SMACK64 | |
62 | Used to make access control decisions. In almost all cases | |
63 | the label given to a new filesystem object will be the label | |
64 | of the process that created it. | |
65 | SMACK64EXEC | |
66 | The Smack label of a process that execs a program file with | |
67 | this attribute set will run with this attribute's value. | |
68 | SMACK64MMAP | |
69 | Don't allow the file to be mmapped by a process whose Smack | |
70 | label does not allow all of the access permitted to a process | |
71 | with the label contained in this attribute. This is a very | |
72 | specific use case for shared libraries. | |
73 | SMACK64TRANSMUTE | |
74 | Can only have the value "TRUE". If this attribute is present | |
75 | on a directory when an object is created in the directory and | |
76 | the Smack rule (more below) that permitted the write access | |
77 | to the directory includes the transmute ("t") mode the object | |
78 | gets the label of the directory instead of the label of the | |
79 | creating process. If the object being created is a directory | |
80 | the SMACK64TRANSMUTE attribute is set as well. | |
81 | SMACK64IPIN | |
82 | This attribute is only available on file descriptors for sockets. | |
83 | Use the Smack label in this attribute for access control | |
84 | decisions on packets being delivered to this socket. | |
85 | SMACK64IPOUT | |
86 | This attribute is only available on file descriptors for sockets. | |
87 | Use the Smack label in this attribute for access control | |
88 | decisions on packets coming from this socket. | |
89 | ||
90 | There are multiple ways to set a Smack label on a file: | |
e114e473 CS |
91 | |
92 | # attr -S -s SMACK64 -V "value" path | |
f7112e6c | 93 | # chsmack -a value path |
e114e473 | 94 | |
f7112e6c CS |
95 | A process can see the smack label it is running with by |
96 | reading /proc/self/attr/current. A process with CAP_MAC_ADMIN | |
97 | can set the process smack by writing there. | |
98 | ||
99 | Most Smack configuration is accomplished by writing to files | |
100 | in the smackfs filesystem. This pseudo-filesystem is usually | |
101 | mounted on /smack. | |
102 | ||
103 | access | |
104 | This interface reports whether a subject with the specified | |
105 | Smack label has a particular access to an object with a | |
106 | specified Smack label. Write a fixed format access rule to | |
107 | this file. The next read will indicate whether the access | |
108 | would be permitted. The text will be either "1" indicating | |
109 | access, or "0" indicating denial. | |
110 | access2 | |
111 | This interface reports whether a subject with the specified | |
112 | Smack label has a particular access to an object with a | |
113 | specified Smack label. Write a long format access rule to | |
114 | this file. The next read will indicate whether the access | |
115 | would be permitted. The text will be either "1" indicating | |
116 | access, or "0" indicating denial. | |
117 | ambient | |
118 | This contains the Smack label applied to unlabeled network | |
119 | packets. | |
e05b6f98 RK |
120 | change-rule |
121 | This interface allows modification of existing access control rules. | |
122 | The format accepted on write is: | |
123 | "%s %s %s %s" | |
124 | where the first string is the subject label, the second the | |
125 | object label, the third the access to allow and the fourth the | |
126 | access to deny. The access strings may contain only the characters | |
127 | "rwxat-". If a rule for a given subject and object exists it will be | |
128 | modified by enabling the permissions in the third string and disabling | |
129 | those in the fourth string. If there is no such rule it will be | |
130 | created using the access specified in the third and the fourth strings. | |
f7112e6c CS |
131 | cipso |
132 | This interface allows a specific CIPSO header to be assigned | |
133 | to a Smack label. The format accepted on write is: | |
134 | "%24s%4d%4d"["%4d"]... | |
135 | The first string is a fixed Smack label. The first number is | |
136 | the level to use. The second number is the number of categories. | |
137 | The following numbers are the categories. | |
138 | "level-3-cats-5-19 3 2 5 19" | |
139 | cipso2 | |
140 | This interface allows a specific CIPSO header to be assigned | |
141 | to a Smack label. The format accepted on write is: | |
142 | "%s%4d%4d"["%4d"]... | |
143 | The first string is a long Smack label. The first number is | |
144 | the level to use. The second number is the number of categories. | |
145 | The following numbers are the categories. | |
146 | "level-3-cats-5-19 3 2 5 19" | |
147 | direct | |
148 | This contains the CIPSO level used for Smack direct label | |
149 | representation in network packets. | |
150 | doi | |
151 | This contains the CIPSO domain of interpretation used in | |
152 | network packets. | |
153 | load | |
154 | This interface allows access control rules in addition to | |
155 | the system defined rules to be specified. The format accepted | |
156 | on write is: | |
157 | "%24s%24s%5s" | |
158 | where the first string is the subject label, the second the | |
159 | object label, and the third the requested access. The access | |
160 | string may contain only the characters "rwxat-", and specifies | |
161 | which sort of access is allowed. The "-" is a placeholder for | |
162 | permissions that are not allowed. The string "r-x--" would | |
163 | specify read and execute access. Labels are limited to 23 | |
164 | characters in length. | |
165 | load2 | |
166 | This interface allows access control rules in addition to | |
167 | the system defined rules to be specified. The format accepted | |
168 | on write is: | |
169 | "%s %s %s" | |
170 | where the first string is the subject label, the second the | |
171 | object label, and the third the requested access. The access | |
172 | string may contain only the characters "rwxat-", and specifies | |
173 | which sort of access is allowed. The "-" is a placeholder for | |
174 | permissions that are not allowed. The string "r-x--" would | |
175 | specify read and execute access. | |
176 | load-self | |
177 | This interface allows process specific access rules to be | |
178 | defined. These rules are only consulted if access would | |
179 | otherwise be permitted, and are intended to provide additional | |
180 | restrictions on the process. The format is the same as for | |
181 | the load interface. | |
182 | load-self2 | |
183 | This interface allows process specific access rules to be | |
184 | defined. These rules are only consulted if access would | |
185 | otherwise be permitted, and are intended to provide additional | |
186 | restrictions on the process. The format is the same as for | |
187 | the load2 interface. | |
188 | logging | |
189 | This contains the Smack logging state. | |
190 | mapped | |
191 | This contains the CIPSO level used for Smack mapped label | |
192 | representation in network packets. | |
193 | netlabel | |
194 | This interface allows specific internet addresses to be | |
195 | treated as single label hosts. Packets are sent to single | |
196 | label hosts without CIPSO headers, but only from processes | |
197 | that have Smack write access to the host label. All packets | |
198 | received from single label hosts are given the specified | |
199 | label. The format accepted on write is: | |
200 | "%d.%d.%d.%d label" or "%d.%d.%d.%d/%d label". | |
201 | onlycap | |
202 | This contains the label processes must have for CAP_MAC_ADMIN | |
203 | and CAP_MAC_OVERRIDE to be effective. If this file is empty | |
204 | these capabilities are effective at for processes with any | |
205 | label. The value is set by writing the desired label to the | |
206 | file or cleared by writing "-" to the file. | |
66867818 LP |
207 | ptrace |
208 | This is used to define the current ptrace policy | |
209 | 0 - default: this is the policy that relies on smack access rules. | |
210 | For the PTRACE_READ a subject needs to have a read access on | |
211 | object. For the PTRACE_ATTACH a read-write access is required. | |
212 | 1 - exact: this is the policy that limits PTRACE_ATTACH. Attach is | |
213 | only allowed when subject's and object's labels are equal. | |
214 | PTRACE_READ is not affected. Can be overriden with CAP_SYS_PTRACE. | |
215 | 2 - draconian: this policy behaves like the 'exact' above with an | |
216 | exception that it can't be overriden with CAP_SYS_PTRACE. | |
449543b0 RK |
217 | revoke-subject |
218 | Writing a Smack label here sets the access to '-' for all access | |
219 | rules with that subject label. | |
e114e473 CS |
220 | |
221 | You can add access rules in /etc/smack/accesses. They take the form: | |
222 | ||
223 | subjectlabel objectlabel access | |
224 | ||
225 | access is a combination of the letters rwxa which specify the | |
226 | kind of access permitted a subject with subjectlabel on an | |
227 | object with objectlabel. If there is no rule no access is allowed. | |
228 | ||
e114e473 CS |
229 | Look for additional programs on http://schaufler-ca.com |
230 | ||
231 | From the Smack Whitepaper: | |
232 | ||
233 | The Simplified Mandatory Access Control Kernel | |
234 | ||
235 | Casey Schaufler | |
236 | casey@schaufler-ca.com | |
237 | ||
238 | Mandatory Access Control | |
239 | ||
240 | Computer systems employ a variety of schemes to constrain how information is | |
241 | shared among the people and services using the machine. Some of these schemes | |
242 | allow the program or user to decide what other programs or users are allowed | |
243 | access to pieces of data. These schemes are called discretionary access | |
244 | control mechanisms because the access control is specified at the discretion | |
245 | of the user. Other schemes do not leave the decision regarding what a user or | |
246 | program can access up to users or programs. These schemes are called mandatory | |
247 | access control mechanisms because you don't have a choice regarding the users | |
248 | or programs that have access to pieces of data. | |
249 | ||
250 | Bell & LaPadula | |
251 | ||
252 | From the middle of the 1980's until the turn of the century Mandatory Access | |
253 | Control (MAC) was very closely associated with the Bell & LaPadula security | |
254 | model, a mathematical description of the United States Department of Defense | |
255 | policy for marking paper documents. MAC in this form enjoyed a following | |
256 | within the Capital Beltway and Scandinavian supercomputer centers but was | |
257 | often sited as failing to address general needs. | |
258 | ||
259 | Domain Type Enforcement | |
260 | ||
261 | Around the turn of the century Domain Type Enforcement (DTE) became popular. | |
262 | This scheme organizes users, programs, and data into domains that are | |
263 | protected from each other. This scheme has been widely deployed as a component | |
264 | of popular Linux distributions. The administrative overhead required to | |
265 | maintain this scheme and the detailed understanding of the whole system | |
266 | necessary to provide a secure domain mapping leads to the scheme being | |
267 | disabled or used in limited ways in the majority of cases. | |
268 | ||
269 | Smack | |
270 | ||
271 | Smack is a Mandatory Access Control mechanism designed to provide useful MAC | |
272 | while avoiding the pitfalls of its predecessors. The limitations of Bell & | |
273 | LaPadula are addressed by providing a scheme whereby access can be controlled | |
274 | according to the requirements of the system and its purpose rather than those | |
275 | imposed by an arcane government policy. The complexity of Domain Type | |
276 | Enforcement and avoided by defining access controls in terms of the access | |
277 | modes already in use. | |
278 | ||
279 | Smack Terminology | |
280 | ||
281 | The jargon used to talk about Smack will be familiar to those who have dealt | |
282 | with other MAC systems and shouldn't be too difficult for the uninitiated to | |
283 | pick up. There are four terms that are used in a specific way and that are | |
284 | especially important: | |
285 | ||
286 | Subject: A subject is an active entity on the computer system. | |
287 | On Smack a subject is a task, which is in turn the basic unit | |
288 | of execution. | |
289 | ||
290 | Object: An object is a passive entity on the computer system. | |
291 | On Smack files of all types, IPC, and tasks can be objects. | |
292 | ||
293 | Access: Any attempt by a subject to put information into or get | |
294 | information from an object is an access. | |
295 | ||
296 | Label: Data that identifies the Mandatory Access Control | |
297 | characteristics of a subject or an object. | |
298 | ||
299 | These definitions are consistent with the traditional use in the security | |
300 | community. There are also some terms from Linux that are likely to crop up: | |
301 | ||
302 | Capability: A task that possesses a capability has permission to | |
303 | violate an aspect of the system security policy, as identified by | |
304 | the specific capability. A task that possesses one or more | |
305 | capabilities is a privileged task, whereas a task with no | |
306 | capabilities is an unprivileged task. | |
307 | ||
308 | Privilege: A task that is allowed to violate the system security | |
309 | policy is said to have privilege. As of this writing a task can | |
310 | have privilege either by possessing capabilities or by having an | |
311 | effective user of root. | |
312 | ||
313 | Smack Basics | |
314 | ||
315 | Smack is an extension to a Linux system. It enforces additional restrictions | |
316 | on what subjects can access which objects, based on the labels attached to | |
317 | each of the subject and the object. | |
318 | ||
319 | Labels | |
320 | ||
321 | Smack labels are ASCII character strings, one to twenty-three characters in | |
322 | length. Single character labels using special characters, that being anything | |
323 | other than a letter or digit, are reserved for use by the Smack development | |
324 | team. Smack labels are unstructured, case sensitive, and the only operation | |
325 | ever performed on them is comparison for equality. Smack labels cannot | |
ecfcc53f EB |
326 | contain unprintable characters, the "/" (slash), the "\" (backslash), the "'" |
327 | (quote) and '"' (double-quote) characters. | |
f7112e6c | 328 | Smack labels cannot begin with a '-'. This is reserved for special options. |
e114e473 CS |
329 | |
330 | There are some predefined labels: | |
331 | ||
4303154e EB |
332 | _ Pronounced "floor", a single underscore character. |
333 | ^ Pronounced "hat", a single circumflex character. | |
334 | * Pronounced "star", a single asterisk character. | |
335 | ? Pronounced "huh", a single question mark character. | |
f7112e6c | 336 | @ Pronounced "web", a single at sign character. |
e114e473 CS |
337 | |
338 | Every task on a Smack system is assigned a label. System tasks, such as | |
339 | init(8) and systems daemons, are run with the floor ("_") label. User tasks | |
340 | are assigned labels according to the specification found in the | |
341 | /etc/smack/user configuration file. | |
342 | ||
343 | Access Rules | |
344 | ||
345 | Smack uses the traditional access modes of Linux. These modes are read, | |
346 | execute, write, and occasionally append. There are a few cases where the | |
347 | access mode may not be obvious. These include: | |
348 | ||
349 | Signals: A signal is a write operation from the subject task to | |
350 | the object task. | |
351 | Internet Domain IPC: Transmission of a packet is considered a | |
352 | write operation from the source task to the destination task. | |
353 | ||
354 | Smack restricts access based on the label attached to a subject and the label | |
355 | attached to the object it is trying to access. The rules enforced are, in | |
356 | order: | |
357 | ||
358 | 1. Any access requested by a task labeled "*" is denied. | |
359 | 2. A read or execute access requested by a task labeled "^" | |
360 | is permitted. | |
361 | 3. A read or execute access requested on an object labeled "_" | |
362 | is permitted. | |
363 | 4. Any access requested on an object labeled "*" is permitted. | |
364 | 5. Any access requested by a task on an object with the same | |
365 | label is permitted. | |
366 | 6. Any access requested that is explicitly defined in the loaded | |
367 | rule set is permitted. | |
368 | 7. Any other access is denied. | |
369 | ||
370 | Smack Access Rules | |
371 | ||
372 | With the isolation provided by Smack access separation is simple. There are | |
373 | many interesting cases where limited access by subjects to objects with | |
374 | different labels is desired. One example is the familiar spy model of | |
375 | sensitivity, where a scientist working on a highly classified project would be | |
376 | able to read documents of lower classifications and anything she writes will | |
377 | be "born" highly classified. To accommodate such schemes Smack includes a | |
378 | mechanism for specifying rules allowing access between labels. | |
379 | ||
380 | Access Rule Format | |
381 | ||
382 | The format of an access rule is: | |
383 | ||
384 | subject-label object-label access | |
385 | ||
386 | Where subject-label is the Smack label of the task, object-label is the Smack | |
387 | label of the thing being accessed, and access is a string specifying the sort | |
f7112e6c CS |
388 | of access allowed. The access specification is searched for letters that |
389 | describe access modes: | |
e114e473 CS |
390 | |
391 | a: indicates that append access should be granted. | |
392 | r: indicates that read access should be granted. | |
393 | w: indicates that write access should be granted. | |
394 | x: indicates that execute access should be granted. | |
f7112e6c | 395 | t: indicates that the rule requests transmutation. |
e114e473 CS |
396 | |
397 | Uppercase values for the specification letters are allowed as well. | |
398 | Access mode specifications can be in any order. Examples of acceptable rules | |
399 | are: | |
400 | ||
401 | TopSecret Secret rx | |
402 | Secret Unclass R | |
403 | Manager Game x | |
404 | User HR w | |
405 | New Old rRrRr | |
406 | Closed Off - | |
407 | ||
408 | Examples of unacceptable rules are: | |
409 | ||
410 | Top Secret Secret rx | |
411 | Ace Ace r | |
412 | Odd spells waxbeans | |
413 | ||
414 | Spaces are not allowed in labels. Since a subject always has access to files | |
415 | with the same label specifying a rule for that case is pointless. Only | |
f7112e6c | 416 | valid letters (rwxatRWXAT) and the dash ('-') character are allowed in |
e114e473 CS |
417 | access specifications. The dash is a placeholder, so "a-r" is the same |
418 | as "ar". A lone dash is used to specify that no access should be allowed. | |
419 | ||
420 | Applying Access Rules | |
421 | ||
422 | The developers of Linux rarely define new sorts of things, usually importing | |
423 | schemes and concepts from other systems. Most often, the other systems are | |
424 | variants of Unix. Unix has many endearing properties, but consistency of | |
425 | access control models is not one of them. Smack strives to treat accesses as | |
426 | uniformly as is sensible while keeping with the spirit of the underlying | |
427 | mechanism. | |
428 | ||
429 | File system objects including files, directories, named pipes, symbolic links, | |
430 | and devices require access permissions that closely match those used by mode | |
431 | bit access. To open a file for reading read access is required on the file. To | |
432 | search a directory requires execute access. Creating a file with write access | |
433 | requires both read and write access on the containing directory. Deleting a | |
434 | file requires read and write access to the file and to the containing | |
435 | directory. It is possible that a user may be able to see that a file exists | |
436 | but not any of its attributes by the circumstance of having read access to the | |
437 | containing directory but not to the differently labeled file. This is an | |
438 | artifact of the file name being data in the directory, not a part of the file. | |
439 | ||
f7112e6c CS |
440 | If a directory is marked as transmuting (SMACK64TRANSMUTE=TRUE) and the |
441 | access rule that allows a process to create an object in that directory | |
442 | includes 't' access the label assigned to the new object will be that | |
443 | of the directory, not the creating process. This makes it much easier | |
444 | for two processes with different labels to share data without granting | |
445 | access to all of their files. | |
446 | ||
e114e473 CS |
447 | IPC objects, message queues, semaphore sets, and memory segments exist in flat |
448 | namespaces and access requests are only required to match the object in | |
449 | question. | |
450 | ||
451 | Process objects reflect tasks on the system and the Smack label used to access | |
452 | them is the same Smack label that the task would use for its own access | |
453 | attempts. Sending a signal via the kill() system call is a write operation | |
454 | from the signaler to the recipient. Debugging a process requires both reading | |
455 | and writing. Creating a new task is an internal operation that results in two | |
456 | tasks with identical Smack labels and requires no access checks. | |
457 | ||
458 | Sockets are data structures attached to processes and sending a packet from | |
459 | one process to another requires that the sender have write access to the | |
460 | receiver. The receiver is not required to have read access to the sender. | |
461 | ||
462 | Setting Access Rules | |
463 | ||
464 | The configuration file /etc/smack/accesses contains the rules to be set at | |
465 | system startup. The contents are written to the special file /smack/load. | |
466 | Rules can be written to /smack/load at any time and take effect immediately. | |
467 | For any pair of subject and object labels there can be only one rule, with the | |
468 | most recently specified overriding any earlier specification. | |
469 | ||
470 | The program smackload is provided to ensure data is formatted | |
471 | properly when written to /smack/load. This program reads lines | |
472 | of the form | |
473 | ||
474 | subjectlabel objectlabel mode. | |
475 | ||
476 | Task Attribute | |
477 | ||
478 | The Smack label of a process can be read from /proc/<pid>/attr/current. A | |
479 | process can read its own Smack label from /proc/self/attr/current. A | |
480 | privileged process can change its own Smack label by writing to | |
481 | /proc/self/attr/current but not the label of another process. | |
482 | ||
483 | File Attribute | |
484 | ||
485 | The Smack label of a filesystem object is stored as an extended attribute | |
486 | named SMACK64 on the file. This attribute is in the security namespace. It can | |
487 | only be changed by a process with privilege. | |
488 | ||
489 | Privilege | |
490 | ||
491 | A process with CAP_MAC_OVERRIDE is privileged. | |
492 | ||
493 | Smack Networking | |
494 | ||
495 | As mentioned before, Smack enforces access control on network protocol | |
496 | transmissions. Every packet sent by a Smack process is tagged with its Smack | |
497 | label. This is done by adding a CIPSO tag to the header of the IP packet. Each | |
498 | packet received is expected to have a CIPSO tag that identifies the label and | |
499 | if it lacks such a tag the network ambient label is assumed. Before the packet | |
500 | is delivered a check is made to determine that a subject with the label on the | |
501 | packet has write access to the receiving process and if that is not the case | |
502 | the packet is dropped. | |
503 | ||
504 | CIPSO Configuration | |
505 | ||
506 | It is normally unnecessary to specify the CIPSO configuration. The default | |
507 | values used by the system handle all internal cases. Smack will compose CIPSO | |
508 | label values to match the Smack labels being used without administrative | |
509 | intervention. Unlabeled packets that come into the system will be given the | |
510 | ambient label. | |
511 | ||
512 | Smack requires configuration in the case where packets from a system that is | |
513 | not smack that speaks CIPSO may be encountered. Usually this will be a Trusted | |
514 | Solaris system, but there are other, less widely deployed systems out there. | |
515 | CIPSO provides 3 important values, a Domain Of Interpretation (DOI), a level, | |
516 | and a category set with each packet. The DOI is intended to identify a group | |
517 | of systems that use compatible labeling schemes, and the DOI specified on the | |
518 | smack system must match that of the remote system or packets will be | |
519 | discarded. The DOI is 3 by default. The value can be read from /smack/doi and | |
520 | can be changed by writing to /smack/doi. | |
521 | ||
522 | The label and category set are mapped to a Smack label as defined in | |
523 | /etc/smack/cipso. | |
524 | ||
525 | A Smack/CIPSO mapping has the form: | |
526 | ||
527 | smack level [category [category]*] | |
528 | ||
529 | Smack does not expect the level or category sets to be related in any | |
530 | particular way and does not assume or assign accesses based on them. Some | |
531 | examples of mappings: | |
532 | ||
533 | TopSecret 7 | |
534 | TS:A,B 7 1 2 | |
535 | SecBDE 5 2 4 6 | |
536 | RAFTERS 7 12 26 | |
537 | ||
538 | The ":" and "," characters are permitted in a Smack label but have no special | |
539 | meaning. | |
540 | ||
541 | The mapping of Smack labels to CIPSO values is defined by writing to | |
542 | /smack/cipso. Again, the format of data written to this special file | |
543 | is highly restrictive, so the program smackcipso is provided to | |
544 | ensure the writes are done properly. This program takes mappings | |
545 | on the standard input and sends them to /smack/cipso properly. | |
546 | ||
547 | In addition to explicit mappings Smack supports direct CIPSO mappings. One | |
548 | CIPSO level is used to indicate that the category set passed in the packet is | |
549 | in fact an encoding of the Smack label. The level used is 250 by default. The | |
550 | value can be read from /smack/direct and changed by writing to /smack/direct. | |
551 | ||
552 | Socket Attributes | |
553 | ||
554 | There are two attributes that are associated with sockets. These attributes | |
555 | can only be set by privileged tasks, but any task can read them for their own | |
556 | sockets. | |
557 | ||
558 | SMACK64IPIN: The Smack label of the task object. A privileged | |
559 | program that will enforce policy may set this to the star label. | |
560 | ||
561 | SMACK64IPOUT: The Smack label transmitted with outgoing packets. | |
562 | A privileged program may set this to match the label of another | |
563 | task with which it hopes to communicate. | |
564 | ||
4303154e EB |
565 | Smack Netlabel Exceptions |
566 | ||
567 | You will often find that your labeled application has to talk to the outside, | |
568 | unlabeled world. To do this there's a special file /smack/netlabel where you can | |
569 | add some exceptions in the form of : | |
570 | @IP1 LABEL1 or | |
571 | @IP2/MASK LABEL2 | |
572 | ||
573 | It means that your application will have unlabeled access to @IP1 if it has | |
574 | write access on LABEL1, and access to the subnet @IP2/MASK if it has write | |
575 | access on LABEL2. | |
576 | ||
577 | Entries in the /smack/netlabel file are matched by longest mask first, like in | |
578 | classless IPv4 routing. | |
579 | ||
580 | A special label '@' and an option '-CIPSO' can be used there : | |
581 | @ means Internet, any application with any label has access to it | |
582 | -CIPSO means standard CIPSO networking | |
583 | ||
584 | If you don't know what CIPSO is and don't plan to use it, you can just do : | |
585 | echo 127.0.0.1 -CIPSO > /smack/netlabel | |
586 | echo 0.0.0.0/0 @ > /smack/netlabel | |
587 | ||
588 | If you use CIPSO on your 192.168.0.0/16 local network and need also unlabeled | |
589 | Internet access, you can have : | |
590 | echo 127.0.0.1 -CIPSO > /smack/netlabel | |
591 | echo 192.168.0.0/16 -CIPSO > /smack/netlabel | |
592 | echo 0.0.0.0/0 @ > /smack/netlabel | |
593 | ||
594 | ||
e114e473 CS |
595 | Writing Applications for Smack |
596 | ||
597 | There are three sorts of applications that will run on a Smack system. How an | |
598 | application interacts with Smack will determine what it will have to do to | |
599 | work properly under Smack. | |
600 | ||
601 | Smack Ignorant Applications | |
602 | ||
603 | By far the majority of applications have no reason whatever to care about the | |
604 | unique properties of Smack. Since invoking a program has no impact on the | |
605 | Smack label associated with the process the only concern likely to arise is | |
606 | whether the process has execute access to the program. | |
607 | ||
608 | Smack Relevant Applications | |
609 | ||
610 | Some programs can be improved by teaching them about Smack, but do not make | |
611 | any security decisions themselves. The utility ls(1) is one example of such a | |
612 | program. | |
613 | ||
614 | Smack Enforcing Applications | |
615 | ||
616 | These are special programs that not only know about Smack, but participate in | |
617 | the enforcement of system policy. In most cases these are the programs that | |
618 | set up user sessions. There are also network services that provide information | |
619 | to processes running with various labels. | |
620 | ||
621 | File System Interfaces | |
622 | ||
623 | Smack maintains labels on file system objects using extended attributes. The | |
624 | Smack label of a file, directory, or other file system object can be obtained | |
625 | using getxattr(2). | |
626 | ||
627 | len = getxattr("/", "security.SMACK64", value, sizeof (value)); | |
628 | ||
629 | will put the Smack label of the root directory into value. A privileged | |
630 | process can set the Smack label of a file system object with setxattr(2). | |
631 | ||
632 | len = strlen("Rubble"); | |
633 | rc = setxattr("/foo", "security.SMACK64", "Rubble", len, 0); | |
634 | ||
635 | will set the Smack label of /foo to "Rubble" if the program has appropriate | |
636 | privilege. | |
637 | ||
638 | Socket Interfaces | |
639 | ||
640 | The socket attributes can be read using fgetxattr(2). | |
641 | ||
642 | A privileged process can set the Smack label of outgoing packets with | |
643 | fsetxattr(2). | |
644 | ||
645 | len = strlen("Rubble"); | |
646 | rc = fsetxattr(fd, "security.SMACK64IPOUT", "Rubble", len, 0); | |
647 | ||
648 | will set the Smack label "Rubble" on packets going out from the socket if the | |
649 | program has appropriate privilege. | |
650 | ||
651 | rc = fsetxattr(fd, "security.SMACK64IPIN, "*", strlen("*"), 0); | |
652 | ||
653 | will set the Smack label "*" as the object label against which incoming | |
654 | packets will be checked if the program has appropriate privilege. | |
655 | ||
656 | Administration | |
657 | ||
658 | Smack supports some mount options: | |
659 | ||
660 | smackfsdef=label: specifies the label to give files that lack | |
661 | the Smack label extended attribute. | |
662 | ||
663 | smackfsroot=label: specifies the label to assign the root of the | |
664 | file system if it lacks the Smack extended attribute. | |
665 | ||
666 | smackfshat=label: specifies a label that must have read access to | |
667 | all labels set on the filesystem. Not yet enforced. | |
668 | ||
669 | smackfsfloor=label: specifies a label to which all labels set on the | |
670 | filesystem must have read access. Not yet enforced. | |
671 | ||
672 | These mount options apply to all file system types. | |
673 | ||
ecfcc53f EB |
674 | Smack auditing |
675 | ||
676 | If you want Smack auditing of security events, you need to set CONFIG_AUDIT | |
677 | in your kernel configuration. | |
678 | By default, all denied events will be audited. You can change this behavior by | |
679 | writing a single character to the /smack/logging file : | |
680 | 0 : no logging | |
681 | 1 : log denied (default) | |
682 | 2 : log accepted | |
683 | 3 : log denied & accepted | |
684 | ||
685 | Events are logged as 'key=value' pairs, for each event you at least will get | |
40e47125 | 686 | the subject, the object, the rights requested, the action, the kernel function |
ecfcc53f EB |
687 | that triggered the event, plus other pairs depending on the type of event |
688 | audited. |