diff options
author | 2017-05-13 04:51:49 -0700 | |
---|---|---|
committer | 2017-05-18 10:33:24 -0600 | |
commit | a5606ced286197cc280dbf3b880c6167bba9462d (patch) | |
tree | 11dce398896bf2d3373d06cdb9e35e7819513e7e /Documentation/security | |
parent | doc: ReSTify LoadPin.txt (diff) | |
download | linux-a5606ced286197cc280dbf3b880c6167bba9462d.tar.gz linux-a5606ced286197cc280dbf3b880c6167bba9462d.tar.bz2 linux-a5606ced286197cc280dbf3b880c6167bba9462d.zip |
doc: ReSTify Smack.txt
Adjusts for ReST markup and moves under LSM admin guide.
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Diffstat (limited to 'Documentation/security')
-rw-r--r-- | Documentation/security/00-INDEX | 2 | ||||
-rw-r--r-- | Documentation/security/Smack.txt | 752 |
2 files changed, 0 insertions, 754 deletions
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX index a55f781be0dd..cdb2294ec047 100644 --- a/Documentation/security/00-INDEX +++ b/Documentation/security/00-INDEX @@ -1,7 +1,5 @@ 00-INDEX - this file. -Smack.txt - - documentation on the Smack Linux Security Module. keys-ecryptfs.txt - description of the encryption keys for the ecryptfs filesystem. keys-request-key.txt diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt deleted file mode 100644 index 945cc633d883..000000000000 --- a/Documentation/security/Smack.txt +++ /dev/null @@ -1,752 +0,0 @@ - - - "Good for you, you've decided to clean the elevator!" - - The Elevator, from Dark Star - -Smack is the Simplified Mandatory Access Control Kernel. -Smack is a kernel based implementation of mandatory access -control that includes simplicity in its primary design goals. - -Smack is not the only Mandatory Access Control scheme -available for Linux. Those new to Mandatory Access Control -are encouraged to compare Smack with the other mechanisms -available to determine which is best suited to the problem -at hand. - -Smack consists of three major components: - - The kernel - - Basic utilities, which are helpful but not required - - Configuration data - -The kernel component of Smack is implemented as a Linux -Security Modules (LSM) module. It requires netlabel and -works best with file systems that support extended attributes, -although xattr support is not strictly required. -It is safe to run a Smack kernel under a "vanilla" distribution. - -Smack kernels use the CIPSO IP option. Some network -configurations are intolerant of IP options and can impede -access to systems that use them as Smack does. - -Smack is used in the Tizen operating system. Please -go to http://wiki.tizen.org for information about how -Smack is used in Tizen. - -The current git repository for Smack user space is: - - git://github.com/smack-team/smack.git - -This should make and install on most modern distributions. -There are five commands included in smackutil: - -chsmack - display or set Smack extended attribute values -smackctl - load the Smack access rules -smackaccess - report if a process with one label has access - to an object with another - -These two commands are obsolete with the introduction of -the smackfs/load2 and smackfs/cipso2 interfaces. - -smackload - properly formats data for writing to smackfs/load -smackcipso - properly formats data for writing to smackfs/cipso - -In keeping with the intent of Smack, configuration data is -minimal and not strictly required. The most important -configuration step is mounting the smackfs pseudo filesystem. -If smackutil is installed the startup script will take care -of this, but it can be manually as well. - -Add this line to /etc/fstab: - - smackfs /sys/fs/smackfs smackfs defaults 0 0 - -The /sys/fs/smackfs directory is created by the kernel. - -Smack uses extended attributes (xattrs) to store labels on filesystem -objects. The attributes are stored in the extended attribute security -name space. A process must have CAP_MAC_ADMIN to change any of these -attributes. - -The extended attributes that Smack uses are: - -SMACK64 - Used to make access control decisions. In almost all cases - the label given to a new filesystem object will be the label - of the process that created it. -SMACK64EXEC - The Smack label of a process that execs a program file with - this attribute set will run with this attribute's value. -SMACK64MMAP - Don't allow the file to be mmapped by a process whose Smack - label does not allow all of the access permitted to a process - with the label contained in this attribute. This is a very - specific use case for shared libraries. -SMACK64TRANSMUTE - Can only have the value "TRUE". If this attribute is present - on a directory when an object is created in the directory and - the Smack rule (more below) that permitted the write access - to the directory includes the transmute ("t") mode the object - gets the label of the directory instead of the label of the - creating process. If the object being created is a directory - the SMACK64TRANSMUTE attribute is set as well. -SMACK64IPIN - This attribute is only available on file descriptors for sockets. - Use the Smack label in this attribute for access control - decisions on packets being delivered to this socket. -SMACK64IPOUT - This attribute is only available on file descriptors for sockets. - Use the Smack label in this attribute for access control - decisions on packets coming from this socket. - -There are multiple ways to set a Smack label on a file: - - # attr -S -s SMACK64 -V "value" path - # chsmack -a value path - -A process can see the Smack label it is running with by -reading /proc/self/attr/current. A process with CAP_MAC_ADMIN -can set the process Smack by writing there. - -Most Smack configuration is accomplished by writing to files -in the smackfs filesystem. This pseudo-filesystem is mounted -on /sys/fs/smackfs. - -access - Provided for backward compatibility. The access2 interface - is preferred and should be used instead. - This interface reports whether a subject with the specified - Smack label has a particular access to an object with a - specified Smack label. Write a fixed format access rule to - this file. The next read will indicate whether the access - would be permitted. The text will be either "1" indicating - access, or "0" indicating denial. -access2 - This interface reports whether a subject with the specified - Smack label has a particular access to an object with a - specified Smack label. Write a long format access rule to - this file. The next read will indicate whether the access - would be permitted. The text will be either "1" indicating - access, or "0" indicating denial. -ambient - This contains the Smack label applied to unlabeled network - packets. -change-rule - This interface allows modification of existing access control rules. - The format accepted on write is: - "%s %s %s %s" - where the first string is the subject label, the second the - object label, the third the access to allow and the fourth the - access to deny. The access strings may contain only the characters - "rwxat-". If a rule for a given subject and object exists it will be - modified by enabling the permissions in the third string and disabling - those in the fourth string. If there is no such rule it will be - created using the access specified in the third and the fourth strings. -cipso - Provided for backward compatibility. The cipso2 interface - is preferred and should be used instead. - This interface allows a specific CIPSO header to be assigned - to a Smack label. The format accepted on write is: - "%24s%4d%4d"["%4d"]... - The first string is a fixed Smack label. The first number is - the level to use. The second number is the number of categories. - The following numbers are the categories. - "level-3-cats-5-19 3 2 5 19" -cipso2 - This interface allows a specific CIPSO header to be assigned - to a Smack label. The format accepted on write is: - "%s%4d%4d"["%4d"]... - The first string is a long Smack label. The first number is - the level to use. The second number is the number of categories. - The following numbers are the categories. - "level-3-cats-5-19 3 2 5 19" -direct - This contains the CIPSO level used for Smack direct label - representation in network packets. -doi - This contains the CIPSO domain of interpretation used in - network packets. -ipv6host - This interface allows specific IPv6 internet addresses to be - treated as single label hosts. Packets are sent to single - label hosts only from processes that have Smack write access - to the host label. All packets received from single label hosts - are given the specified label. The format accepted on write is: - "%h:%h:%h:%h:%h:%h:%h:%h label" or - "%h:%h:%h:%h:%h:%h:%h:%h/%d label". - The "::" address shortcut is not supported. - If label is "-DELETE" a matched entry will be deleted. -load - Provided for backward compatibility. The load2 interface - is preferred and should be used instead. - This interface allows access control rules in addition to - the system defined rules to be specified. The format accepted - on write is: - "%24s%24s%5s" - where the first string is the subject label, the second the - object label, and the third the requested access. The access - string may contain only the characters "rwxat-", and specifies - which sort of access is allowed. The "-" is a placeholder for - permissions that are not allowed. The string "r-x--" would - specify read and execute access. Labels are limited to 23 - characters in length. -load2 - This interface allows access control rules in addition to - the system defined rules to be specified. The format accepted - on write is: - "%s %s %s" - where the first string is the subject label, the second the - object label, and the third the requested access. The access - string may contain only the characters "rwxat-", and specifies - which sort of access is allowed. The "-" is a placeholder for - permissions that are not allowed. The string "r-x--" would - specify read and execute access. -load-self - Provided for backward compatibility. The load-self2 interface - is preferred and should be used instead. - This interface allows process specific access rules to be - defined. These rules are only consulted if access would - otherwise be permitted, and are intended to provide additional - restrictions on the process. The format is the same as for - the load interface. -load-self2 - This interface allows process specific access rules to be - defined. These rules are only consulted if access would - otherwise be permitted, and are intended to provide additional - restrictions on the process. The format is the same as for - the load2 interface. -logging - This contains the Smack logging state. -mapped - This contains the CIPSO level used for Smack mapped label - representation in network packets. -netlabel - This interface allows specific internet addresses to be - treated as single label hosts. Packets are sent to single - label hosts without CIPSO headers, but only from processes - that have Smack write access to the host label. All packets - received from single label hosts are given the specified - label. The format accepted on write is: - "%d.%d.%d.%d label" or "%d.%d.%d.%d/%d label". - If the label specified is "-CIPSO" the address is treated - as a host that supports CIPSO headers. -onlycap - This contains labels processes must have for CAP_MAC_ADMIN - and CAP_MAC_OVERRIDE to be effective. If this file is empty - these capabilities are effective at for processes with any - label. The values are set by writing the desired labels, separated - by spaces, to the file or cleared by writing "-" to the file. -ptrace - This is used to define the current ptrace policy - 0 - default: this is the policy that relies on Smack access rules. - For the PTRACE_READ a subject needs to have a read access on - object. For the PTRACE_ATTACH a read-write access is required. - 1 - exact: this is the policy that limits PTRACE_ATTACH. Attach is - only allowed when subject's and object's labels are equal. - PTRACE_READ is not affected. Can be overridden with CAP_SYS_PTRACE. - 2 - draconian: this policy behaves like the 'exact' above with an - exception that it can't be overridden with CAP_SYS_PTRACE. -revoke-subject - Writing a Smack label here sets the access to '-' for all access - rules with that subject label. -unconfined - If the kernel is configured with CONFIG_SECURITY_SMACK_BRINGUP - a process with CAP_MAC_ADMIN can write a label into this interface. - Thereafter, accesses that involve that label will be logged and - the access permitted if it wouldn't be otherwise. Note that this - is dangerous and can ruin the proper labeling of your system. - It should never be used in production. -relabel-self - This interface contains a list of labels to which the process can - transition to, by writing to /proc/self/attr/current. - Normally a process can change its own label to any legal value, but only - if it has CAP_MAC_ADMIN. This interface allows a process without - CAP_MAC_ADMIN to relabel itself to one of labels from predefined list. - A process without CAP_MAC_ADMIN can change its label only once. When it - does, this list will be cleared. - The values are set by writing the desired labels, separated - by spaces, to the file or cleared by writing "-" to the file. - -If you are using the smackload utility -you can add access rules in /etc/smack/accesses. They take the form: - - subjectlabel objectlabel access - -access is a combination of the letters rwxatb which specify the -kind of access permitted a subject with subjectlabel on an -object with objectlabel. If there is no rule no access is allowed. - -Look for additional programs on http://schaufler-ca.com - -From the Smack Whitepaper: - -The Simplified Mandatory Access Control Kernel - -Casey Schaufler -casey@schaufler-ca.com - -Mandatory Access Control - -Computer systems employ a variety of schemes to constrain how information is -shared among the people and services using the machine. Some of these schemes -allow the program or user to decide what other programs or users are allowed -access to pieces of data. These schemes are called discretionary access -control mechanisms because the access control is specified at the discretion -of the user. Other schemes do not leave the decision regarding what a user or -program can access up to users or programs. These schemes are called mandatory -access control mechanisms because you don't have a choice regarding the users -or programs that have access to pieces of data. - -Bell & LaPadula - -From the middle of the 1980's until the turn of the century Mandatory Access -Control (MAC) was very closely associated with the Bell & LaPadula security -model, a mathematical description of the United States Department of Defense -policy for marking paper documents. MAC in this form enjoyed a following -within the Capital Beltway and Scandinavian supercomputer centers but was -often sited as failing to address general needs. - -Domain Type Enforcement - -Around the turn of the century Domain Type Enforcement (DTE) became popular. -This scheme organizes users, programs, and data into domains that are -protected from each other. This scheme has been widely deployed as a component -of popular Linux distributions. The administrative overhead required to -maintain this scheme and the detailed understanding of the whole system -necessary to provide a secure domain mapping leads to the scheme being -disabled or used in limited ways in the majority of cases. - -Smack - -Smack is a Mandatory Access Control mechanism designed to provide useful MAC -while avoiding the pitfalls of its predecessors. The limitations of Bell & -LaPadula are addressed by providing a scheme whereby access can be controlled -according to the requirements of the system and its purpose rather than those -imposed by an arcane government policy. The complexity of Domain Type -Enforcement and avoided by defining access controls in terms of the access -modes already in use. - -Smack Terminology - -The jargon used to talk about Smack will be familiar to those who have dealt -with other MAC systems and shouldn't be too difficult for the uninitiated to -pick up. There are four terms that are used in a specific way and that are -especially important: - - Subject: A subject is an active entity on the computer system. - On Smack a subject is a task, which is in turn the basic unit - of execution. - - Object: An object is a passive entity on the computer system. - On Smack files of all types, IPC, and tasks can be objects. - - Access: Any attempt by a subject to put information into or get - information from an object is an access. - - Label: Data that identifies the Mandatory Access Control - characteristics of a subject or an object. - -These definitions are consistent with the traditional use in the security -community. There are also some terms from Linux that are likely to crop up: - - Capability: A task that possesses a capability has permission to - violate an aspect of the system security policy, as identified by - the specific capability. A task that possesses one or more - capabilities is a privileged task, whereas a task with no - capabilities is an unprivileged task. - - Privilege: A task that is allowed to violate the system security - policy is said to have privilege. As of this writing a task can - have privilege either by possessing capabilities or by having an - effective user of root. - -Smack Basics - -Smack is an extension to a Linux system. It enforces additional restrictions -on what subjects can access which objects, based on the labels attached to -each of the subject and the object. - -Labels - -Smack labels are ASCII character strings. They can be up to 255 characters -long, but keeping them to twenty-three characters is recommended. -Single character labels using special characters, that being anything -other than a letter or digit, are reserved for use by the Smack development -team. Smack labels are unstructured, case sensitive, and the only operation -ever performed on them is comparison for equality. Smack labels cannot -contain unprintable characters, the "/" (slash), the "\" (backslash), the "'" -(quote) and '"' (double-quote) characters. -Smack labels cannot begin with a '-'. This is reserved for special options. - -There are some predefined labels: - - _ Pronounced "floor", a single underscore character. - ^ Pronounced "hat", a single circumflex character. - * Pronounced "star", a single asterisk character. - ? Pronounced "huh", a single question mark character. - @ Pronounced "web", a single at sign character. - -Every task on a Smack system is assigned a label. The Smack label -of a process will usually be assigned by the system initialization -mechanism. - -Access Rules - -Smack uses the traditional access modes of Linux. These modes are read, -execute, write, and occasionally append. There are a few cases where the -access mode may not be obvious. These include: - - Signals: A signal is a write operation from the subject task to - the object task. - Internet Domain IPC: Transmission of a packet is considered a - write operation from the source task to the destination task. - -Smack restricts access based on the label attached to a subject and the label -attached to the object it is trying to access. The rules enforced 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. - -Smack Access Rules - -With the isolation provided by Smack access separation is simple. There are -many interesting cases where limited access by subjects to objects with -different labels is desired. One example is the familiar spy model of -sensitivity, where a scientist working on a highly classified project would be -able to read documents of lower classifications and anything she writes will -be "born" highly classified. To accommodate such schemes Smack includes a -mechanism for specifying rules allowing access between labels. - -Access Rule Format - -The format of an access rule is: - - subject-label object-label access - -Where subject-label is the Smack label of the task, object-label is the Smack -label of the thing being accessed, and access is a string specifying the sort -of access allowed. The access specification is searched for letters that -describe access modes: - - a: indicates that append access should be granted. - r: indicates that read access should be granted. - w: indicates that write access should be granted. - x: indicates that execute access should be granted. - t: indicates that the rule requests transmutation. - b: indicates that the rule should be reported for bring-up. - -Uppercase values for the specification letters are allowed as well. -Access mode specifications can be in any order. Examples of acceptable rules -are: - - TopSecret Secret rx - Secret Unclass R - Manager Game x - User HR w - Snap Crackle rwxatb - New Old rRrRr - Closed Off - - -Examples of unacceptable rules are: - - Top Secret Secret rx - Ace Ace r - Odd spells waxbeans - -Spaces are not allowed in labels. Since a subject always has access to files -with the same label specifying a rule for that case is pointless. Only -valid letters (rwxatbRWXATB) and the dash ('-') character are allowed in -access specifications. The dash is a placeholder, so "a-r" is the same -as "ar". A lone dash is used to specify that no access should be allowed. - -Applying Access Rules - -The developers of Linux rarely define new sorts of things, usually importing -schemes and concepts from other systems. Most often, the other systems are -variants of Unix. Unix has many endearing properties, but consistency of -access control models is not one of them. Smack strives to treat accesses as -uniformly as is sensible while keeping with the spirit of the underlying -mechanism. - -File system objects including files, directories, named pipes, symbolic links, -and devices require access permissions that closely match those used by mode -bit access. To open a file for reading read access is required on the file. To -search a directory requires execute access. Creating a file with write access -requires both read and write access on the containing directory. Deleting a -file requires read and write access to the file and to the containing -directory. It is possible that a user may be able to see that a file exists -but not any of its attributes by the circumstance of having read access to the -containing directory but not to the differently labeled file. This is an -artifact of the file name being data in the directory, not a part of the file. - -If a directory is marked as transmuting (SMACK64TRANSMUTE=TRUE) and the -access rule that allows a process to create an object in that directory -includes 't' access the label assigned to the new object will be that -of the directory, not the creating process. This makes it much easier -for two processes with different labels to share data without granting -access to all of their files. - -IPC objects, message queues, semaphore sets, and memory segments exist in flat -namespaces and access requests are only required to match the object in -question. - -Process objects reflect tasks on the system and the Smack label used to access -them is the same Smack label that the task would use for its own access -attempts. Sending a signal via the kill() system call is a write operation -from the signaler to the recipient. Debugging a process requires both reading -and writing. Creating a new task is an internal operation that results in two -tasks with identical Smack labels and requires no access checks. - -Sockets are data structures attached to processes and sending a packet from -one process to another requires that the sender have write access to the -receiver. The receiver is not required to have read access to the sender. - -Setting Access Rules - -The configuration file /etc/smack/accesses contains the rules to be set at -system startup. The contents are written to the special file -/sys/fs/smackfs/load2. Rules can be added at any time and take effect -immediately. For any pair of subject and object labels there can be only -one rule, with the most recently specified overriding any earlier -specification. - -Task Attribute - -The Smack label of a process can be read from /proc/<pid>/attr/current. A -process can read its own Smack label from /proc/self/attr/current. A -privileged process can change its own Smack label by writing to -/proc/self/attr/current but not the label of another process. - -File Attribute - -The Smack label of a filesystem object is stored as an extended attribute -named SMACK64 on the file. This attribute is in the security namespace. It can -only be changed by a process with privilege. - -Privilege - -A process with CAP_MAC_OVERRIDE or CAP_MAC_ADMIN is privileged. -CAP_MAC_OVERRIDE allows the process access to objects it would -be denied otherwise. CAP_MAC_ADMIN allows a process to change -Smack data, including rules and attributes. - -Smack Networking - -As mentioned before, Smack enforces access control on network protocol -transmissions. Every packet sent by a Smack process is tagged with its Smack -label. This is done by adding a CIPSO tag to the header of the IP packet. Each -packet received is expected to have a CIPSO tag that identifies the label and -if it lacks such a tag the network ambient label is assumed. Before the packet -is delivered a check is made to determine that a subject with the label on the -packet has write access to the receiving process and if that is not the case -the packet is dropped. - -CIPSO Configuration - -It is normally unnecessary to specify the CIPSO configuration. The default -values used by the system handle all internal cases. Smack will compose CIPSO -label values to match the Smack labels being used without administrative -intervention. Unlabeled packets that come into the system will be given the -ambient label. - -Smack requires configuration in the case where packets from a system that is -not Smack that speaks CIPSO may be encountered. Usually this will be a Trusted -Solaris system, but there are other, less widely deployed systems out there. -CIPSO provides 3 important values, a Domain Of Interpretation (DOI), a level, -and a category set with each packet. The DOI is intended to identify a group -of systems that use compatible labeling schemes, and the DOI specified on the -Smack system must match that of the remote system or packets will be -discarded. The DOI is 3 by default. The value can be read from -/sys/fs/smackfs/doi and can be changed by writing to /sys/fs/smackfs/doi. - -The label and category set are mapped to a Smack label as defined in -/etc/smack/cipso. - -A Smack/CIPSO mapping has the form: - - smack level [category [category]*] - -Smack does not expect the level or category sets to be related in any -particular way and does not assume or assign accesses based on them. Some -examples of mappings: - - TopSecret 7 - TS:A,B 7 1 2 - SecBDE 5 2 4 6 - RAFTERS 7 12 26 - -The ":" and "," characters are permitted in a Smack label but have no special -meaning. - -The mapping of Smack labels to CIPSO values is defined by writing to -/sys/fs/smackfs/cipso2. - -In addition to explicit mappings Smack supports direct CIPSO mappings. One -CIPSO level is used to indicate that the category set passed in the packet is -in fact an encoding of the Smack label. The level used is 250 by default. The -value can be read from /sys/fs/smackfs/direct and changed by writing to -/sys/fs/smackfs/direct. - -Socket Attributes - -There are two attributes that are associated with sockets. These attributes -can only be set by privileged tasks, but any task can read them for their own -sockets. - - SMACK64IPIN: The Smack label of the task object. A privileged - program that will enforce policy may set this to the star label. - - SMACK64IPOUT: The Smack label transmitted with outgoing packets. - A privileged program may set this to match the label of another - task with which it hopes to communicate. - -Smack Netlabel Exceptions - -You will often find that your labeled application has to talk to the outside, -unlabeled world. To do this there's a special file /sys/fs/smackfs/netlabel -where you can add some exceptions in the form of : -@IP1 LABEL1 or -@IP2/MASK LABEL2 - -It means that your application will have unlabeled access to @IP1 if it has -write access on LABEL1, and access to the subnet @IP2/MASK if it has write -access on LABEL2. - -Entries in the /sys/fs/smackfs/netlabel file are matched by longest mask -first, like in classless IPv4 routing. - -A special label '@' and an option '-CIPSO' can be used there : -@ means Internet, any application with any label has access to it --CIPSO means standard CIPSO networking - -If you don't know what CIPSO is and don't plan to use it, you can just do : -echo 127.0.0.1 -CIPSO > /sys/fs/smackfs/netlabel -echo 0.0.0.0/0 @ > /sys/fs/smackfs/netlabel - -If you use CIPSO on your 192.168.0.0/16 local network and need also unlabeled -Internet access, you can have : -echo 127.0.0.1 -CIPSO > /sys/fs/smackfs/netlabel -echo 192.168.0.0/16 -CIPSO > /sys/fs/smackfs/netlabel -echo 0.0.0.0/0 @ > /sys/fs/smackfs/netlabel - - -Writing Applications for Smack - -There are three sorts of applications that will run on a Smack system. How an -application interacts with Smack will determine what it will have to do to -work properly under Smack. - -Smack Ignorant Applications - -By far the majority of applications have no reason whatever to care about the -unique properties of Smack. Since invoking a program has no impact on the -Smack label associated with the process the only concern likely to arise is -whether the process has execute access to the program. - -Smack Relevant Applications - -Some programs can be improved by teaching them about Smack, but do not make -any security decisions themselves. The utility ls(1) is one example of such a -program. - -Smack Enforcing Applications - -These are special programs that not only know about Smack, but participate in -the enforcement of system policy. In most cases these are the programs that -set up user sessions. There are also network services that provide information -to processes running with various labels. - -File System Interfaces - -Smack maintains labels on file system objects using extended attributes. The -Smack label of a file, directory, or other file system object can be obtained -using getxattr(2). - - len = getxattr("/", "security.SMACK64", value, sizeof (value)); - -will put the Smack label of the root directory into value. A privileged -process can set the Smack label of a file system object with setxattr(2). - - len = strlen("Rubble"); - rc = setxattr("/foo", "security.SMACK64", "Rubble", len, 0); - -will set the Smack label of /foo to "Rubble" if the program has appropriate -privilege. - -Socket Interfaces - -The socket attributes can be read using fgetxattr(2). - -A privileged process can set the Smack label of outgoing packets with -fsetxattr(2). - - len = strlen("Rubble"); - rc = fsetxattr(fd, "security.SMACK64IPOUT", "Rubble", len, 0); - -will set the Smack label "Rubble" on packets going out from the socket if the -program has appropriate privilege. - - rc = fsetxattr(fd, "security.SMACK64IPIN, "*", strlen("*"), 0); - -will set the Smack label "*" as the object label against which incoming -packets will be checked if the program has appropriate privilege. - -Administration - -Smack supports some mount options: - - smackfsdef=label: specifies the label to give files that lack - the Smack label extended attribute. - - smackfsroot=label: specifies the label to assign the root of the - file system if it lacks the Smack extended attribute. - - smackfshat=label: specifies a label that must have read access to - all labels set on the filesystem. Not yet enforced. - - smackfsfloor=label: specifies a label to which all labels set on the - filesystem must have read access. Not yet enforced. - -These mount options apply to all file system types. - -Smack auditing - -If you want Smack auditing of security events, you need to set CONFIG_AUDIT -in your kernel configuration. -By default, all denied events will be audited. You can change this behavior by -writing a single character to the /sys/fs/smackfs/logging file : -0 : no logging -1 : log denied (default) -2 : log accepted -3 : log denied & accepted - -Events are logged as 'key=value' pairs, for each event you at least will get -the subject, the object, the rights requested, the action, the kernel function -that triggered the event, plus other pairs depending on the type of event -audited. - -Bringup Mode - -Bringup mode provides logging features that can make application -configuration and system bringup easier. Configure the kernel with -CONFIG_SECURITY_SMACK_BRINGUP to enable these features. When bringup -mode is enabled accesses that succeed due to rules marked with the "b" -access mode will logged. When a new label is introduced for processes -rules can be added aggressively, marked with the "b". The logging allows -tracking of which rules actual get used for that label. - -Another feature of bringup mode is the "unconfined" option. Writing -a label to /sys/fs/smackfs/unconfined makes subjects with that label -able to access any object, and objects with that label accessible to -all subjects. Any access that is granted because a label is unconfined -is logged. This feature is dangerous, as files and directories may -be created in places they couldn't if the policy were being enforced. |