| Casey Schaufler | e114e47 | 2008-02-04 22:29:50 -0800 | [diff] [blame] | 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 | 
| Etienne Basset | ecfcc53 | 2009-04-08 20:40:06 +0200 | [diff] [blame] | 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. | 
| Casey Schaufler | e114e47 | 2008-02-04 22:29:50 -0800 | [diff] [blame] | 190 |  | 
 | 191 | There are some predefined labels: | 
 | 192 |  | 
| Etienne Basset | 4303154 | 2009-03-27 17:11:01 -0400 | [diff] [blame] | 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. | 
| Casey Schaufler | e114e47 | 2008-02-04 22:29:50 -0800 | [diff] [blame] | 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 |  | 
| Etienne Basset | 4303154 | 2009-03-27 17:11:01 -0400 | [diff] [blame] | 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 |  | 
| Casey Schaufler | e114e47 | 2008-02-04 22:29:50 -0800 | [diff] [blame] | 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 |  | 
| Etienne Basset | ecfcc53 | 2009-04-08 20:40:06 +0200 | [diff] [blame] | 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. |