https://selinuxproject.org/w/api.php?action=feedcontributions&user=Jaxelson&feedformat=atom SELinux Wiki - User contributions [en] 2024-03-29T08:07:06Z User contributions MediaWiki 1.23.13 https://selinuxproject.org/page/LibselinuxAPISummary LibselinuxAPISummary 2011-11-02T02:48:06Z <p>Jaxelson: /* API Summary for libselinux */ fix spelling of depreciated to deprecated</p> <hr /> <div>= API Summary for libselinux =<br /> The API summary has been taken from the '''libselinux 2.0.96''' release and sorted in alphabetical order. There are 166 functions available in this release, although 4 are deprecated. The appropriate man (3) pages should consulted for detailed usage.<br /> <br /> {| border=&quot;1&quot;<br /> ! Function Name<br /> ! Description<br /> ! Header File<br /> <br /> |-<br /> | avc_add_callback<br /> | Register a callback for security events.<br /> <br /> Register a callback function for events in the set @events related to the SID pair (@ssid, @tsid) and and the permissions @perms, interpreting @perms based on @tclass. Returns %0 on success or -%1 if insufficient memory exists to add the callback.<br /> | avc.h<br /> <br /> |-<br /> | avc_audit<br /> | Audit the granting or denial of permissions in accordance with the policy. This function is typically called by avc_has_perm() after a permission check, but can also be called directly by callers who use avc_has_perm_noaudit() in order to separate the permission check from the auditing. For example, this separation is useful when the permission check must be performed under a lock, to allow the lock to be released before calling the auditing code.<br /> | avc.h<br /> <br /> |-<br /> | avc_av_stats<br /> | Log AV table statistics.<br /> <br /> Log a message with information about the size and distribution of the access vector table. The audit callback is used to print the message.<br /> | avc.h<br /> <br /> |-<br /> | avc_cache_stats<br /> | Get cache access statistics.<br /> <br /> Fill the supplied structure with information about AVC activity since the last call to avc_init() or avc_reset(). See the structure definition for details.<br /> | avc.h<br /> <br /> |-<br /> | avc_cleanup<br /> | Remove unused SIDs and AVC entries.<br /> <br /> Search the SID table for SID structures with zero reference counts, and remove them along with all AVC entries that reference them. This can be used to return memory to the system.<br /> | avc.h<br /> <br /> |-<br /> | avc_compute_create<br /> | Compute SID for labeling a new object.<br /> <br /> Call the security server to obtain a context for labeling a new object. Look up the context in the SID table, making a new entry if not found. Store a pointer to the SID structure into the memory referenced by @newsid, returning %0 on success or -%1 on error with @errno set.<br /> | avc.h<br /> <br /> |-<br /> | avc_compute_member<br /> | Compute SID for polyinstantation.<br /> <br /> Call the security server to obtain a context for labeling an object instance. Look up the context in the SID table, making a new entry if not found. Store a pointer to the SID structure into the memory referenced by @newsid, returning %0 on success or -%1 on error with @errno set.<br /> | avc.h<br /> <br /> |-<br /> | avc_context_to_sid<br /> <br /> avc_context_to_sid_raw<br /> | Get SID for context. Look up security context @ctx in SID table, making a new entry if @ctx is not found. Store a pointer to the SID structure into the memory referenced by @sid,returning %0 on success or -%1 on error with @errno set.<br /> | avc.h<br /> <br /> |-<br /> | avc_destroy<br /> | Free all AVC structures.<br /> <br /> Destroy all AVC structures and free all allocated memory. User-supplied locking, memory, and audit callbacks will be retained, but security-event callbacks will not. All SID's will be invalidated. User must call avc_init() if further use of AVC is desired.<br /> | avc.h<br /> <br /> |-<br /> | avc_entry_ref_init<br /> | Initialize an AVC entry reference.<br /> <br /> Use this macro to initialize an avc entry reference structure before first use. These structures are passed to avc_has_perm(), which stores cache entry references in them. They can increase performance on repeated queries.<br /> | avc.h<br /> <br /> |-<br /> | avc_get_initial_sid<br /> | Get SID for an initial kernel security identifier.<br /> <br /> Get the context for an initial kernel security identifier specified by @name using security_get_initial_context() and then call avc_context_to_sid() to get the corresponding SID.<br /> | avc.h<br /> <br /> |-<br /> | avc_has_perm<br /> | Check permissions and perform any appropriate auditing.<br /> <br /> Check the AVC to determine whether the @requested permissions are granted for the SID pair (@ssid, @tsid), interpreting the permissions based on @tclass, and call the security server on a cache miss to obtain a new decision and add it to the cache. Update @aeref to refer to an AVC entry with the resulting decisions. Audit the granting or denial of permissions in accordance with the policy. Return %0 if all @requested permissions are granted, -%1 with @errno set to %EACCES if any permissions are denied or to another value upon other errors.<br /> | avc.h<br /> <br /> |-<br /> | avc_has_perm_noaudit<br /> | Check permissions but perform no auditing. Check the AVC to determine whether the @requested permissions are granted for the SID pair (@ssid, @tsid), interpreting the permissions based on @tclass, and call the security server on a cache miss to obtain a new decision and add it to the cache. Update @aeref to refer to an AVC entry with the resulting decisions, and return a copy of the decisions in @avd. Return %0 if all @requested permissions are granted, -%1 with @errno set to %EACCES if any permissions are denied, or to another value upon other errors. This function is typically called by avc_has_perm(), but may also be called directly to separate permission checking from auditing, e.g. in cases where a lock must be held for the check but should be released for the auditing.<br /> | avc.h<br /> <br /> |-<br /> | avc_init (deprecated)<br /> | Legacy userspace SELinux AVC setup - use &lt;tt&gt;avc_open&lt;/tt&gt;.<br /> <br /> Initialize the access vector cache. Return %0 on success or -%1 with @errno set on failure. If @msgprefix is NULL, uses &quot;uavc&quot;. If any callback structure references are NULL, use default methods for those callbacks (see the definition of the callback structures).<br /> | avc.h<br /> <br /> |-<br /> | avc_netlink_acquire_fd<br /> | Create a netlink socket and connect to the kernel.<br /> | avc.h<br /> <br /> |-<br /> | avc_netlink_check_nb<br /> | Wait for netlink messages from the kernel.<br /> | avc.h<br /> <br /> |-<br /> | avc_netlink_close<br /> | Close the netlink socket.<br /> | avc.h<br /> <br /> |-<br /> | avc_netlink_loop<br /> | Acquire netlink socket fd. Allows the application to manage messages from the netlink socket in its own main loop.<br /> | avc.h<br /> <br /> |-<br /> | avc_netlink_open<br /> | Release netlink socket fd. Returns ownership of the netlink socket to the library.<br /> | avc.h<br /> <br /> |-<br /> | avc_netlink_release_fd<br /> | Check netlink socket for new messages. Called by the application when using &lt;tt&gt;avc_netlink_acquire_fd()&lt;/tt&gt; to process kernel netlink events.<br /> | avc.h<br /> <br /> |-<br /> | avc_open<br /> | Initialize the AVC. This function is identical to avc_init() except the message prefix is set to “avc” and any callbacks desired should be specified via selinux_set_callback(). It is possible to set enforcing mode using &lt;tt&gt;AVC_OPT_SETENFORCE&lt;/tt&gt;, this will override the kernel setting.<br /> | avc.h<br /> <br /> |-<br /> | avc_reset<br /> | Flush the cache and reset statistics. Remove all entries from the cache and reset all access statistics (as returned by avc_cache_stats()) to zero. The SID mapping is not affected. Return %0 on success, -%1 with @errno set on error.<br /> | avc.h<br /> <br /> |-<br /> | avc_sid_stats<br /> | Log SID table statistics. Log a message with information about the size and distribution of the SID table. The audit callback is used to print the message.<br /> | avc.h<br /> <br /> |-<br /> | avc_sid_to_context<br /> <br /> avc_sid_to_context_raw<br /> | Get copy of context corresponding to SID. Return a copy of the security context corresponding to the input @sid in the memory referenced by @ctx. The caller is expected to free the context with freecon(). Return %0 on success, -%1 on failure, with @errno set to %ENOMEM if insufficient memory was available to make the copy, or %EINVAL if the input SID is invalid.<br /> | avc.h<br /> <br /> |-<br /> | checkPasswdAccess (deprecated)<br /> | Check a permission in the passwd class. Return 0 if granted or -1 otherwise.<br /> | selinux.h<br /> <br /> |-<br /> | context_free<br /> | Free the storage used by a context.<br /> | context.h<br /> <br /> |-<br /> | context_new<br /> | Return a new context initialized to a context string.<br /> | context.h<br /> <br /> |-<br /> | context_range_get<br /> | Get a pointer to the range.<br /> | context.h<br /> <br /> |-<br /> | context_range_set<br /> | Set the range component. Returns nonzero if unsuccessful.<br /> | context.h<br /> <br /> |-<br /> | context_role_get<br /> | Get a pointer to the role.<br /> | context.h<br /> <br /> |-<br /> | context_role_set<br /> | Set the role component. Returns nonzero if unsuccessful.<br /> | context.h<br /> <br /> |-<br /> | context_str<br /> | Return a pointer to the string value of context_t. Valid until the next call to context_str or context_free for the same context_t*.<br /> | context.h<br /> <br /> |-<br /> | context_type_get<br /> | Get a pointer to the type.<br /> | context.h<br /> <br /> |-<br /> | context_type_set<br /> | Set the type component. Returns nonzero if unsuccessful.<br /> | context.h<br /> <br /> |-<br /> | context_user_get<br /> | Get a pointer to the user.<br /> | context.h<br /> <br /> |-<br /> | context_user_set<br /> | Set the user component. Returns nonzero if unsuccessful.<br /> | context.h<br /> <br /> |-<br /> | fgetfilecon<br /> <br /> fgetfilecon_raw<br /> | Wrapper for the xattr API - Get file context, and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | fini_selinuxmnt<br /> | Deinitialises the global variable selinux_mnt to the selinuxfs mountpoint.<br /> | <br /> <br /> |-<br /> | freecon<br /> | Free the memory allocated for a context by any of the get* calls.<br /> | selinux.h<br /> <br /> |-<br /> | freeconary<br /> | Free the memory allocated for a context array by security_compute_user.<br /> | selinux.h<br /> <br /> |-<br /> | fsetfilecon<br /> <br /> fsetfilecon_raw<br /> | Wrapper for the xattr API- Set file context.<br /> | selinux.h<br /> <br /> |-<br /> | get_default_context<br /> | Get the default security context for a user session for 'user' spawned by 'fromcon' and set &lt;nowiki&gt;*newcon&lt;/nowiki&gt; to refer to it. The context will be one of those authorized by the policy, but the selection of a default is subject to user customizable preferences. If 'fromcon' is NULL, defaults to current context. Returns 0 on success or -1 otherwise. Caller must free via freecon. <br /> | get_context_list.h<br /> <br /> |-<br /> | get_default_context_with_level<br /> | Same as get_default_context, but use the provided MLS level rather than the default level for the user. <br /> | get_context_list.h<br /> <br /> |-<br /> | get_default_context_with_role<br /> | Same as get_default_context, but only return a context that has the specified role.<br /> | get_context_list.h<br /> <br /> |-<br /> | get_default_context_with_rolelevel<br /> | Same as get_default_context, but only return a context that has the specified role and level.<br /> | get_context_list.h<br /> <br /> |-<br /> | get_default_type<br /> | Get the default type (domain) for 'role' and set 'type' to refer to it. Caller must free via free(). Return 0 on success or -1 otherwise. <br /> | get_default_type.h<br /> <br /> |-<br /> | get_ordered_context_list<br /> | Get an ordered list of authorized security contexts for a user session for 'user' spawned by 'fromcon' and set &lt;nowiki&gt;*conary&lt;/nowiki&gt; to refer to the NULL-terminated array of contexts. Every entry in the list will be authorized by the policy, but the ordering is subject to user customizable preferences. Returns number of entries in &lt;nowiki&gt;*conary&lt;/nowiki&gt;. If 'fromcon' is NULL, defaults to current context. Caller must free via freeconary.<br /> | get_context_list.h<br /> <br /> |-<br /> | get_ordered_context_list_with_level<br /> | Same as get_ordered_context_list, but use the provided MLS level rather than the default level for the user.<br /> | get_context_list.h<br /> <br /> |-<br /> | getcon<br /> <br /> getcon_raw<br /> | Get current context, and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Caller must free via freecon. <br /> | selinux.h<br /> <br /> |-<br /> | getexeccon<br /> <br /> getexeccon_raw<br /> | Get exec context, and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Sets &lt;nowiki&gt;*con&lt;/nowiki&gt; to NULL if no exec context has been set, i.e. using default. If non-NULL, caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | getfilecon<br /> <br /> getfilecon_raw<br /> | Wrapper for the xattr API - Get file context, and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | getfscreatecon<br /> <br /> getfscreatecon_raw<br /> | Get fscreate context, and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Sets &lt;nowiki&gt;*con&lt;/nowiki&gt; to NULL if no fs create context has been set, i.e. using default.If non-NULL, caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | getkeycreatecon<br /> <br /> getkeycreatecon_raw<br /> | Get keycreate context, and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Sets &lt;nowiki&gt;*con&lt;/nowiki&gt; to NULL if no key create context has been set, i.e. using default. If non-NULL, caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | getpeercon<br /> <br /> getpeercon_raw<br /> | Wrapper for the socket API - Get context of peer socket, and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | getpidcon<br /> <br /> getpidcon_raw<br /> | Get context of process identified by pid, and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | getprevcon<br /> <br /> getprevcon_raw<br /> | Get previous context (prior to last exec), and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | getseuser<br /> | Get the SELinux username and level to use for a given Linux username and service. These values may then be passed into the get_ordered_context_list* and get_default_context* functions to obtain a context for the user. Returns 0 on success or -1 otherwise. Caller must free the returned strings via free().<br /> | selinux.h<br /> <br /> |-<br /> | getseuserbyname<br /> | Get the SELinux username and level to use for a given Linux username. These values may then be passed into the get_ordered_context_list* and get_default_context* functions to obtain a context for the user. Returns 0 on success or -1 otherwise. Caller must free the returned strings via free().<br /> | selinux.h<br /> <br /> |-<br /> | getsockcreatecon<br /> <br /> getsockcreatecon_raw<br /> | Get sockcreate context, and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Sets &lt;nowiki&gt;*con&lt;/nowiki&gt; to NULL if no socket create context has been set, i.e. using default. If non-NULL, caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | init_selinuxmnt<br /> | Initialises the global variable selinux_mnt to the selinuxfs mountpoint.<br /> | <br /> <br /> |-<br /> | is_context_customizable<br /> | Returns whether a file context is customizable, and should not be relabeled.<br /> | selinux.h<br /> <br /> |-<br /> | is_selinux_enabled<br /> | Return 1 if running on a SELinux kernel, or 0 if not or -1 for error.<br /> | selinux.h<br /> <br /> |-<br /> | is_selinux_mls_enabled<br /> | Return 1 if we are running on a SELinux MLS kernel, or 0 otherwise.<br /> | selinux.h<br /> <br /> |-<br /> | lgetfilecon<br /> <br /> lgetfilecon_raw<br /> | Wrapper for the xattr API - Get file context, and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to it. Caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | lsetfilecon<br /> <br /> lsetfilecon_raw<br /> | Wrapper for the xattr API- Set file context for symbolic link.<br /> | selinux.h<br /> <br /> |-<br /> | manual_user_enter_context<br /> | Allow the user to manually enter a context as a fallback if a list of authorized contexts could not be obtained. Caller must free via freecon. Returns 0 on success or -1 otherwise. <br /> | get_context_list.h<br /> <br /> |-<br /> | matchmediacon<br /> | Match the specified media and against the media contexts configuration and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to the resulting context. Caller must free con via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | matchpathcon<br /> | Match the specified pathname and mode against the file context sconfiguration and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to the resulting context.'mode' can be 0 to disable mode matching. Caller must free via freecon. If matchpathcon_init has not already been called, then this function will call it upon its first invocation with a NULL path.<br /> | selinux.h<br /> <br /> |-<br /> | matchpathcon_checkmatches<br /> | Check to see whether any specifications had no matches and report them. The 'str' is used as a prefix for any warning messages.<br /> | selinux.h<br /> <br /> |-<br /> | matchpathcon_filespec_add<br /> | Maintain an association between an inode and a specification index, and check whether a conflicting specification is already associated with the same inode (e.g. due to multiple hard links). If so, then use the latter of the two specifications based on their order in the file contexts configuration. Return the used specification index. <br /> | selinux.h<br /> <br /> |-<br /> | matchpathcon_filespec_destroy<br /> | Destroy any inode associations that have been added, e.g. to restart for a new filesystem. <br /> | selinux.h<br /> <br /> |-<br /> | matchpathcon_filespec_eval<br /> | Display statistics on the hash table usage for the associations.<br /> | selinux.h<br /> <br /> |-<br /> | matchpathcon_fini<br /> | Free the memory allocated by matchpathcon_init.<br /> | selinux.h<br /> <br /> |-<br /> | matchpathcon_index <br /> | Same as matchpathcon, but return a specification index for later use in a matchpathcon_filespec_add() call.<br /> | selinux.h<br /> <br /> |-<br /> | matchpathcon_init<br /> | Load the file contexts configuration specified by 'path' into memory for use by subsequent matchpathcon calls. If 'path' is NULL, then load the active file contexts configuration, i.e. the path returned by selinux_file_context_path(). Unless the MATCHPATHCON_BASEONLY flag has been set, this function also checks for a 'path'.homedirs file and a 'path'.local file and loads additional specifications from them if present.<br /> | selinux.h<br /> <br /> |-<br /> | matchpathcon_init_prefix<br /> | Same as matchpathcon_init, but only load entries with regexes that have stems that are prefixes of 'prefix'.<br /> | selinux.h<br /> <br /> |-<br /> | print_access_vector<br /> | Display an access vector in a string representation.<br /> | selinux.h<br /> <br /> |-<br /> | query_user_context<br /> | Given a list of authorized security contexts for the user, query the user to select one and set &lt;nowiki&gt;*newcon&lt;/nowiki&gt; to refer to it. Caller must free via freecon. Returns 0 on sucess or -1 otherwise. <br /> | get_context_list.h<br /> <br /> |-<br /> | rpm_execcon<br /> | Execute a helper for rpm in an appropriate security context.<br /> | selinux.h<br /> <br /> |-<br /> | security_av_perm_to_string<br /> | Convert access vector permissions to string names.<br /> | selinux.h<br /> <br /> |-<br /> | security_av_string<br /> | Returns an access vector in a string representation. User must free the returned string via free().<br /> | selinux.h<br /> <br /> |-<br /> | security_canonicalize_context<br /> <br /> security_canonicalize_context_raw<br /> | Canonicalize a security context.<br /> | selinux.h<br /> <br /> |-<br /> | security_check_context<br /> <br /> security_check_context_raw<br /> | Check the validity of a security context.<br /> | selinux.h<br /> <br /> |-<br /> | security_class_to_string<br /> | Convert security class values to string names.<br /> | selinux.h<br /> <br /> |-<br /> | security_commit_booleans<br /> | Commit the pending values for the booleans.<br /> | selinux.h<br /> <br /> |-<br /> | security_compute_av<br /> <br /> security_compute_av_raw<br /> | Compute an access decision.<br /> | selinux.h<br /> <br /> |-<br /> | security_compute_av_flags<br /> <br /> security_compute_av_flags_raw<br /> | <br /> | selinux.h<br /> <br /> |-<br /> | security_compute_create<br /> <br /> security_compute_create_raw<br /> | Compute a labeling decision and set &lt;nowiki&gt;*newcon&lt;/nowiki&gt; to refer to it. Caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | security_compute_member<br /> <br /> security_compute_member_raw<br /> | Compute a polyinstantiation member decision and set &lt;nowiki&gt;*newcon&lt;/nowiki&gt; to refer to it. Caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | security_compute_relabel<br /> <br /> security_compute_relabel_raw<br /> | Compute a relabeling decision and set &lt;nowiki&gt;*newcon&lt;/nowiki&gt; to refer to it. Caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | security_compute_user<br /> <br /> security_compute_user_raw<br /> | Compute the set of reachable user contexts and set &lt;nowiki&gt;*con&lt;/nowiki&gt; to refer to the NULL-terminated array of contexts. Caller must free via freeconary. <br /> | selinux.h<br /> <br /> |-<br /> | security_deny_unknown<br /> | Get the behavior for undefined classes / permissions.<br /> | selinux.h<br /> <br /> |-<br /> | security_disable<br /> | Disable SELinux at runtime (must be done prior to initial policy load).<br /> | selinux.h<br /> <br /> |-<br /> | security_get_boolean_active<br /> | Get the active value for the boolean.<br /> | selinux.h<br /> <br /> |-<br /> | security_get_boolean_names<br /> | Get the boolean names<br /> | selinux.h<br /> <br /> |-<br /> | security_get_boolean_pending<br /> | Get the pending value for the boolean.<br /> | selinux.h<br /> <br /> |-<br /> | security_get_initial_context<br /> <br /> security_get_initial_context_raw<br /> | Get the context of an initial kernel security identifier by name. Caller must free via freecon.<br /> | selinux.h<br /> <br /> |-<br /> | security_getenforce<br /> | Get the enforce flag value.<br /> | selinux.h<br /> <br /> |-<br /> | security_load_booleans<br /> | Load policy boolean settings. Path may be NULL, in which case the booleans are loaded from the active policy boolean configuration file.<br /> | selinux.h<br /> <br /> |-<br /> | security_load_policy<br /> | Load a policy configuration.<br /> | selinux.h<br /> <br /> |-<br /> | '''selinux_mkload_policy'''<br /> | Make a policy image and load it. This is a higher level interface for loading policy than &lt;tt&gt;security_load_policy&lt;/tt&gt;.<br /> | selinux.h<br /> <br /> |-<br /> | security_policyvers<br /> | Get the policy version number.<br /> | selinux.h<br /> <br /> |-<br /> | security_set_boolean<br /> | Set the pending value for the boolean.<br /> | selinux.h<br /> <br /> |-<br /> | security_set_boolean_list<br /> | Save a list of booleans in a single transaction.<br /> | selinux.h<br /> <br /> |-<br /> | security_setenforce<br /> | Set the enforce flag value.<br /> | selinux.h<br /> <br /> |-<br /> | selabel_close<br /> | Destroy the specified handle, closing files, freeing allocated memory, etc. The handle may not be further used after it has been closed.<br /> | label.h<br /> <br /> |-<br /> | selabel_lookup<br /> <br /> selabel_lookup_raw<br /> | Perform a labeling lookup operation. Return %0 on success, -%1 with @errno set on failure. The key and type arguments are the inputs to the lookup operation; appropriate values are dictated by the backend in use. The result is returned in the memory pointed to by @con and must be freed by the user with freecon().<br /> | label.h<br /> <br /> |-<br /> | selabel_open<br /> | Create a labeling handle.<br /> <br /> Open a labeling backend for use. The available backend identifiers are:<br /> <br /> SELABEL_CTX_FILE - file_contexts.<br /> <br /> SELABEL_CTX_MEDIA - media contexts.<br /> <br /> SELABEL_CTX_X - x_contexts.<br /> <br /> SELABEL_CTX_DB - pgsql_contexts.<br /> <br /> Options may be provided via the opts parameter; available options are:<br /> <br /> SELABEL_OPT_UNUSED - no-op option, useful for unused slots in an array of options.<br /> <br /> SELABEL_OPT_VALIDATE - validate contexts before returning them (boolean value).<br /> <br /> SELABEL_OPT_BASEONLY - don't use local customizations to backend data (boolean value).<br /> <br /> SELABEL_OPT_PATH - specify an alternate path to use when loading backend data.<br /> <br /> SELABEL_OPT_SUBSET - select a subset of the search space as an optimization (file backend).<br /> <br /> Not all options may be supported by every backend. Return value is the created handle on success or NULL with @errno set on failure.<br /> | label.h<br /> <br /> |-<br /> | selabel_stats<br /> | Log a message with information about the number of queries performed, number of unused matching entries, or other operational statistics. Message is backend-specific, some backends may not output a message.<br /> | label.h<br /> <br /> |-<br /> | selinux_binary_policy_path<br /> | Return path to the binary policy file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_booleans_path<br /> | Return path to the booleans file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_check_passwd_access<br /> | Check a permission in the passwd class. Return 0 if granted or -1 otherwise.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_check_securetty_context <br /> | Check if the tty_context is defined as a securetty&lt;nowiki&gt;. Return 0 if secure, &lt; 0 otherwise.&lt;/nowiki&gt;<br /> | selinux.h<br /> <br /> |-<br /> | selinux_colors_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_contexts_path<br /> | Return path to contexts directory under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_customizable_types_path<br /> | Return path to customizable_types file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_default_context_path<br /> | Return path to default_context file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_default_type_path<br /> | Return path to default type file.<br /> | get_default_type.h<br /> <br /> |-<br /> | selinux_failsafe_context_path<br /> | Return path to failsafe_context file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_file_context_cmp<br /> | Compare two file contexts, return 0 if equivalent.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_file_context_homedir_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_file_context_local_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_file_context_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_file_context_subs_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_file_context_verify<br /> | Verify the context of the file 'path' against policy. Return 0 if correct.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_getenforcemode<br /> | Reads the /etc/selinux/config file and determines whether the machine should be started in enforcing (1), permissive (0) or disabled (-1) mode. <br /> | selinux.h<br /> <br /> |-<br /> | selinux_getpolicytype<br /> | Reads the /&lt;tt&gt;etc/selinux/config&lt;/tt&gt; file and determines what the default policy for the machine is. Calling application must free policytype.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_homedir_context_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_init_load_policy<br /> | Perform the initial policy load.<br /> <br /> This function determines the desired enforcing mode, sets the the &lt;nowiki&gt;*enforce&lt;/nowiki&gt; argument accordingly for the caller to use, sets the SELinux kernel enforcing status to match it, and loads the policy. It also internally handles the initial selinuxfs mount required to perform these actions.<br /> <br /> The function returns 0 if everything including the policy load succeeds. In this case, init is expected to re-exec itself in order to transition to the proper security context. Otherwise, the function returns -1, and init must check &lt;nowiki&gt;*enforce&lt;/nowiki&gt; to determine how to proceed. If enforcing (&lt;nowiki&gt;*enforce&lt;/nowiki&gt; &gt; 0), then init should halt the system. Otherwise, init may proceed normally without a re-exec.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_lsetfilecon_default<br /> | This function sets the file context on to the system defaults returns 0 on success.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_media_context_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_mkload_policy<br /> | Make a policy image and load it. <br /> <br /> This function provides a higher level interface for loading policy than security_load_policy, internally determining the right policy version, locating and opening the policy file, mapping it into memory, manipulating it as needed for current boolean settings and/or local definitions, and then calling security_load_policy to load it.<br /> <br /> 'preservebools' is a boolean flag indicating whether current policy boolean values should be preserved into the new policy (if 1) or reset to the saved policy settings (if 0). The former case is the default for policy reloads, while the latter case is an option for policy reloads but is primarily for the initial policy load.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_netfilter_context_path<br /> | Returns path to the netfilter_context file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_path<br /> | Returns path to the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_policy_root<br /> | Reads the /etc/selinux/config file and returns the top level directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_raw_context_to_color<br /> | Perform context translation between security contexts and display colors. Returns a space-separated list of ten ten hex RGB triples prefixed by hash marks, e.g. &quot;&lt;nowiki&gt;#ff0000&lt;/nowiki&gt;&quot;. Caller must free the resulting string via free(). Returns -1 upon an error or 0 otherwise.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_raw_to_trans_context<br /> | Perform context translation between the human-readable format (&quot;translated&quot;) and the internal system format (&quot;raw&quot;). Caller must free the resulting context via freecon. Returns -1 upon an error or 0 otherwise. If passed NULL, sets the returned context to NULL and returns 0.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_removable_context_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_reset_config<br /> | Force a reset of the loaded configuration. Not thread-safe.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_securetty_types_path<br /> | Return path to the securetty_types file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_sepgsql_context_path<br /> | Return path to the &lt;tt&gt;sepgsql_context&lt;/tt&gt; file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_set_callback<br /> | Sets up a call back for the following events:<br /> <br /> &lt;tt&gt;SELINUX_CB_LOG&lt;/tt&gt; - to add additional info to audit log.<br /> <br /> &lt;tt&gt;SELINUX_CB_AUDIT&lt;/tt&gt; - to add additional audit info when using calls like &lt;tt&gt;avc_has_perm&lt;/tt&gt; that can cause an audit evet to be generated.<br /> <br /> &lt;tt&gt;SELINUX_CB_VALIDATE&lt;/tt&gt; - to validate a context (used by &lt;tt&gt;setfiles&lt;/tt&gt; for setting contexts on policies that are not active - see&lt;tt&gt; setfiles.c&lt;/tt&gt;).<br /> <br /> &lt;tt&gt;SELINUX_CB_SETENFORCE&lt;/tt&gt; - to run user defined functions whenever the state changes.<br /> <br /> &lt;tt&gt;SELINUX_CB_POLICYLOAD&lt;/tt&gt; - to run user defined functions whenever the policy is reloaded.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_set_mapping<br /> | Userspace class mapping support.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_trans_to_raw_context<br /> | Perform context translation between the human-readable format (&quot;translated&quot;) and the internal system format (&quot;raw&quot;). Caller must free the resulting context via freecon. Returns -1 upon an error or 0 otherwise. If passed NULL, sets the returned context to NULL and returns 0.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_translations_path<br /> | Return path to setrans.conf file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_user_contexts_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_users_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_usersconf_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_virtual_domain_context_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_virtual_image_context_path<br /> | Return path to file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | selinux_x_context_path<br /> | Return path to x_context file under the policy root directory.<br /> | selinux.h<br /> <br /> |-<br /> | set_matchpathcon_canoncon<br /> | Same as set_matchpathcon_invalidcon but also allows canonicalization of the context, by changing &lt;nowiki&gt;*context&lt;/nowiki&gt; to refer to the canonical form. If not set, and invalidcon is also not set, then this defaults to calling security_canonicalize_context().<br /> | selinux.h<br /> <br /> |-<br /> | set_matchpathcon_flags<br /> | Set flags controlling operation of matchpathcon_init or matchpathcon: <br /> <br /> MATCHPATHCON_BASEONLY - Only process the base file_contexts file. <br /> <br /> MATCHPATHCON_NOTRANS - Do not perform any context translation.<br /> <br /> MATCHPATHCON_VALIDATE - Validate/canonicalize contexts at init time.<br /> | selinux.h<br /> <br /> |-<br /> | set_matchpathcon_invalidcon<br /> | Set the function used by matchpathcon_init when checking the validity of a context in the file_contexts configuration. If not set, then this defaults to a test based on security_check_context(). The function is also responsible for reporting any such error, and may include the 'path' and 'lineno' in such error messages.<br /> | selinux.h<br /> <br /> |-<br /> | set_matchpathcon_printf<br /> | Set the function used by matchpathcon_init when displaying errors about the file_contexts configuration. If not set, then this defaults to fprintf(stderr, fmt, ...).<br /> | selinux.h<br /> <br /> |-<br /> | set_selinuxmnt <br /> | Set the path to the selinuxfs mount point explicitly. Normally, this is determined automatically during libselinux initialization, but this is not always possible, e.g. for /sbin/init which performs the initial mount of selinuxfs.<br /> | selinux.h<br /> <br /> |-<br /> | setcon<br /> <br /> setcon_raw<br /> | Set the current security context to con.<br /> <br /> Note that use of this function requires that the entire application be trusted to maintain any desired separation between the old and new security contexts, unlike exec-based transitions performed via setexeccon. When possible, decompose your application and use setexeccon()+execve() instead. Note that the application may lose access to its open descriptors as a result of a setcon() unless policy allows it to use descriptors opened by the old context. <br /> | selinux.h<br /> <br /> |-<br /> | setexeccon<br /> <br /> setexeccon_raw<br /> | Set exec security context for the next execve. Call with NULL if you want to reset to the default.<br /> | selinux.h<br /> <br /> |-<br /> | setfilecon<br /> <br /> setfilecon_raw<br /> | Wrapper for the xattr API - Set file context.<br /> | selinux.h<br /> <br /> |-<br /> | setfscreatecon<br /> <br /> setfscreatecon_raw<br /> | Set the fscreate security context for subsequent file creations. Call with NULL if you want to reset to the default.<br /> | selinux.h<br /> <br /> |-<br /> | setkeycreatecon<br /> <br /> setkeycreatecon_raw<br /> | Set the keycreate security context for subsequent key creations. Call with NULL if you want to reset to the default.<br /> | selinux.h<br /> <br /> |-<br /> | setsockcreatecon<br /> <br /> setsockcreatecon_raw<br /> | Set the sockcreate security context for subsequent socket creations. Call with NULL if you want to reset to the default.<br /> | selinux.h<br /> <br /> |-<br /> | sidget (deprecated)<br /> | From 2.0.86 this is a no-op.<br /> | avc.h<br /> <br /> |-<br /> | sidput (deprecated)<br /> | From 2.0.86 this is a no-op.<br /> | avc.h<br /> <br /> |-<br /> | string_to_av_perm<br /> | Convert string names to access vector permissions.<br /> | selinux.h<br /> <br /> |-<br /> | string_to_security_class<br /> | Convert string names to security class values.<br /> | selinux.h<br /> <br /> |}</div> Jaxelson https://selinuxproject.org/page/ObjectClassesPerms ObjectClassesPerms 2011-09-16T01:08:51Z <p>Jaxelson: /* dir */ added some descriptions</p> <hr /> <div>= '''SELinux Object Classes and Permissions Reference''' =<br /> This document contains a list of all of the object classes and permissions for modern SELinux systems (starting in kernel 2.6.0). Each permission has a brief description of of the semantics of each permission, in addition to the versions of the kernel which support the permission and the policy capability that enables its enforcement (if applicable).<br /> <br /> The document has the following caveats:<br /> * The permission descriptions are only for providing a general idea of the purposes of the permissions; a permission may mediate many operations.<br /> * Since SELinux development is ongoing, this document may be be incomplete or inaccurate.<br /> <br /> == Common Permission Sets ==<br /> === common database ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||create||Create a new database object.<br /> |-<br /> ||drop||Remove a database object.<br /> |-<br /> ||getattr||Get the attributes of a database object.<br /> |-<br /> ||setattr||Set the attributes of a database object.<br /> |-<br /> ||relabelfrom||Change the security context based on existing type.<br /> |-<br /> ||relabelto||Change the security context based on the new type.<br /> |}<br /> <br /> === common file ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||getattr||Get file attributes for block file, such as access mode. (e.g. stat, some ioctls. ...)<br /> |-<br /> ||relabelto||Change the security context based on the new type.<br /> |-<br /> ||unlink||Remove hard link (delete).<br /> |-<br /> ||ioctl||IO control system call requests not addressed by other permissions.<br /> |-<br /> ||execute||Execute<br /> |-<br /> ||append||Append file contents. i.e opened with O_APPEND flag.<br /> |-<br /> ||read||Read file contents.<br /> |-<br /> ||setattr||Change file attributes for block file such as access mode. (e.g. chmod, some ioctls, ...)<br /> |-<br /> ||swapon||Allows file to be used for paging/swapping space.<br /> |-<br /> ||write||Write or append file contents.<br /> |-<br /> ||lock||Set and unset block file locks.<br /> |-<br /> ||create||Create new block file.<br /> |-<br /> ||rename||Rename a hard link.<br /> |-<br /> ||mounton||Use as mount point; only useful for directories and files in Linux.<br /> |-<br /> ||quotaon||Enabling quotas.<br /> |-<br /> ||relabelfrom||Change the security context based on existing type.<br /> |-<br /> ||link||Create hard link to block files<br /> |}<br /> <br /> === common ipc ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||write||Write or append.<br /> |-<br /> ||destroy||Destroy.<br /> |-<br /> ||unix_write||Write or append; required by IPC operations.<br /> |-<br /> ||getattr||Get file attributes, such as access mode. (e.g. stat, some ioctls. ...)<br /> |-<br /> ||create||Create.<br /> |-<br /> ||read||Read.<br /> |-<br /> ||setattr||Change file attributes for shared memory segment such as access mode. (e.g. chmod, some ioctls, ...)<br /> |-<br /> ||unix_read||Read; required by IPC operations.<br /> |-<br /> ||associate||Associate a key<br /> |}<br /> <br /> === common socket ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||append||Write or append socket file contents.<br /> |-<br /> ||relabelfrom||Change the security context based on existing type.<br /> |-<br /> ||create||Create new socket file.<br /> |-<br /> ||read||Read socket file contents.<br /> |-<br /> ||sendto||Send datagrams to socket.<br /> |-<br /> ||connect||Initiate connection.<br /> |-<br /> ||recvfrom||Receive datagrams from socket.<br /> |-<br /> ||send_msg||Send datagram message; implicitly granted if the message SID is equal to the sending socket SID.<br /> |-<br /> ||bind||Bind name.<br /> |-<br /> ||lock||Set and unset socket file locks<br /> |-<br /> ||ioctl||IO control system call requests not addressed by other permissions.<br /> |-<br /> ||getattr||Get file attributes for socket file, such as access mode. (e.g. stat, some ioctls. ...)<br /> |-<br /> ||write||Write or append socket file contents.<br /> |-<br /> ||setopt||Set socket options.<br /> |-<br /> ||getopt||Get socket options.<br /> |-<br /> ||listen||Listen for connections.<br /> |-<br /> ||setattr||Change file attributes for file such as access mode. (e.g. chmod, some ioctls)<br /> |-<br /> ||shutdown||Shutdown connection.<br /> |-<br /> ||relabelto||Change the security context based on the new type.<br /> |-<br /> ||recv_msg||Receive datagram message; implicitly granted if the message SID is equal to the sending socket SID.<br /> |-<br /> ||accept||Accept a connection.<br /> |-<br /> ||name_bind||Use port or file; for AF_INET sockets, controls relationship between a socket and it's port number; for AF_UNIX sockets, controls relationship between a socket and it's file<br /> |}<br /> <br /> === common x_device ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||getattr<br /> |-<br /> ||setattr<br /> |-<br /> ||use<br /> |-<br /> ||read<br /> |-<br /> ||write<br /> |-<br /> ||getfocus<br /> |-<br /> ||setfocus<br /> |-<br /> ||bell<br /> |-<br /> ||force_cursor<br /> |-<br /> ||freeze<br /> |-<br /> ||grab<br /> |-<br /> ||manage<br /> |-<br /> ||list_property<br /> |-<br /> ||get_property<br /> |-<br /> ||set_property<br /> |-<br /> ||add<br /> |-<br /> ||remove<br /> |}<br /> <br /> == Kernel Object Classes ==<br /> === appletalk_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.18+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.18+<br /> |-<br /> ||create||see common socket:create||2.6.18+<br /> |-<br /> ||read||see common socket:read||2.6.18+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.18+<br /> |-<br /> ||connect||see common socket:connect||2.6.18+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.18+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.18+<br /> |-<br /> ||bind||see common socket:bind||2.6.18+<br /> |-<br /> ||lock||see common socket:lock||2.6.18+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.18+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.18+<br /> |-<br /> ||write||see common socket:write||2.6.18+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.18+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.18+<br /> |-<br /> ||listen||see common socket:listen||2.6.18+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.18+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.18+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.18+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.18+<br /> |-<br /> ||accept||see common socket:accept||2.6.18+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.18+<br /> |}<br /> <br /> === association ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||sendto||Send to an IPSEC assocation.||2.6.12+<br /> |-<br /> ||recvfrom||Receive from an IPSEC association.||2.6.12+<br /> |-<br /> ||setcontext||Set the context of an IPSEC association on creation.||2.6.16+<br /> |-<br /> ||polmatch||Match an IPSEC policy entry||2.6.19+<br /> |}<br /> <br /> === blk_file ===<br /> Inherits from: [[#common file|common file]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||getattr||see common file:getattr<br /> |-<br /> ||relabelto||see common file:relabelto<br /> |-<br /> ||unlink||see common file:unlink<br /> |-<br /> ||ioctl||see common file:ioctl<br /> |-<br /> ||execute||see common file:execute<br /> |-<br /> ||append||see common file:append<br /> |-<br /> ||read||see common file:read<br /> |-<br /> ||setattr||see common file:setattr<br /> |-<br /> ||swapon||see common file:swapon<br /> |-<br /> ||write||see common file:write<br /> |-<br /> ||lock||see common file:lock<br /> |-<br /> ||create||see common file:create<br /> |-<br /> ||rename||see common file:rename<br /> |-<br /> ||mounton||see common file:mounton<br /> |-<br /> ||quotaon||see common file:quotaon<br /> |-<br /> ||relabelfrom||see common file:relabelfrom<br /> |-<br /> ||link||see common file:link<br /> |-<br /> ||open||Open a block device file.||2.6.26+ / open_perms<br /> |}<br /> <br /> === capability ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||chown||Allow changing file ownership and group ownership.<br /> |-<br /> ||dac_override||Overrides all discretionary access control including ACL execute access if applicable. This does not include the access covered by LINUX_IMMUTABLE.<br /> |-<br /> ||dac_read_search||Overrides all discretionary access control for reading and searching directories.<br /> |-<br /> ||fowner||Grant all file operations otherwise restricted due to different ownership except where FSETID capability is applicable. DAC and MAC accesses are not overridden.<br /> |-<br /> ||fsetid||Overrides the restriction that the real or effective user ID of a process sending a signal must match the real or effective user ID of the process receiving the signal.<br /> |-<br /> ||kill||Allow signal raising for any process.<br /> |-<br /> ||setgid||Allow setgid(2) allow setgroups(2) allow fake gids on credentials passed over a socket.<br /> |-<br /> ||setuid||Allow all setsuid(2) type calls including fsuid. Allow passing of forged pids on credentials passed over a socket.<br /> |-<br /> ||setpcap||Transfer capability maps from current process to any process.<br /> |-<br /> ||linux_immutable||Grant privilege to modify S_IMMUTABLE and S_APPEND file attributes on supporting filesystems.<br /> |-<br /> ||net_bind_service||Allow low port binding. Port &lt; 1024 for TCP/UDP. VCI &lt; 32 for ATM.<br /> |-<br /> ||net_broadcast||Grant network broadcasting and listening to incoming multicasts.<br /> |-<br /> ||net_admin||Allows all networking configurations and modifications. See linux/capability.h for details.<br /> |-<br /> ||net_raw||Allows opening of raw sockets and packet sockets.<br /> |-<br /> ||ipc_lock||Grants the capability to lock non-shared and shared memory segments.<br /> |-<br /> ||ipc_owner||Grant the ability to ignore IPC ownership checks.<br /> |-<br /> ||sys_module||Allow unrestricted kernel modification including but not limited to loading and removing kernel modules. Allows modification of kernels bounding capability mask. See sysctl.<br /> |-<br /> ||sys_rawio||Grant permission to use ioperm(2) and iopl(2) as well as the ability to send messages to USB devices via /proc/bus/usb.<br /> |-<br /> ||sys_chroot||Grant use of the chroot(2) call.<br /> |-<br /> ||sys_ptrace||Allow a ptrace of any process.<br /> |-<br /> ||sys_pacct||Allow modification of accounting for any process.<br /> |-<br /> ||sys_admin||Too many to list here (see /usr/include/linux/capability.h)<br /> |-<br /> ||sys_boot||Grant ability to reboot the system.<br /> |-<br /> ||sys_nice||Grants privilage to change priority of any process. Grants change of scheduling algorithm used by any process.<br /> |-<br /> ||sys_resource||Too many to list here (see /usr/include/linux/capability.h for details.)<br /> |-<br /> ||sys_time||Grant permission to set system time and to set the real-time lock.<br /> |-<br /> ||sys_tty_config||Grant permission to configure tty devices. Allow vhangup(2) call on a tty.<br /> |-<br /> ||mknod||Grants permission to creation of character and block device nodes.<br /> |-<br /> ||lease||Grants ability to take leases on a file. For details on what leases are see fcntl(2).<br /> |-<br /> ||audit_write||Send audit messsages from user space.||2.6.12+<br /> |-<br /> ||audit_control||Change auditing rules. Set login UID.||2.6.12+<br /> |-<br /> ||setfcap||Set file capabilities.||2.6.25+<br /> |}<br /> <br /> === capability2 ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||mac_override||''Unused by SELinux''||2.6.25+<br /> |-<br /> ||mac_admin||''Unused by SELinux''||2.6.25+<br /> |}<br /> <br /> === chr_file ===<br /> Inherits from: [[#common file|common file]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||getattr||see common file:getattr<br /> |-<br /> ||relabelto||see common file:relabelto<br /> |-<br /> ||unlink||see common file:unlink<br /> |-<br /> ||ioctl||see common file:ioctl<br /> |-<br /> ||execute||see common file:execute<br /> |-<br /> ||append||see common file:append<br /> |-<br /> ||read||see common file:read<br /> |-<br /> ||setattr||see common file:setattr<br /> |-<br /> ||swapon||see common file:swapon<br /> |-<br /> ||write||see common file:write<br /> |-<br /> ||lock||see common file:lock<br /> |-<br /> ||create||see common file:create<br /> |-<br /> ||rename||see common file:rename<br /> |-<br /> ||mounton||see common file:mounton<br /> |-<br /> ||quotaon||see common file:quotaon<br /> |-<br /> ||relabelfrom||see common file:relabelfrom<br /> |-<br /> ||link||see common file:link<br /> |-<br /> ||execute_no_trans||Execute a file in the callers domain.||2.6.11+<br /> |-<br /> ||entrypoint||Can be executed as the entry point of the new domain in a transition.||2.6.11+<br /> |-<br /> ||execmod||Make executable a file mapping that has been modified by copy-on-write.||2.6.11+<br /> |-<br /> ||open||Open a character device file.||2.6.26+ / open_perms<br /> |}<br /> <br /> === dccp_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.20+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.20+<br /> |-<br /> ||create||see common socket:create||2.6.20+<br /> |-<br /> ||read||see common socket:read||2.6.20+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.20+<br /> |-<br /> ||connect||see common socket:connect||2.6.20+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.20+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.20+<br /> |-<br /> ||bind||see common socket:bind||2.6.20+<br /> |-<br /> ||lock||see common socket:lock||2.6.20+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.20+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.20+<br /> |-<br /> ||write||see common socket:write||2.6.20+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.20+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.20+<br /> |-<br /> ||listen||see common socket:listen||2.6.20+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.20+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.20+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.20+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.20+<br /> |-<br /> ||accept||see common socket:accept||2.6.20+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.20+<br /> |-<br /> ||connectto||Connect to server socket.||2.6.20+<br /> |-<br /> ||newconn||Create new socket for connection.||2.6.20+<br /> |-<br /> ||acceptfrom||Accept connection from client socket.||2.6.20+<br /> |-<br /> ||node_bind||Ability to bind to a node.||2.6.20+<br /> |-<br /> ||name_connect||Connect to a specific port number.||2.6.20+<br /> |}<br /> <br /> === dir ===<br /> Inherits from: [[#common file|common file]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||getattr||see common file:getattr<br /> |-<br /> ||relabelto||see common file:relabelto<br /> |-<br /> ||unlink||see common file:unlink<br /> |-<br /> ||ioctl||see common file:ioctl<br /> |-<br /> ||execute||see common file:execute<br /> |-<br /> ||append||see common file:append<br /> |-<br /> ||read||see common file:read<br /> |-<br /> ||setattr||see common file:setattr<br /> |-<br /> ||swapon||see common file:swapon<br /> |-<br /> ||write||see common file:write<br /> |-<br /> ||lock||see common file:lock<br /> |-<br /> ||create||see common file:create<br /> |-<br /> ||rename||see common file:rename<br /> |-<br /> ||mounton||see common file:mounton<br /> |-<br /> ||quotaon||see common file:quotaon<br /> |-<br /> ||relabelfrom||see common file:relabelfrom<br /> |-<br /> ||link||see common file:link<br /> |-<br /> ||search||Required on all ancestor directories of a file being accessed, similar to DAC +x permission<br /> |-<br /> ||rmdir||Remove the directory<br /> |-<br /> ||remove_name||Remove a file from the directory.<br /> |-<br /> ||reparent||Change parent directory.<br /> |-<br /> ||add_name||Add a file to the directory.<br /> |-<br /> ||open||Open a directory.||2.6.26+ / open_perms<br /> |}<br /> <br /> === fd ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||use||Permission to use an inherited file descriptor<br /> |}<br /> <br /> === fifo_file ===<br /> Inherits from: [[#common file|common file]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||getattr||see common file:getattr<br /> |-<br /> ||relabelto||see common file:relabelto<br /> |-<br /> ||unlink||see common file:unlink<br /> |-<br /> ||ioctl||see common file:ioctl<br /> |-<br /> ||execute||see common file:execute<br /> |-<br /> ||append||see common file:append<br /> |-<br /> ||read||see common file:read<br /> |-<br /> ||setattr||see common file:setattr<br /> |-<br /> ||swapon||see common file:swapon<br /> |-<br /> ||write||see common file:write<br /> |-<br /> ||lock||see common file:lock<br /> |-<br /> ||create||see common file:create<br /> |-<br /> ||rename||see common file:rename<br /> |-<br /> ||mounton||see common file:mounton<br /> |-<br /> ||quotaon||see common file:quotaon<br /> |-<br /> ||relabelfrom||see common file:relabelfrom<br /> |-<br /> ||link||see common file:link<br /> |-<br /> ||open||Open a FIFO.||2.6.26+ / open_perms<br /> |}<br /> <br /> === file ===<br /> Inherits from: [[#common file|common file]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||getattr||see common file:getattr<br /> |-<br /> ||relabelto||see common file:relabelto<br /> |-<br /> ||unlink||see common file:unlink<br /> |-<br /> ||ioctl||see common file:ioctl<br /> |-<br /> ||execute||see common file:execute<br /> |-<br /> ||append||see common file:append<br /> |-<br /> ||read||see common file:read<br /> |-<br /> ||setattr||see common file:setattr<br /> |-<br /> ||swapon||see common file:swapon<br /> |-<br /> ||write||see common file:write<br /> |-<br /> ||lock||see common file:lock<br /> |-<br /> ||create||see common file:create<br /> |-<br /> ||rename||see common file:rename<br /> |-<br /> ||mounton||see common file:mounton<br /> |-<br /> ||quotaon||see common file:quotaon<br /> |-<br /> ||relabelfrom||see common file:relabelfrom<br /> |-<br /> ||link||see common file:link<br /> |-<br /> ||execute_no_trans||Execute a file in the callers domain.<br /> |-<br /> ||entrypoint||Can be executed as the entry point of the new domain in a transition.<br /> |-<br /> ||execmod||Make executable a file mapping that has been modified by copy-on-write.||2.6.11+<br /> |-<br /> ||open||Open a file.||2.6.26+ / open_perms<br /> |}<br /> <br /> === filesystem ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||mount||Mount the filesystem.<br /> |-<br /> ||remount||Change filesystem mount flags.<br /> |-<br /> ||unmount||Unmount the filesystem.<br /> |-<br /> ||getattr||Get file attributes, such as access mode. (e.g. stat, some ioctls. ...)<br /> |-<br /> ||relabelfrom||Change the security context based on existing type.<br /> |-<br /> ||relabelto||Change the security context based on the new type.<br /> |-<br /> ||transition||Transition to a new SID (change security context).<br /> |-<br /> ||associate||Associate a file to the filesystem.<br /> |-<br /> ||quotamod||Modify quota information.<br /> |-<br /> ||quotaget||Get quota information<br /> |}<br /> <br /> === ipc ===<br /> Inherits from: [[#common ipc|common ipc]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||write||see common ipc:write<br /> |-<br /> ||destroy||see common ipc:destroy<br /> |-<br /> ||unix_write||see common ipc:unix_write<br /> |-<br /> ||getattr||see common ipc:getattr<br /> |-<br /> ||create||see common ipc:create<br /> |-<br /> ||read||see common ipc:read<br /> |-<br /> ||setattr||see common ipc:setattr<br /> |-<br /> ||unix_read||see common ipc:unix_read<br /> |-<br /> ||associate||see common ipc:associate<br /> |}<br /> <br /> === kernel_service ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||use_as_override||Grant a process the right to nominate an alternate process security ID for the kernel to use as an override for the SELinux subjective security when accessing stuff on behalf of another process.||2.6.29+<br /> |-<br /> ||create_files_as||Grant a process the right to nominate a file creation label for a kernel service to use.||2.6.29+<br /> |}<br /> <br /> === key ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||view||||2.6.18+<br /> |-<br /> ||read||||2.6.18+<br /> |-<br /> ||write||||2.6.18+<br /> |-<br /> ||search||||2.6.18+<br /> |-<br /> ||link||||2.6.18+<br /> |-<br /> ||setattr||||2.6.18+<br /> |-<br /> ||create||||2.6.18+<br /> |}<br /> <br /> === key_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom<br /> |-<br /> ||create||see common socket:create<br /> |-<br /> ||read||see common socket:read<br /> |-<br /> ||sendto||see common socket:sendto<br /> |-<br /> ||connect||see common socket:connect<br /> |-<br /> ||recvfrom||see common socket:recvfrom<br /> |-<br /> ||send_msg||see common socket:send_msg<br /> |-<br /> ||bind||see common socket:bind<br /> |-<br /> ||lock||see common socket:lock<br /> |-<br /> ||ioctl||see common socket:ioctl<br /> |-<br /> ||getattr||see common socket:getattr<br /> |-<br /> ||write||see common socket:write<br /> |-<br /> ||setopt||see common socket:setopt<br /> |-<br /> ||getopt||see common socket:getopt<br /> |-<br /> ||listen||see common socket:listen<br /> |-<br /> ||setattr||see common socket:setattr<br /> |-<br /> ||shutdown||see common socket:shutdown<br /> |-<br /> ||relabelto||see common socket:relabelto<br /> |-<br /> ||recv_msg||see common socket:recv_msg<br /> |-<br /> ||accept||see common socket:accept<br /> |-<br /> ||name_bind||see common socket:name_bind<br /> |}<br /> <br /> === lnk_file ===<br /> Inherits from: [[#common file|common file]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||getattr||see common file:getattr<br /> |-<br /> ||relabelto||see common file:relabelto<br /> |-<br /> ||unlink||see common file:unlink<br /> |-<br /> ||ioctl||see common file:ioctl<br /> |-<br /> ||execute||see common file:execute<br /> |-<br /> ||append||see common file:append<br /> |-<br /> ||read||see common file:read<br /> |-<br /> ||setattr||see common file:setattr<br /> |-<br /> ||swapon||see common file:swapon<br /> |-<br /> ||write||see common file:write<br /> |-<br /> ||lock||see common file:lock<br /> |-<br /> ||create||see common file:create<br /> |-<br /> ||rename||see common file:rename<br /> |-<br /> ||mounton||see common file:mounton<br /> |-<br /> ||quotaon||see common file:quotaon<br /> |-<br /> ||relabelfrom||see common file:relabelfrom<br /> |-<br /> ||link||see common file:link<br /> |}<br /> <br /> === memprotect ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||mmap_zero||Mmap the first page of memory.||2.6.23+<br /> |}<br /> <br /> === msg ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||receive||Remove a message from a queue.<br /> |-<br /> ||send||Add a message to a queue.<br /> |}<br /> <br /> === msgq ===<br /> Inherits from: [[#common ipc|common ipc]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||write||see common ipc:write<br /> |-<br /> ||destroy||see common ipc:destroy<br /> |-<br /> ||unix_write||see common ipc:unix_write<br /> |-<br /> ||getattr||see common ipc:getattr<br /> |-<br /> ||create||see common ipc:create<br /> |-<br /> ||read||see common ipc:read<br /> |-<br /> ||setattr||see common ipc:setattr<br /> |-<br /> ||unix_read||see common ipc:unix_read<br /> |-<br /> ||associate||see common ipc:associate<br /> |-<br /> ||enqueue||Message can be added to a queue.<br /> |}<br /> <br /> === netif ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||tcp_recv||Receive TCP packet.<br /> |-<br /> ||tcp_send||Send TCP packet.<br /> |-<br /> ||udp_recv||Receive UDP packet.<br /> |-<br /> ||udp_send||Send UDP packet.<br /> |-<br /> ||rawip_recv||Receive raw IP packet.<br /> |-<br /> ||rawip_send||Send raw IP packet.<br /> |-<br /> ||dccp_recv||Receive DCCP packet.||2.6.20+<br /> |-<br /> ||dccp_send||Send DCCP packet.||2.6.20+<br /> |-<br /> ||ingress||||2.6.25+ / network_peer_controls<br /> |-<br /> ||egress||||2.6.25+ / network_peer_controls<br /> |}<br /> <br /> === netlink_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom<br /> |-<br /> ||create||see common socket:create<br /> |-<br /> ||read||see common socket:read<br /> |-<br /> ||sendto||see common socket:sendto<br /> |-<br /> ||connect||see common socket:connect<br /> |-<br /> ||recvfrom||see common socket:recvfrom<br /> |-<br /> ||send_msg||see common socket:send_msg<br /> |-<br /> ||bind||see common socket:bind<br /> |-<br /> ||lock||see common socket:lock<br /> |-<br /> ||ioctl||see common socket:ioctl<br /> |-<br /> ||getattr||see common socket:getattr<br /> |-<br /> ||write||see common socket:write<br /> |-<br /> ||setopt||see common socket:setopt<br /> |-<br /> ||getopt||see common socket:getopt<br /> |-<br /> ||listen||see common socket:listen<br /> |-<br /> ||setattr||see common socket:setattr<br /> |-<br /> ||shutdown||see common socket:shutdown<br /> |-<br /> ||relabelto||see common socket:relabelto<br /> |-<br /> ||recv_msg||see common socket:recv_msg<br /> |-<br /> ||accept||see common socket:accept<br /> |-<br /> ||name_bind||see common socket:name_bind<br /> |}<br /> <br /> === netlink_audit_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.8+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.8+<br /> |-<br /> ||create||see common socket:create||2.6.8+<br /> |-<br /> ||read||see common socket:read||2.6.8+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.8+<br /> |-<br /> ||connect||see common socket:connect||2.6.8+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.8+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.8+<br /> |-<br /> ||bind||see common socket:bind||2.6.8+<br /> |-<br /> ||lock||see common socket:lock||2.6.8+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.8+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.8+<br /> |-<br /> ||write||see common socket:write||2.6.8+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.8+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.8+<br /> |-<br /> ||listen||see common socket:listen||2.6.8+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.8+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.8+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.8+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.8+<br /> |-<br /> ||accept||see common socket:accept||2.6.8+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.8+<br /> |-<br /> ||nlmsg_read||Read netlink message.||2.6.8+<br /> |-<br /> ||nlmsg_write||Write netlink message.||2.6.8+<br /> |-<br /> ||nlmsg_relay||Send user space audit messages to the kernel audit system.||2.6.12+<br /> |-<br /> ||nlmsg_readpriv||List all auditing rules.||2.6.12+<br /> |-<br /> ||nlmsg_tty_audit||Control TTY auditing||2.6.30+<br /> |}<br /> <br /> === netlink_dnrt_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.8+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.8+<br /> |-<br /> ||create||see common socket:create||2.6.8+<br /> |-<br /> ||read||see common socket:read||2.6.8+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.8+<br /> |-<br /> ||connect||see common socket:connect||2.6.8+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.8+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.8+<br /> |-<br /> ||bind||see common socket:bind||2.6.8+<br /> |-<br /> ||lock||see common socket:lock||2.6.8+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.8+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.8+<br /> |-<br /> ||write||see common socket:write||2.6.8+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.8+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.8+<br /> |-<br /> ||listen||see common socket:listen||2.6.8+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.8+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.8+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.8+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.8+<br /> |-<br /> ||accept||see common socket:accept||2.6.8+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.8+<br /> |}<br /> <br /> === netlink_firewall_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.8+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.8+<br /> |-<br /> ||create||see common socket:create||2.6.8+<br /> |-<br /> ||read||see common socket:read||2.6.8+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.8+<br /> |-<br /> ||connect||see common socket:connect||2.6.8+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.8+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.8+<br /> |-<br /> ||bind||see common socket:bind||2.6.8+<br /> |-<br /> ||lock||see common socket:lock||2.6.8+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.8+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.8+<br /> |-<br /> ||write||see common socket:write||2.6.8+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.8+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.8+<br /> |-<br /> ||listen||see common socket:listen||2.6.8+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.8+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.8+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.8+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.8+<br /> |-<br /> ||accept||see common socket:accept||2.6.8+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.8+<br /> |-<br /> ||nlmsg_read||Read netlink message.||2.6.8+<br /> |-<br /> ||nlmsg_write||Write netlink message.||2.6.8+<br /> |}<br /> <br /> === netlink_ip6fw_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.8+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.8+<br /> |-<br /> ||create||see common socket:create||2.6.8+<br /> |-<br /> ||read||see common socket:read||2.6.8+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.8+<br /> |-<br /> ||connect||see common socket:connect||2.6.8+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.8+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.8+<br /> |-<br /> ||bind||see common socket:bind||2.6.8+<br /> |-<br /> ||lock||see common socket:lock||2.6.8+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.8+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.8+<br /> |-<br /> ||write||see common socket:write||2.6.8+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.8+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.8+<br /> |-<br /> ||listen||see common socket:listen||2.6.8+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.8+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.8+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.8+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.8+<br /> |-<br /> ||accept||see common socket:accept||2.6.8+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.8+<br /> |-<br /> ||nlmsg_read||Read netlink message.||2.6.8+<br /> |-<br /> ||nlmsg_write||Write netlink message.||2.6.8+<br /> |}<br /> <br /> === netlink_kobject_uevent_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.12+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.12+<br /> |-<br /> ||create||see common socket:create||2.6.12+<br /> |-<br /> ||read||see common socket:read||2.6.12+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.12+<br /> |-<br /> ||connect||see common socket:connect||2.6.12+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.12+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.12+<br /> |-<br /> ||bind||see common socket:bind||2.6.12+<br /> |-<br /> ||lock||see common socket:lock||2.6.12+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.12+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.12+<br /> |-<br /> ||write||see common socket:write||2.6.12+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.12+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.12+<br /> |-<br /> ||listen||see common socket:listen||2.6.12+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.12+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.12+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.12+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.12+<br /> |-<br /> ||accept||see common socket:accept||2.6.12+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.12+<br /> |}<br /> <br /> === netlink_nflog_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.8+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.8+<br /> |-<br /> ||create||see common socket:create||2.6.8+<br /> |-<br /> ||read||see common socket:read||2.6.8+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.8+<br /> |-<br /> ||connect||see common socket:connect||2.6.8+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.8+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.8+<br /> |-<br /> ||bind||see common socket:bind||2.6.8+<br /> |-<br /> ||lock||see common socket:lock||2.6.8+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.8+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.8+<br /> |-<br /> ||write||see common socket:write||2.6.8+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.8+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.8+<br /> |-<br /> ||listen||see common socket:listen||2.6.8+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.8+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.8+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.8+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.8+<br /> |-<br /> ||accept||see common socket:accept||2.6.8+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.8+<br /> |}<br /> <br /> === netlink_route_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.8+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.8+<br /> |-<br /> ||create||see common socket:create||2.6.8+<br /> |-<br /> ||read||see common socket:read||2.6.8+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.8+<br /> |-<br /> ||connect||see common socket:connect||2.6.8+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.8+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.8+<br /> |-<br /> ||bind||see common socket:bind||2.6.8+<br /> |-<br /> ||lock||see common socket:lock||2.6.8+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.8+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.8+<br /> |-<br /> ||write||see common socket:write||2.6.8+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.8+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.8+<br /> |-<br /> ||listen||see common socket:listen||2.6.8+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.8+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.8+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.8+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.8+<br /> |-<br /> ||accept||see common socket:accept||2.6.8+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.8+<br /> |-<br /> ||nlmsg_read||Read netlink message.||2.6.8+<br /> |-<br /> ||nlmsg_write||Write netlink message.||2.6.8+<br /> |}<br /> <br /> === netlink_selinux_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.8+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.8+<br /> |-<br /> ||create||see common socket:create||2.6.8+<br /> |-<br /> ||read||see common socket:read||2.6.8+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.8+<br /> |-<br /> ||connect||see common socket:connect||2.6.8+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.8+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.8+<br /> |-<br /> ||bind||see common socket:bind||2.6.8+<br /> |-<br /> ||lock||see common socket:lock||2.6.8+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.8+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.8+<br /> |-<br /> ||write||see common socket:write||2.6.8+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.8+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.8+<br /> |-<br /> ||listen||see common socket:listen||2.6.8+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.8+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.8+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.8+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.8+<br /> |-<br /> ||accept||see common socket:accept||2.6.8+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.8+<br /> |}<br /> <br /> === netlink_tcpdiag_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.8+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.8+<br /> |-<br /> ||create||see common socket:create||2.6.8+<br /> |-<br /> ||read||see common socket:read||2.6.8+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.8+<br /> |-<br /> ||connect||see common socket:connect||2.6.8+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.8+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.8+<br /> |-<br /> ||bind||see common socket:bind||2.6.8+<br /> |-<br /> ||lock||see common socket:lock||2.6.8+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.8+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.8+<br /> |-<br /> ||write||see common socket:write||2.6.8+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.8+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.8+<br /> |-<br /> ||listen||see common socket:listen||2.6.8+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.8+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.8+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.8+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.8+<br /> |-<br /> ||accept||see common socket:accept||2.6.8+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.8+<br /> |-<br /> ||nlmsg_read||Read netlink message.||2.6.8+<br /> |-<br /> ||nlmsg_write||Write netlink message.||2.6.8+<br /> |}<br /> <br /> === netlink_xfrm_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.8+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.8+<br /> |-<br /> ||create||see common socket:create||2.6.8+<br /> |-<br /> ||read||see common socket:read||2.6.8+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.8+<br /> |-<br /> ||connect||see common socket:connect||2.6.8+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.8+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.8+<br /> |-<br /> ||bind||see common socket:bind||2.6.8+<br /> |-<br /> ||lock||see common socket:lock||2.6.8+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.8+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.8+<br /> |-<br /> ||write||see common socket:write||2.6.8+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.8+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.8+<br /> |-<br /> ||listen||see common socket:listen||2.6.8+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.8+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.8+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.8+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.8+<br /> |-<br /> ||accept||see common socket:accept||2.6.8+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.8+<br /> |-<br /> ||nlmsg_read||Read netlink message.||2.6.8+<br /> |-<br /> ||nlmsg_write||Write netlink message.||2.6.8+<br /> |}<br /> <br /> === node ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||tcp_recv||Receive TCP packet.<br /> |-<br /> ||tcp_send||Send TCP packet.<br /> |-<br /> ||udp_recv||Receive UDP packet.<br /> |-<br /> ||udp_send||Send UDP packet.<br /> |-<br /> ||rawip_recv||Receive raw IP packet.<br /> |-<br /> ||rawip_send||Send raw IP packet.<br /> |-<br /> ||enforce_dest||Ensure that the destination node can enforce restrictions on the destination socket.<br /> |-<br /> ||dccp_recv||Receive DCCP packet.||2.6.20+<br /> |-<br /> ||dccp_send||Send DCCP packet.||2.6.20+<br /> |-<br /> ||recvfrom||||2.6.25+ / network_peer_controls<br /> |-<br /> ||sendto||||2.6.25+ / network_peer_controls<br /> |}<br /> <br /> === packet ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||send||Send a packet.||2.6.18+<br /> |-<br /> ||receive||Receive a packet.||2.6.18+<br /> |-<br /> ||relabelto||Set a labeling rule to the specified type.||2.6.18+<br /> |-<br /> ||flow_in||''Deprecated''||2.6.25+<br /> |-<br /> ||flow_out||''Deprecated''||2.6.25+<br /> |-<br /> ||forward_in||||2.6.25+<br /> |-<br /> ||forward_out||||2.6.25+<br /> |}<br /> <br /> === packet_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom<br /> |-<br /> ||create||see common socket:create<br /> |-<br /> ||read||see common socket:read<br /> |-<br /> ||sendto||see common socket:sendto<br /> |-<br /> ||connect||see common socket:connect<br /> |-<br /> ||recvfrom||see common socket:recvfrom<br /> |-<br /> ||send_msg||see common socket:send_msg<br /> |-<br /> ||bind||see common socket:bind<br /> |-<br /> ||lock||see common socket:lock<br /> |-<br /> ||ioctl||see common socket:ioctl<br /> |-<br /> ||getattr||see common socket:getattr<br /> |-<br /> ||write||see common socket:write<br /> |-<br /> ||setopt||see common socket:setopt<br /> |-<br /> ||getopt||see common socket:getopt<br /> |-<br /> ||listen||see common socket:listen<br /> |-<br /> ||setattr||see common socket:setattr<br /> |-<br /> ||shutdown||see common socket:shutdown<br /> |-<br /> ||relabelto||see common socket:relabelto<br /> |-<br /> ||recv_msg||see common socket:recv_msg<br /> |-<br /> ||accept||see common socket:accept<br /> |-<br /> ||name_bind||see common socket:name_bind<br /> |}<br /> <br /> === peer ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||recv||Receive from a labeled networking peer.||2.6.25+ / network_peer_controls<br /> |}<br /> <br /> === process ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||fork||Fork into two processes.<br /> |-<br /> ||transition||Transition to a new context on exec().<br /> |-<br /> ||sigchld||Send SIGCHLD signal.<br /> |-<br /> ||sigkill||Send SIGKILL signal.<br /> |-<br /> ||sigstop||Send SIGSTOP signal<br /> |-<br /> ||signull||Test for exisitence of another process without sending a signal<br /> |-<br /> ||signal||Send a signal other than SIGKILL, SIGSTOP, or SIGCHLD.<br /> |-<br /> ||ptrace||Trace program execution of parent or child.<br /> |-<br /> ||getsched||Get priority of a process.<br /> |-<br /> ||setsched||Set priority of a process.<br /> |-<br /> ||getsession||Get session ID of another process.<br /> |-<br /> ||getpgid||Get group Process ID of a process.<br /> |-<br /> ||setpgid||Set group Process ID of a process.<br /> |-<br /> ||getcap||Get Linux capabilities.<br /> |-<br /> ||setcap||Set Linux capabilities.<br /> |-<br /> ||share||Allow state sharing with cloned or forked process.<br /> |-<br /> ||getattr||Get attributes of a file.<br /> |-<br /> ||setexec||Override the default context for the next exec().<br /> |-<br /> ||setfscreate||Override the default context for file creation.<br /> |-<br /> ||setrlimit||Change process hard limits.<br /> |-<br /> ||noatsecure||Disable secure mode environment cleansing (AT_SECURE).||v.16+<br /> |-<br /> ||siginh||Inherit signal state from old sid.||v.16+<br /> |-<br /> ||rlimitinh||Inherit resource limits from old sid.||v.16+<br /> |-<br /> ||dyntransition||Dynamically transition to a new context.||2.6.11+<br /> |-<br /> ||setcurrent||Set the current process context.||2.6.11+<br /> |-<br /> ||execmem||Make executable an anonymous mapping or private file mapping that is writable.||2.6.13+<br /> |-<br /> ||execstack||Make the main process stack executable.||2.6.13+<br /> |-<br /> ||execheap||Make the heap executable.||2.6.13+<br /> |-<br /> ||setkeycreate||Override the default context for key creation.||2.6.18+<br /> |-<br /> ||setsockcreate||Override the default context for socket creation.||2.6.18+<br /> |}<br /> <br /> === rawip_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom<br /> |-<br /> ||create||see common socket:create<br /> |-<br /> ||read||see common socket:read<br /> |-<br /> ||sendto||see common socket:sendto<br /> |-<br /> ||connect||see common socket:connect<br /> |-<br /> ||recvfrom||see common socket:recvfrom<br /> |-<br /> ||send_msg||see common socket:send_msg<br /> |-<br /> ||bind||see common socket:bind<br /> |-<br /> ||lock||see common socket:lock<br /> |-<br /> ||ioctl||see common socket:ioctl<br /> |-<br /> ||getattr||see common socket:getattr<br /> |-<br /> ||write||see common socket:write<br /> |-<br /> ||setopt||see common socket:setopt<br /> |-<br /> ||getopt||see common socket:getopt<br /> |-<br /> ||listen||see common socket:listen<br /> |-<br /> ||setattr||see common socket:setattr<br /> |-<br /> ||shutdown||see common socket:shutdown<br /> |-<br /> ||relabelto||see common socket:relabelto<br /> |-<br /> ||recv_msg||see common socket:recv_msg<br /> |-<br /> ||accept||see common socket:accept<br /> |-<br /> ||name_bind||see common socket:name_bind<br /> |-<br /> ||node_bind||Ability to bind to a node.||v.17+<br /> |}<br /> <br /> === security ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||compute_user||Get user info in selinuxfs.<br /> |-<br /> ||compute_relabel||Get relabel info in selinuxfs.<br /> |-<br /> ||compute_create||Get create info in selinuxfs.<br /> |-<br /> ||compute_av||Compute an access vector given a source/target/class.<br /> |-<br /> ||compute_member||Determines the context to use when selecting a member of a polyinstantiated object.<br /> |-<br /> ||setenforce||Change the enforcement state of SELinux.<br /> |-<br /> ||check_context||Write context in selinuxfs.<br /> |-<br /> ||load_policy||Load the security policy.<br /> |-<br /> ||setbool||Set a boolean value.||2.6.5+<br /> |-<br /> ||setsecparam||Set kernel access vector cache tuning parameters.||2.6.11+<br /> |-<br /> ||setcheckreqprot||Set if SELinux will check original protection mode or modified protection mode (read-implies-exec) for mmap/mprotect.||2.6.12+<br /> |}<br /> <br /> === sem ===<br /> Inherits from: [[#common ipc|common ipc]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||write||see common ipc:write<br /> |-<br /> ||destroy||see common ipc:destroy<br /> |-<br /> ||unix_write||see common ipc:unix_write<br /> |-<br /> ||getattr||see common ipc:getattr<br /> |-<br /> ||create||see common ipc:create<br /> |-<br /> ||read||see common ipc:read<br /> |-<br /> ||setattr||see common ipc:setattr<br /> |-<br /> ||unix_read||see common ipc:unix_read<br /> |-<br /> ||associate||see common ipc:associate<br /> |}<br /> <br /> === shm ===<br /> Inherits from: [[#common ipc|common ipc]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||write||see common ipc:write<br /> |-<br /> ||destroy||see common ipc:destroy<br /> |-<br /> ||unix_write||see common ipc:unix_write<br /> |-<br /> ||getattr||see common ipc:getattr<br /> |-<br /> ||create||see common ipc:create<br /> |-<br /> ||read||see common ipc:read<br /> |-<br /> ||setattr||see common ipc:setattr<br /> |-<br /> ||unix_read||see common ipc:unix_read<br /> |-<br /> ||associate||see common ipc:associate<br /> |-<br /> ||lock||(Un)lock page(s) in memory.<br /> |}<br /> <br /> === sock_file ===<br /> Inherits from: [[#common file|common file]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||getattr||see common file:getattr<br /> |-<br /> ||relabelto||see common file:relabelto<br /> |-<br /> ||unlink||see common file:unlink<br /> |-<br /> ||ioctl||see common file:ioctl<br /> |-<br /> ||execute||see common file:execute<br /> |-<br /> ||append||see common file:append<br /> |-<br /> ||read||see common file:read<br /> |-<br /> ||setattr||see common file:setattr<br /> |-<br /> ||swapon||see common file:swapon<br /> |-<br /> ||write||see common file:write<br /> |-<br /> ||lock||see common file:lock<br /> |-<br /> ||create||see common file:create<br /> |-<br /> ||rename||see common file:rename<br /> |-<br /> ||mounton||see common file:mounton<br /> |-<br /> ||quotaon||see common file:quotaon<br /> |-<br /> ||relabelfrom||see common file:relabelfrom<br /> |-<br /> ||link||see common file:link<br /> |-<br /> ||open||Open a named socket file.||2.6.26+ / open_perms<br /> |}<br /> <br /> === socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom<br /> |-<br /> ||create||see common socket:create<br /> |-<br /> ||read||see common socket:read<br /> |-<br /> ||sendto||see common socket:sendto<br /> |-<br /> ||connect||see common socket:connect<br /> |-<br /> ||recvfrom||see common socket:recvfrom<br /> |-<br /> ||send_msg||see common socket:send_msg<br /> |-<br /> ||bind||see common socket:bind<br /> |-<br /> ||lock||see common socket:lock<br /> |-<br /> ||ioctl||see common socket:ioctl<br /> |-<br /> ||getattr||see common socket:getattr<br /> |-<br /> ||write||see common socket:write<br /> |-<br /> ||setopt||see common socket:setopt<br /> |-<br /> ||getopt||see common socket:getopt<br /> |-<br /> ||listen||see common socket:listen<br /> |-<br /> ||setattr||see common socket:setattr<br /> |-<br /> ||shutdown||see common socket:shutdown<br /> |-<br /> ||relabelto||see common socket:relabelto<br /> |-<br /> ||recv_msg||see common socket:recv_msg<br /> |-<br /> ||accept||see common socket:accept<br /> |-<br /> ||name_bind||see common socket:name_bind<br /> |}<br /> <br /> === system ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||ipc_info||Get info for an ipc socket.<br /> |-<br /> ||syslog_mod||Perform syslog operation other than syslog_read or console logging.<br /> |-<br /> ||syslog_read||Perform syslog read.<br /> |-<br /> ||syslog_console||Perform syslog console.<br /> |}<br /> <br /> === tcp_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom<br /> |-<br /> ||create||see common socket:create<br /> |-<br /> ||read||see common socket:read<br /> |-<br /> ||sendto||see common socket:sendto<br /> |-<br /> ||connect||see common socket:connect<br /> |-<br /> ||recvfrom||see common socket:recvfrom<br /> |-<br /> ||send_msg||see common socket:send_msg<br /> |-<br /> ||bind||see common socket:bind<br /> |-<br /> ||lock||see common socket:lock<br /> |-<br /> ||ioctl||see common socket:ioctl<br /> |-<br /> ||getattr||see common socket:getattr<br /> |-<br /> ||write||see common socket:write<br /> |-<br /> ||setopt||see common socket:setopt<br /> |-<br /> ||getopt||see common socket:getopt<br /> |-<br /> ||listen||see common socket:listen<br /> |-<br /> ||setattr||see common socket:setattr<br /> |-<br /> ||shutdown||see common socket:shutdown<br /> |-<br /> ||relabelto||see common socket:relabelto<br /> |-<br /> ||recv_msg||see common socket:recv_msg<br /> |-<br /> ||accept||see common socket:accept<br /> |-<br /> ||name_bind||see common socket:name_bind<br /> |-<br /> ||connectto||Connect to server socket.<br /> |-<br /> ||newconn||Create new socket for connection.<br /> |-<br /> ||acceptfrom||Accept connection from client socket.<br /> |-<br /> ||node_bind||Ability to bind to a node.||2.6.2+<br /> |-<br /> ||name_connect||Connect to a specific port number.||2.6.12+<br /> |}<br /> <br /> === tun_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append||2.6.32+<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom||2.6.32+<br /> |-<br /> ||create||see common socket:create||2.6.32+<br /> |-<br /> ||read||see common socket:read||2.6.32+<br /> |-<br /> ||sendto||see common socket:sendto||2.6.32+<br /> |-<br /> ||connect||see common socket:connect||2.6.32+<br /> |-<br /> ||recvfrom||see common socket:recvfrom||2.6.32+<br /> |-<br /> ||send_msg||see common socket:send_msg||2.6.32+<br /> |-<br /> ||bind||see common socket:bind||2.6.32+<br /> |-<br /> ||lock||see common socket:lock||2.6.32+<br /> |-<br /> ||ioctl||see common socket:ioctl||2.6.32+<br /> |-<br /> ||getattr||see common socket:getattr||2.6.32+<br /> |-<br /> ||write||see common socket:write||2.6.32+<br /> |-<br /> ||setopt||see common socket:setopt||2.6.32+<br /> |-<br /> ||getopt||see common socket:getopt||2.6.32+<br /> |-<br /> ||listen||see common socket:listen||2.6.32+<br /> |-<br /> ||setattr||see common socket:setattr||2.6.32+<br /> |-<br /> ||shutdown||see common socket:shutdown||2.6.32+<br /> |-<br /> ||relabelto||see common socket:relabelto||2.6.32+<br /> |-<br /> ||recv_msg||see common socket:recv_msg||2.6.32+<br /> |-<br /> ||accept||see common socket:accept||2.6.32+<br /> |-<br /> ||name_bind||see common socket:name_bind||2.6.32+<br /> |}<br /> <br /> === udp_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom<br /> |-<br /> ||create||see common socket:create<br /> |-<br /> ||read||see common socket:read<br /> |-<br /> ||sendto||see common socket:sendto<br /> |-<br /> ||connect||see common socket:connect<br /> |-<br /> ||recvfrom||see common socket:recvfrom<br /> |-<br /> ||send_msg||see common socket:send_msg<br /> |-<br /> ||bind||see common socket:bind<br /> |-<br /> ||lock||see common socket:lock<br /> |-<br /> ||ioctl||see common socket:ioctl<br /> |-<br /> ||getattr||see common socket:getattr<br /> |-<br /> ||write||see common socket:write<br /> |-<br /> ||setopt||see common socket:setopt<br /> |-<br /> ||getopt||see common socket:getopt<br /> |-<br /> ||listen||see common socket:listen<br /> |-<br /> ||setattr||see common socket:setattr<br /> |-<br /> ||shutdown||see common socket:shutdown<br /> |-<br /> ||relabelto||see common socket:relabelto<br /> |-<br /> ||recv_msg||see common socket:recv_msg<br /> |-<br /> ||accept||see common socket:accept<br /> |-<br /> ||name_bind||see common socket:name_bind<br /> |-<br /> ||node_bind||Ability to bind to a node.||2.6.2+<br /> |}<br /> <br /> === unix_dgram_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom<br /> |-<br /> ||create||see common socket:create<br /> |-<br /> ||read||see common socket:read<br /> |-<br /> ||sendto||see common socket:sendto<br /> |-<br /> ||connect||see common socket:connect<br /> |-<br /> ||recvfrom||see common socket:recvfrom<br /> |-<br /> ||send_msg||see common socket:send_msg<br /> |-<br /> ||bind||see common socket:bind<br /> |-<br /> ||lock||see common socket:lock<br /> |-<br /> ||ioctl||see common socket:ioctl<br /> |-<br /> ||getattr||see common socket:getattr<br /> |-<br /> ||write||see common socket:write<br /> |-<br /> ||setopt||see common socket:setopt<br /> |-<br /> ||getopt||see common socket:getopt<br /> |-<br /> ||listen||see common socket:listen<br /> |-<br /> ||setattr||see common socket:setattr<br /> |-<br /> ||shutdown||see common socket:shutdown<br /> |-<br /> ||relabelto||see common socket:relabelto<br /> |-<br /> ||recv_msg||see common socket:recv_msg<br /> |-<br /> ||accept||see common socket:accept<br /> |-<br /> ||name_bind||see common socket:name_bind<br /> |}<br /> <br /> === unix_stream_socket ===<br /> Inherits from: [[#common socket|common socket]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> ! Kernel Version/Capability<br /> |-<br /> ||append||see common socket:append<br /> |-<br /> ||relabelfrom||see common socket:relabelfrom<br /> |-<br /> ||create||see common socket:create<br /> |-<br /> ||read||see common socket:read<br /> |-<br /> ||sendto||see common socket:sendto<br /> |-<br /> ||connect||see common socket:connect<br /> |-<br /> ||recvfrom||see common socket:recvfrom<br /> |-<br /> ||send_msg||see common socket:send_msg<br /> |-<br /> ||bind||see common socket:bind<br /> |-<br /> ||lock||see common socket:lock<br /> |-<br /> ||ioctl||see common socket:ioctl<br /> |-<br /> ||getattr||see common socket:getattr<br /> |-<br /> ||write||see common socket:write<br /> |-<br /> ||setopt||see common socket:setopt<br /> |-<br /> ||getopt||see common socket:getopt<br /> |-<br /> ||listen||see common socket:listen<br /> |-<br /> ||setattr||see common socket:setattr<br /> |-<br /> ||shutdown||see common socket:shutdown<br /> |-<br /> ||relabelto||see common socket:relabelto<br /> |-<br /> ||recv_msg||see common socket:recv_msg<br /> |-<br /> ||accept||see common socket:accept<br /> |-<br /> ||name_bind||see common socket:name_bind<br /> |-<br /> ||connectto||Connect to server socket.<br /> |-<br /> ||newconn||Create new socket for connection.<br /> |-<br /> ||acceptfrom||Accept connection from client socket.<br /> |}<br /> <br /> == Database Object Classes ==<br /> === db_blob ===<br /> Inherits from: [[#common database|common database]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||read||Read a blob.<br /> |-<br /> ||write||Write a blob.<br /> |-<br /> ||import||Import a blob.<br /> |-<br /> ||export||Export a blob.<br /> |}<br /> <br /> === db_column ===<br /> Inherits from: [[#common database|common database]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||use||''Deprecated''<br /> |-<br /> ||select<br /> |-<br /> ||update<br /> |-<br /> ||insert<br /> |}<br /> <br /> === db_database ===<br /> Inherits from: [[#common database|common database]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||access<br /> |-<br /> ||install_module<br /> |-<br /> ||load_module<br /> |-<br /> ||get_param||''Deprecated''<br /> |-<br /> ||set_param||''Deprecated''<br /> |}<br /> <br /> === db_procedure ===<br /> Inherits from: [[#common database|common database]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||execute||Execute a stored procedure.<br /> |-<br /> ||entrypoint<br /> |-<br /> ||install<br /> |}<br /> <br /> === db_table ===<br /> Inherits from: [[#common database|common database]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||use||''Deprecated''<br /> |-<br /> ||select<br /> |-<br /> ||update<br /> |-<br /> ||insert<br /> |-<br /> ||delete<br /> |-<br /> ||lock<br /> |}<br /> <br /> === db_tuple ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||relabelfrom<br /> |-<br /> ||relabelto<br /> |-<br /> ||use||''Deprecated''<br /> |-<br /> ||select<br /> |-<br /> ||update<br /> |-<br /> ||insert<br /> |-<br /> ||delete<br /> |}<br /> <br /> == DBus Object Classes ==<br /> === dbus ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||acquire_svc<br /> |-<br /> ||send_msg||Send a message on the bus.<br /> |}<br /> <br /> == MLS Context Translation Object Classes ==<br /> === context ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||translate||Translate a raw MLS label.<br /> |-<br /> ||contains||Calculate a MLS subset.<br /> |}<br /> <br /> == NSCD Object Classes ==<br /> === nscd ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||getpwd<br /> |-<br /> ||getgrp<br /> |-<br /> ||gethost<br /> |-<br /> ||getstat<br /> |-<br /> ||admin<br /> |-<br /> ||shmempwd<br /> |-<br /> ||shmemgrp<br /> |-<br /> ||shmemhost<br /> |-<br /> ||getserv<br /> |-<br /> ||shmemserv<br /> |}<br /> <br /> == Password Object Classes ==<br /> === passwd ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||passwd||Update user password.<br /> |-<br /> ||chfn||Change finger information. e.g real name, work room and phone and home phone.<br /> |-<br /> ||chsh||Change login shell.<br /> |-<br /> ||rootok||Allow update if the user is root and the process has the rootok PAM permission.<br /> |-<br /> ||crontab||crontab on another user.<br /> |}<br /> <br /> == X Server Object Classes ==<br /> === x_application_data ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||paste<br /> |-<br /> ||paste_after_confirm<br /> |-<br /> ||copy<br /> |}<br /> <br /> === x_client ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||destroy||Close down a client.<br /> |-<br /> ||getattr||Get the attributes of an X client<br /> |-<br /> ||setattr||Set the attributes of an X client<br /> |-<br /> ||manage<br /> |}<br /> <br /> === x_colormap ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||create||Create a new Colormap.<br /> |-<br /> ||destroy||Free a Colormap.<br /> |-<br /> ||read||Read color cells of colormap.<br /> |-<br /> ||write<br /> |-<br /> ||getattr||Get the color gamut of a screen.<br /> |-<br /> ||add_color<br /> |-<br /> ||remove_color<br /> |-<br /> ||install||Copy a virtual colormap into the display hardware.<br /> |-<br /> ||uninstall||Remove a virtual colormap from the display hardware.<br /> |-<br /> ||use<br /> |}<br /> <br /> === x_cursor ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||create||Create an arbitrary cursor object.<br /> |-<br /> ||destroy||Delete a cursor object.<br /> |-<br /> ||read<br /> |-<br /> ||write<br /> |-<br /> ||getattr||Get attributes of the cursor.<br /> |-<br /> ||setattr||Set attributes of the cursor.<br /> |-<br /> ||use||Associate a cursor object with a window.<br /> |}<br /> <br /> === x_device ===<br /> Inherits from: [[#common x_device|common x_device]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||getattr||see common x_device: getattr<br /> |-<br /> ||setattr||see common x_device: setattr<br /> |-<br /> ||use||see common x_device: use<br /> |-<br /> ||read||see common x_device: read<br /> |-<br /> ||write||see common x_device: write<br /> |-<br /> ||getfocus||see common x_device: getfocus<br /> |-<br /> ||setfocus||see common x_device: setfocus<br /> |-<br /> ||bell||see common x_device: bell<br /> |-<br /> ||force_cursor||see common x_device: force_cursor<br /> |-<br /> ||freeze||see common x_device: freeze<br /> |-<br /> ||grab||see common x_device: grab<br /> |-<br /> ||manage||see common x_device: manage<br /> |-<br /> ||list_property||see common x_device: list_property<br /> |-<br /> ||get_property||see common x_device: get_property<br /> |-<br /> ||set_property||see common x_device: set_property<br /> |-<br /> ||add||see common x_device: add<br /> |-<br /> ||remove||see common x_device: remove<br /> |}<br /> <br /> === x_drawable ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||create||Create a Drawable object.<br /> |-<br /> ||destroy||Destroy a Drawable.<br /> |-<br /> ||read<br /> |-<br /> ||write<br /> |-<br /> ||blend<br /> |-<br /> ||getattr||Get attributes of a Drawable object<br /> |-<br /> ||setattr||Set attributes of a Drawable object<br /> |-<br /> ||list_child<br /> |-<br /> ||add_child<br /> |-<br /> ||remove_child<br /> |-<br /> ||list_property<br /> |-<br /> ||get_property<br /> |-<br /> ||set_property<br /> |-<br /> ||manage<br /> |-<br /> ||override<br /> |-<br /> ||show<br /> |-<br /> ||hide<br /> |-<br /> ||send<br /> |-<br /> ||receive<br /> |}<br /> <br /> === x_event ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||send<br /> |-<br /> ||receive<br /> |}<br /> <br /> === x_extension ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||query<br /> |-<br /> ||use<br /> |}<br /> <br /> === x_font ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||create||Load a font.<br /> |-<br /> ||destroy||Free (dereference) a font.<br /> |-<br /> ||getattr||Obtain font names, path, etc.<br /> |-<br /> ||add_glyph<br /> |-<br /> ||remove_glyph<br /> |-<br /> ||use||Use a font for drawing.<br /> |}<br /> <br /> === x_gc ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||create||Create Graphic Contexts object.<br /> |-<br /> ||destroy||Free (dereference) a Graphics Contexts object.<br /> |-<br /> ||getattr||Get attributes for Graphic Contexts object.<br /> |-<br /> ||setattr||Set attributes for Graphic Contexts object.<br /> |-<br /> ||use<br /> |}<br /> <br /> === x_keyboard ===<br /> Inherits from: [[#common x_device|common x_device]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||getattr||see common x_device: getattr<br /> |-<br /> ||setattr||see common x_device: setattr<br /> |-<br /> ||use||see common x_device: use<br /> |-<br /> ||read||see common x_device: read<br /> |-<br /> ||write||see common x_device: write<br /> |-<br /> ||getfocus||see common x_device: getfocus<br /> |-<br /> ||setfocus||see common x_device: setfocus<br /> |-<br /> ||bell||see common x_device: bell<br /> |-<br /> ||force_cursor||see common x_device: force_cursor<br /> |-<br /> ||freeze||see common x_device: freeze<br /> |-<br /> ||grab||see common x_device: grab<br /> |-<br /> ||manage||see common x_device: manage<br /> |-<br /> ||list_property||see common x_device: list_property<br /> |-<br /> ||get_property||see common x_device: get_property<br /> |-<br /> ||set_property||see common x_device: set_property<br /> |-<br /> ||add||see common x_device: add<br /> |-<br /> ||remove||see common x_device: remove<br /> |}<br /> <br /> === x_pointer ===<br /> Inherits from: [[#common x_device|common x_device]]<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||getattr||see common x_device: getattr<br /> |-<br /> ||setattr||see common x_device: setattr<br /> |-<br /> ||use||see common x_device: use<br /> |-<br /> ||read||see common x_device: read<br /> |-<br /> ||write||see common x_device: write<br /> |-<br /> ||getfocus||see common x_device: getfocus<br /> |-<br /> ||setfocus||see common x_device: setfocus<br /> |-<br /> ||bell||see common x_device: bell<br /> |-<br /> ||force_cursor||see common x_device: force_cursor<br /> |-<br /> ||freeze||see common x_device: freeze<br /> |-<br /> ||grab||see common x_device: grab<br /> |-<br /> ||manage||see common x_device: manage<br /> |-<br /> ||list_property||see common x_device: list_property<br /> |-<br /> ||get_property||see common x_device: get_property<br /> |-<br /> ||set_property||see common x_device: set_property<br /> |-<br /> ||add||see common x_device: add<br /> |-<br /> ||remove||see common x_device: remove<br /> |}<br /> <br /> === x_property ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||create||Create property object.<br /> |-<br /> ||destroy||Free (dereference) a property object.<br /> |-<br /> ||read||Read a property.<br /> |-<br /> ||write||Write a property.<br /> |-<br /> ||append||Append a property.<br /> |-<br /> ||getattr||Get the attributes of a property.<br /> |-<br /> ||setattr||Set the attributes of a property.<br /> |}<br /> <br /> === x_resource ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||read<br /> |-<br /> ||write<br /> |}<br /> <br /> === x_screen ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||getattr<br /> |-<br /> ||setattr<br /> |-<br /> ||hide_cursor<br /> |-<br /> ||show_cursor<br /> |-<br /> ||saver_getattr<br /> |-<br /> ||saver_setattr<br /> |-<br /> ||saver_hide<br /> |-<br /> ||saver_show<br /> |}<br /> <br /> === x_selection ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||read<br /> |-<br /> ||write<br /> |-<br /> ||getattr<br /> |-<br /> ||setattr<br /> |}<br /> <br /> === x_server ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||getattr<br /> |-<br /> ||setattr<br /> |-<br /> ||record<br /> |-<br /> ||debug<br /> |-<br /> ||grab<br /> |-<br /> ||manage<br /> |}<br /> <br /> === x_synthetic_event ===<br /> {| border=&quot;1&quot;<br /> ! Permission<br /> ! Description<br /> |-<br /> ||send<br /> |-<br /> ||receive<br /> |}</div> Jaxelson https://selinuxproject.org/page/NB_MAC NB MAC 2010-09-15T00:38:07Z <p>Jaxelson: linked subject and object</p> <hr /> <div>= Mandatory Access Control (MAC) =<br /> Mandatory Access Control (MAC) is a type of access control in which the operating system is used to constrain a user or process (the [[NB Subjects|subject]]) from accessing or performing an operation on an [[NB Objects|object]] (such as a file, disk, memory etc.). <br /> <br /> Each of the subjects and objects have a set of security attributes that can be interrogated by the operating system to check if the requested operation can be performed or not. For SELinux the:<br /> <br /> * [[NB_Subjects | Subjects]] are processes.<br /> * [[NB_Objects | Objects]] are system resources such as files, sockets, etc.<br /> * security attributes are the [[NB_SC | security context]].<br /> * Security Server within the Linux kernel authorizes access (or not) using the:<br /> * security policy (or policy) that describes rules that must be obeyed.<br /> <br /> Note that the subject (and therefore the user) cannot decide to bypass the policy rules being enforced by the MAC policy with SELinux enabled. Contrast this to standard Linux Discretionary Access Control (DAC), which also governs the ability of subjects to access objects, however it allows users to make policy decisions (see [http://taiga.selinuxproject.org/~rhaines/diagrams/3-processing-call.png Processing a System Call]).<br /> <br /> SELinux supports two forms of MAC:<br /> <br /> # '''Type Enforcement''' - Where processes run in domains and the actions on objects are controlled by the policy. This is the implementation used for general purpose MAC within SELinux. The [[NB_TE | Type Enforcement]] section covers this in more detail. <br /> # '''Multi-Level Security''' - This is an implementation based on the Bell-La Padula (BLP) model, and used by organizations where different levels of access are required so that (for example in some defence / Government systems) restricted information is separated from classified information (i.e. maintaining confidentiality). This allows enforcement rules such as &quot;no write down&quot; and &quot;no read up&quot; to be implemented in a policy by extending the security context to include security levels. The [[NB_MLS | Multilevel Security ]] section covers this in more detail along with a variant of MLS called Multi-Category Security (MCS). <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/Mac Mac 2010-09-15T00:36:57Z <p>Jaxelson: fixing redirect link</p> <hr /> <div>#REDIRECT[[NB MAC]]</div> Jaxelson https://selinuxproject.org/page/Mac Mac 2010-09-15T00:36:42Z <p>Jaxelson: created redirect</p> <hr /> <div>#REDIRECT[[NB MC]]</div> Jaxelson https://selinuxproject.org/page/Mandatory_Access_Control Mandatory Access Control 2010-09-13T23:37:57Z <p>Jaxelson: creating redirect</p> <hr /> <div>#REDIRECT[[NB MAC]]</div> Jaxelson https://selinuxproject.org/page/NewUsers NewUsers 2010-09-13T23:37:30Z <p>Jaxelson: /* What does SELinux do? */ linked MAC</p> <hr /> <div>This is a resource for new users, it explains in very broad terms what SELinux does, how to get it and so on.<br /> <br /> = What does SELinux do? =<br /> <br /> SELinux controls access between applications and resources. By using a [[Mandatory Access Control|mandatory]] security policy SELinux enforces the security goals of the system regardless of whether applications misbehave or users act carelessly.<br /> SELinux is capable of enforcing a wide range of security goals, from simply sandboxing applications to locking down network facing daemons and restricting users to only the resources they need to work.<br /> <br /> = How do I know if SELinux is on? =<br /> If you use Red Hat Enterprise Linux or Fedora it is enabled by default. To see whether it is actively enforcing the policy you can run getenforce:<br /> <br /> [root@localhost ~]# getenforce<br /> Enforcing<br /> <br /> If it says Enforcing (as above) your system is being protected by SELinux. If it says permissive SELinux is enabled but is only logging failed accesses, not denying them. If it says Disabled then SELinux is not enabled on your system.<br /> <br /> =How do I get it? =<br /> SELinux isn't a distribution by itself but a security enhancement to Linux that can be enabled by your distribution or vendor (or yourself if you are very motivated). <br /> <br /> {|<br /> ! Distribution<br /> ! How to get it<br /> |-<br /> ||Red Hat Enterprise Linux (4+)<br /> ||Default<br /> |-<br /> ||Fedora (2+)<br /> ||Default<br /> |-<br /> ||Ubuntu<br /> ||Hardened Ubuntu<br /> |-<br /> ||Debian<br /> ||add-on<br /> |-<br /> ||Gentoo<br /> ||Hardened Gentoo<br /> |}<br /> <br /> <br /> = Why do I have it? =<br /> <br /> Your distribution or vendor may have chosen to enable SELinux by default. They are doing this because they want added security protections on the versions of Linux they ship. A huge amount of effort has gone in to creating security policies that protect your system from intrusions while at the same time allowing users to behave the way they normally do. Leaving SELinux enabled on these systems is a good idea because it can protect you from zero-day and known vulnerabilities while balancing your need to use your system the way you need to.<br /> <br /> = Where can I find help? =<br /> <br /> There are several mailing lists and IRC channels depending on what distribution you are running and what you need help with. See the [[User_Help | Mailing lists and IRC channels]] page for a full list.<br /> <br /> This site has additional documentation that can help you use SELinux. You can start with the [[AdminDocs | administrators and users]] page.<br /> <br /> <br /> = The SELinux Notebook =<br /> Some of the sections from [http://www.freetechbooks.com/the-selinux-notebook-the-foundations-t785.html Volume 1 - The SELinux Notebook - The Foundations] are available on this site. <br /> <br /> The Notebook sections describe the SELinux services built into Fedora 12 and should give a high level description of the major components that provide Mandatory Access Control services for GNU / Linux.<br /> <br /> Hopefully it will show how all the SELinux components link together and how SELinux-aware applications and their object managers have been implemented (such as X-Windows, SE-PostgreSQL and virtual machines).<br /> <br /> == Notebook Sections ==<br /> The major sections are:<br /> * [[NB_Overview | SELinux Overview]]<br /> * [[NB_MAC | Mandatory Access Control (MAC)]]<br /> * [[NB_TE | Type Enforcement (TE)]]<br /> * [[NB_RBAC | Role-Based Access Control (RBAC)]]<br /> * [[NB_SC | Security Context]]<br /> * [[NB_Subjects | Subjects]]<br /> * [[NB_Objects | Objects]]<br /> * [[NB_MLS | Multi-Level Security and Multi-Category Security]]<br /> * [[NB_PolicyType | Types of SELinux Policy]]<br /> * [[NB_PandE | SELinux Permissive and Enforcing Modes]]<br /> * [[NB_AL |Audit Logs]]<br /> * [[NB_Poly | Polyinstantiation]]<br /> * [[NB_PAM | PAM Login Process]]<br /> * [[NB_LSM | Linux Security Module and SELinux]]<br /> * [[NB_Networking | SELinux Networking Support]]<br /> * [[NB_VM | SELinux Virtual Machine Support]]<br /> * [[NB_XWIN | SELinux X-Windows Support]]<br /> * [[NB_SQL | SELinux PostgreSQL Support]]<br /> * [[NB_Apache | Apache SELinux Support]]<br /> * [[NB_RefPolicy | Reference Policy Support]]<br /> <br /> == Relevant F-12 Packages ==<br /> The following are the rpm packages installed on the test machine used for all code listings, testing and research:<br /> &lt;pre&gt;<br /> checkpolicy-2.0.19-3.fc12.i686<br /> checkpolicy-2.0.19-3.fc12.src<br /> <br /> coreutils-7.6-8.f12.src<br /> <br /> ipsec-tools-0.7.3-4.fc12.i686<br /> <br /> kernel-2.6.31.5-127.fc12.i686<br /> kernel-2.6.31.5-127.fc12.src<br /> <br /> libselinux-2.0.90-5.fc12.i686<br /> libselinux-devel-2.0.90-5.fc12.i686<br /> libselinux-python-2.0.90-5.fc12.i686<br /> libselinux-utils-2.0.90-5.fc12.i686<br /> <br /> libsemanage-2.0.45-1.fc12.i686<br /> libsemanage-devel-2.0.45-1.fc12.i686<br /> libsemanage-python-2.0.45-1.fc12.i686<br /> <br /> libsepol-2.0.41-3.fc12.i686<br /> libsepol-devel-2.0.41-3.fc12.i686<br /> libsepol-static-2.0.41-3.fc12.i686<br /> libsepol-2.0.41-3.fc12.src<br /> <br /> libvirt-0.7.1-15.f12.src<br /> <br /> mcstrans-0.3.1-3.fc12.i686<br /> <br /> mod_selinux-2.2.2015-3.fc12.src<br /> <br /> netlabel_tools-0.19-3.fc12.i686<br /> <br /> policycoreutils-2.0.79-1.fc12.i686<br /> policycoreutils-gui-2.0.79-1.fc12.i686<br /> policycoreutils-sandbox-2.0.79-1.fc12.i686<br /> policycoreutils-python-2.0.79-1.fc12.i686<br /> policycoreutils-newrole-2.0.79-1.fc12.i686<br /> <br /> postgresql-libs-8.4.3-1.fc12.i686<br /> postgresql-8.4.3-1.fc12.i686<br /> postgresql-server-8.4.3-1.fc12.i686<br /> <br /> qemu-0.12.3-2.fc12.src<br /> <br /> selinux-policy-3.6.32-103.fc12.src<br /> selinux-policy-3.6.32-103.fc12.noarch<br /> selinux-policy-doc-3.6.32-103.fc12.noarch<br /> selinux-policy-minimum-3.6.32-103.fc12.noarch<br /> selinux-policy-mls-3.6.32-103.fc12.noarch<br /> selinux-policy-targeted-3.6.32-103.fc12.noarch<br /> <br /> sepostgresql-8.4.2-2583.fc12.i686<br /> <br /> setools-3.3.6-4.fc12.i686<br /> setools-console-3.3.6-4.fc12.i686<br /> setools-gui-3.3.6-4.fc12.i686<br /> setools-libs-3.3.6-4.fc12.i686<br /> setools-libs-java-3.3.6-4.fc12.i686<br /> setools-libs-tcl-3.3.6-4.fc12.i686<br /> <br /> xen-3.4.2-1.fc12.src<br /> &lt;/pre&gt;<br /> <br /> The gcc tools will be required to compile and link the test “C” applications used in some of the scenarios (&lt;tt&gt;gcc-4.4.2-20.i686&lt;/tt&gt; and &lt;tt&gt;libgcc-4.4.2-20.i686&lt;/tt&gt; rpms are installed on the test machine that is using the &lt;tt&gt;kernel-2.6.31.5-127.fc12.i686&lt;/tt&gt; rpm).</div> Jaxelson https://selinuxproject.org/page/NB_SC NB SC 2010-09-13T23:36:27Z <p>Jaxelson: /* Security Context */</p> <hr /> <div>= Security Context =<br /> SELinux requires a security context to be associated with every process (or [[SELinux subject|subject]]) and object that are used by the security server to decide whether access is allowed or not as defined by the policy.<br /> <br /> The security context is also known as a &quot;security label&quot; or just label that can cause confusion as there are many types of label depending on the context (another context!!).<br /> <br /> Within SELinux, a security context is represented as variable-length strings that define the SELinux user&lt;ref name=&quot;ftn7&quot;&gt;&lt;sup&gt;An SELinux user id is not the same as the GNU / Linux user id. The GNU / Linux user id is mapped to the SELinux user id by configuration files (via the &lt;tt&gt;semanage(8)&lt;/tt&gt; command).&lt;/sup&gt;&lt;/ref&gt;, their role, a type identifier and an optional MCS / MLS security level as follows:<br /> &lt;pre&gt;<br /> user:role:type[:level]<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> {| border=&quot;1&quot;<br /> | &lt;tt&gt;user&lt;/tt&gt;<br /> | The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.<br /> <br /> |-<br /> | &lt;tt&gt;role&lt;/tt&gt;<br /> | The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.<br /> <br /> |-<br /> | &lt;tt&gt;type&lt;/tt&gt;<br /> | When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access.<br /> <br /> When a type is associated with an object, it defines what access permissions the SELinux user has to that object.<br /> <br /> |-<br /> | &lt;tt&gt;level&lt;/tt&gt;<br /> | This optional field can also be know as a &lt;tt&gt;range&lt;/tt&gt; and is only present if the policy supports MCS or MLS. The entry can consist of:<br /> <br /> * A single security &lt;tt&gt;level&lt;/tt&gt; that contains a sensitivity level and zero or more categories (e.g. &lt;tt&gt;s0&lt;/tt&gt;, &lt;tt&gt;s1:c0&lt;/tt&gt;, &lt;tt&gt;s7:c10.c15&lt;/tt&gt;).<br /> * A &lt;tt&gt;range&lt;/tt&gt; that consists of two security levels (a low and high) separated by a hyphen (e.g. &lt;tt&gt;s0 - s15:c0.c1023&lt;/tt&gt;).<br /> <br /> These components are discussed in the [[NB_MLS#Security Levels | Security Levels]] section. <br /> <br /> |}<br /> <br /> <br /> However note that:<br /> # Access decisions regarding a subject make use of all the components of the [[NB_SC | security context]].<br /> # Access decisions regarding an object make use of all the components of the security context, however: <br /> :: a) the user is either set to a special user called &lt;tt&gt;system_u&lt;/tt&gt; or it is set to the SELinux user id of the creating process (as it serves no real purpose other than it can be used for audit purposes within logs). <br /> :: b) the role is not relevant to security decisions and is always set to a special SELinux internal role of &lt;tt&gt;object_r&lt;/tt&gt;.<br /> <br /> Therefore for an object, the type (and level for MLS) are the only relevant security fields that are used in access decisions. <br /> <br /> Examples of using &lt;tt&gt;system_u&lt;/tt&gt; and &lt;tt&gt;object_r&lt;/tt&gt; can be seen in the file system after relabeling and running the &lt;tt&gt;ls -Z&lt;/tt&gt; command on various directories.<br /> <br /> The examples below show security contexts for processes, directories and files (note that the policy did not support MCS or MLS, therefore no &lt;tt&gt;level&lt;/tt&gt; field):<br /> <br /> '''Example Process Security Context:'''<br /> &lt;pre&gt;<br /> # These are process security contexts taken from a ps -Z command <br /> # (edited for clarity) that show four processes:<br /> <br /> LABEL PID TTY CMD<br /> user_u:unconfined_r:unconfined_t 2539 pts/0 bash<br /> user_u:message_filter_r:ext_gateway_t 3134 pts/0 secure_server<br /> user_u:message_filter_r:int_gateway_t 3138 pts/0 secure_server<br /> user_u:unconfined_r:unconfined_t 3146 pts/0 ps<br /> <br /> # Note the bash and ps processes are running under the <br /> # unconfined_t domain, however the secure_server has two instances<br /> # running under two different domains (ext_gateway_t and <br /> # int_gateway_t). Also note that they are using the <br /> # message_filter_r role whereas bash and ps use unconfined_r.<br /> #<br /> # These results were obtained by running the system in permissive<br /> # mode (as in enforcing mode the gateway processes would not be shown).<br /> &lt;/pre&gt;<br /> <br /> '''Example Object Security Context:'''<br /> &lt;pre&gt;<br /> # These are the message queue directory object security contexts <br /> # taken from an ls -Zd command (edited for clarity):<br /> <br /> system_u:object_r:in_queue_t /user/message_queue/in_queue<br /> system_u:object_r:out_queue_t /user/message_queue/out_queue<br /> <br /> # Note that they are instantiated with system_u and object_r<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> # These are the message queue file object security contexts <br /> # taken from an ls -Z command (edited for clarity):<br /> <br /> /user/message_queue/in_queue:<br /> user_u:object_r:in_file_t Message-1<br /> user_u:object_r:in_file_t Message-2<br /> <br /> /user/message_queue/out_queue:<br /> user_u:object_r:out_file_t Message-10<br /> user_u:object_r:out_file_t Message-11<br /> <br /> # Note that they are instantiated with user_u as that was the <br /> # SELinux user id of the process that created the files (see the<br /> # process example above). The role remained as object_r.<br /> &lt;/pre&gt;<br /> <br /> ----<br /> &lt;references/&gt;<br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/User_Resources User Resources 2010-09-13T23:33:40Z <p>Jaxelson: /* Blogs */ wikified</p> <hr /> <div>== Guides ==<br /> <br /> [[Guide|SELinux Guide]]<br /> <br /> == FAQs and Documentation ==<br /> <br /> [http://www.slideshare.net/PaulWay/selinux-for-everyday-users SELinux for Everyday Users] (Slides by Paul Wayper)<br /> <br /> [http://www.slideshare.net/PaulWay/slug-2009-06-selinux-for-sysadmins SELinux for SysAdmins] (Slides by Paul Wayper)<br /> <br /> [http://userspace.selinuxproject.org/trac/wiki/SelinuxTools SELinux Tools] (canonical list with explanations)<br /> <br /> [http://docs.fedoraproject.org/selinux-user-guide/f11/en-US/ Fedora 11 SELinux User Guide]<br /> <br /> [http://sradvan.fedorapeople.org/SELinux_Managing_Confined_Services/en-US/html-single/ Managing SELinux confined services] (draft)<br /> <br /> [http://www.nsa.gov/research/selinux/faqs.shtml NSA SELinux FAQ]<br /> <br /> [http://fedoraproject.org/wiki/SELinux/FAQ Fedora SELinux FAQ]<br /> <br /> [http://oss.tresys.com/projects/refpolicy/wiki/Documentation Reference policy documentation]<br /> <br /> [http://www.nsa.gov/research/selinux/docs.shtml NSA SELinux documentation]<br /> <br /> [http://www.tresys.com/selinux.html Tresys SELinux resources]<br /> <br /> [http://people.redhat.com/drepper/selinux-mem.html Understanding SELinux memory protection controls]<br /> <br /> [http://people.redhat.com/drepper/textrelocs.html Explanation of text relocations and a description of how to find the reason and how to fix them]<br /> <br /> [http://jczucco.googlepages.com/selinux.html Portuguese Documentation] Hardening Linux Usando Controle de Acesso Mandatório<br /> <br /> [http://wiki.centos.org/TipsAndTricks/SelinuxBooleans SELinux Booleans] Documentation at the Centos Wiki<br /> <br /> [http://www.redhatmagazine.com/2008/07/02/writing-policy-for-confined-selinux-users/ Writing policy for confined SELinux users] Red Hat Magazine article by Dan Walsh.<br /> <br /> [http://magazine.redhat.com/2008/04/17/fedora-9-and-summit-preview-confining-the-user-with-selinux/ Fedora 9 and summit preview: Confining the user with SELinux] Red Hat Magazine article by Dan Walsh.<br /> <br /> [http://magazine.redhat.com/2007/05/04/whats-new-in-selinux-for-red-hat-enterprise-linux-5/ What's new in SELinux for Red Hat Enterprise Linux 5] Red Hat Magazine article by Dan Walsh.<br /> <br /> [http://magazine.redhat.com/2007/08/21/a-step-by-step-guide-to-building-a-new-selinux-policy-module/ A step by step guide to building a new SELinux policy module] Red Hat Magazine article by Dan Walsh.<br /> <br /> [http://www.redhat.com/magazine/001nov04/features/selinux/ What is Security-Enhanced Linux?] Red Hat Magazine article by Russell Coker.<br /> <br /> [http://www.ibm.com/developerworks/linux/library/l-lxc-security/index.html Secure Linux containers cookbook] by Serge Hallyn of IBM.<br /> <br /> [http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/ Role-based access control in SELinux: Learn your way around this admin-friendly security administration layer] by Serge Hallyn of IBM.<br /> <br /> [http://www.ibm.com/developerworks/linux/library/l-selinux.html SELinux from scratch: Build an SELinux-ready Gentoo system] by Serge Hallyn from IBM.<br /> <br /> [http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html Polyinstantiation of directories in an SELinux system] by Russell Coker.<br /> <br /> [http://www.redhat.com/magazine/006apr05/features/selinux/ Taking advantage of SELinux in Red Hat Enterprise Linux] Red Hat Magazine article by Faye Coker and Russell Coker.<br /> <br /> [http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ Red Hat Enterprise Linux 4 SELinux user guide]<br /> <br /> [http://www.redhat.com/search?q=selinux&amp;site=redhat_kbase&amp;asp_charset=ISO-8859-1&amp;filter=0&amp;client=kbase&amp;proxystylesheet=kbase&amp;lr=lang_en Summary of SELinux articles on Red Hat knowledge base]<br /> <br /> [http://fedoraproject.org/wiki/Interviews/SELinux Interview with Daniel Walsh, the principal developer of SELinux in Fedora from Red Hat, where he tells us more about what SELinux does and how it's improved in Fedora 8]<br /> <br /> [http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules Fedora SELinux Policy Module Packaging] (draft)<br /> <br /> [http://wiki.postgresql.org/wiki/SEPostgreSQL SEPostgreSQL introduction]<br /> <br /> [http://oss.tresys.com/projects/refpolicy/wiki/ObjectClassesPerms SELinux object classes and permissions reference]<br /> <br /> [http://oss.tresys.com/docs/refpolicy/api/ SELinux reference policy interface reference]<br /> <br /> [http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus SELinux plus introduction]<br /> <br /> [http://www.selinuxbyexample.com/ SELinux by example]<br /> <br /> [http://www.linuxsecurity.com/content/view/120622 Hacks From Pax: SELinux And Access Decisions] by Pax Dickinson.<br /> <br /> [http://www.linuxsecurity.com/content/view/120567/49/ Hacks From Pax: Security Enhanced Linux and Mandatory Access Control] by Pax Dickinson.<br /> <br /> [http://www.linuxsecurity.com/content/view/120837/169/ Hacks From Pax: SELinux Policy Development] by Pax Dickinson.<br /> <br /> [http://www.linuxjournal.com/article/9542 Paranoid Penguin - Introduction to SELinux, Part II] by Mick Bauer.<br /> <br /> [http://www.linuxjournal.com/article/9500 Paranoid Penguin - Introduction to SELinux] by Mick Bauer.<br /> <br /> [http://www.linuxjournal.com/article/9408 Multi-Category Security in SELinux in Fedora Core 5] by Russell Coker.<br /> <br /> [http://www.nsa.gov/research/_files/selinux/papers/policy2/t1.shtml Configuring the SELinux Policy]<br /> <br /> [[ObjectClassesPerms | Object Classes and Permissions descriptions]]<br /> <br /> == Mailing lists and IRC ==<br /> <br /> [[User_Help | Mailing lists and IRC channels]]<br /> <br /> == Blogs ==<br /> <br /> * [http://selinuxnews.org SELinux Community News]<br /> * [http://selinuxnews.org/planet Planet SELinux] - Aggregates all of the blogs below (plus some more)<br /> ** [http://danwalsh.livejournal.com/ Dan Walsh]<br /> ** [http://selinux-mac.blogspot.com/ Dominick Grift]<br /> ** [http://eparis.livejournal.com/ Eric Paris]<br /> ** [http://blog.namei.org/ James Morris]<br /> ** [http://securityblog.org/brindle/ Joshua Brindle]<br /> ** [http://paulmoore.livejournal.com/ Paul Moore]<br /> <br /> == Websites ==<br /> <br /> [http://wiki.russianfedora.ru/index.php/SELinux Russian Fedora SELinux Wiki]<br /> <br /> [http://www.nsa.gov/research/selinux/index.shtml NSA SELinux website]<br /> <br /> [http://www.selinux-symposium.org/ SELinux Symposium 2005-2007]<br /> <br /> [http://oss.tresys.com Tresys Open Source Server]<br /> <br /> [http://fedoraproject.org/wiki/SELinux/ Fedora SELinux project wiki]<br /> <br /> [http://www.gentoo.org/proj/en/hardened/selinux/index.xml Hardened Gentoo's SELinux project page]<br /> <br /> [http://wiki.debian.org/SELinux Debian SELinux wiki]<br /> <br /> [http://www.engardelinux.org/modules/index/selinux/ Engarde SELinux page]<br /> <br /> [http://wiki.ubuntu.com/SELinux Ubuntu SELinux wiki]<br /> <br /> [http://www.opensolaris.org/os/project/fmac OpenSolaris Flexible MAC project]<br /> <br /> [http://www.selinux.gr.jp/ Japanese SELinux Users Group]<br /> <br /> [http://www.coker.com.au/selinux/ Russell Coker's SELinux Site]<br /> <br /> [http://people.redhat.com/dwalsh/ Dan Walsh's SELinux site]<br /> <br /> [http://selinux.sourceforge.net/ Public forum for the NSA Security-Enhanced Linux project]<br /> <br /> == Tools ==<br /> <br /> [http://linux.die.net/man/8/setsebool setsebool(8)]<br /> <br /> [http://linux.die.net/man/1/audit2allow audit2allow(1)]<br /> <br /> [http://linux.die.net/man/8/semanage semanage(8)]<br /> <br /> [http://linux.die.net/man/8/restorecon restorecon(8)]<br /> <br /> [http://linux.die.net/man/1/chcon chcon(1)]<br /> <br /> [http://linux.die.net/man/3/matchpathcon matchpathcon(3)]<br /> <br /> [http://linux.die.net/man/8/chcat chcat(8)]<br /> <br /> [http://linux.die.net/man/8/getsebool getsebool(8)]<br /> <br /> [http://linux.die.net/man/8/semodule semodule(8)]<br /> <br /> [http://linux.die.net/man/8/sestatus sestatus(8)]<br /> <br /> [http://linux.die.net/man/8/togglesebool togglesebool(8)]<br /> <br /> [http://linux.die.net/man/8/selinuxenabled selinuxenabled(8)]<br /> <br /> [http://linux.die.net/man/8/setfiles setfiles(8)]<br /> <br /> [http://linux.die.net/man/8/audit2why audit2why(8)]<br /> <br /> [http://linux.die.net/man/8/fixfiles fixfiles(8)]<br /> <br /> [http://linux.die.net/man/8/getenforce getenforce(8)]<br /> <br /> [http://linux.die.net/man/8/setenforce setenforce(8)]<br /> <br /> [http://linux.die.net/man/1/newrole newrole(1)]<br /> <br /> [http://linux.die.net/man/8/run_init run_init(8)]<br /> <br /> [http://linux.die.net/man/1/runcon runcon(1)]<br /> <br /> [http://linux.die.net/man/8/restorecond restorecond(8)]<br /> <br /> system-config-selinux<br /> <br /> [https://fedorahosted.org/setroubleshoot SETroubleshoot]<br /> <br /> [http://oss.tresys.com/projects/slide SELinux Policy IDE (SLIDE)]<br /> <br /> [http://oss.tresys.com/projects/setools SETools Policy Analysis Suite]<br /> <br /> [http://oss.tresys.com/projects/cdsframework Cross Domain Solution Framework]<br /> <br /> [http://seedit.sourceforge.net SELinux Policy Editor]<br /> <br /> == Manual pages ==<br /> <br /> [http://linux.die.net/man/8/selinux selinux(8)]<br /> <br /> [http://linux.die.net/man/8/booleans booleans(8)]<br /> <br /> [http://linux.die.net/man/8/ftpd_selinux ftpd_selinux(8)]<br /> <br /> [http://linux.die.net/man/8/named_selinux named_selinux(8)]<br /> <br /> [http://linux.die.net/man/8/rsync_selinux rsync_selinux(8)]<br /> <br /> [http://linux.die.net/man/8/httpd_selinux httpd_selinux(8)]<br /> <br /> [http://linux.die.net/man/8/nfs_selinux nfs_selinux(8)]<br /> <br /> [http://linux.die.net/man/8/samba_selinux samba_selinux(8)]<br /> <br /> [http://linux.die.net/man/8/kerberos_selinux kerberos_selinux(8)]<br /> <br /> [http://linux.die.net/man/8/nis_selinux nis_selinux(8)]<br /> <br /> [http://linux.die.net/man/8/ypbind_selinux ypbind_selinux(8)]<br /> <br /> == Topics ==<br /> <br /> <br /> [[SELinux_models|SELinux security models and concepts]]</div> Jaxelson https://selinuxproject.org/page/SELinux_subject SELinux subject 2010-09-13T23:29:28Z <p>Jaxelson: creating redirect</p> <hr /> <div>#REDIRECT[[NB Subjects]]</div> Jaxelson https://selinuxproject.org/page/NB_SC NB SC 2010-09-13T23:29:14Z <p>Jaxelson: /* Security Context */ linking to selinux subject</p> <hr /> <div>= Security Context =<br /> SELinux requires a security context to be associated with every process (or [[SELinux subject|subject]]) and object that are used by the security server to decide whether access is allowed or not as defined by the policy.<br /> <br /> The security context is also known as a &quot;security label&quot; or just label that can cause confusion as there are many types of label depending on the context (another context!!).<br /> <br /> Within SELinux, a security context is represented as variable-length strings that define the SELinux user&lt;ref name=&quot;ftn7&quot;&gt;&lt;sup&gt;An SELinux user id is not the same as the GNU / Linux user id. The GNU / Linux user id is mapped to the SELinux user id by configuration files (via the &lt;tt&gt;semanage(8)&lt;/tt&gt; command).&lt;/sup&gt;&lt;/ref&gt;, their role, a type identifier and an optional MCS / MLS security level as follows:<br /> &lt;pre&gt;<br /> user:role:type[:level]<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> {| border=&quot;1&quot;<br /> | &lt;tt&gt;user&lt;/tt&gt;<br /> | The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.<br /> <br /> |-<br /> | &lt;tt&gt;role&lt;/tt&gt;<br /> | The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.<br /> <br /> |-<br /> | &lt;tt&gt;type&lt;/tt&gt;<br /> | When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access.<br /> <br /> When a type is associated with an object, it defines what access permissions the SELinux user has to that object.<br /> <br /> |-<br /> | &lt;tt&gt;level&lt;/tt&gt;<br /> | This field can also be know as a &lt;tt&gt;range&lt;/tt&gt; and is only present if the policy supports MCS or MLS. The entry can consist of:<br /> <br /> * A single security &lt;tt&gt;level&lt;/tt&gt; that contains a sensitivity level and zero or more categories (e.g. &lt;tt&gt;s0&lt;/tt&gt;, &lt;tt&gt;s1:c0&lt;/tt&gt;, &lt;tt&gt;s7:c10.c15&lt;/tt&gt;).<br /> * A &lt;tt&gt;range&lt;/tt&gt; that consists of two security levels (a low and high) separated by a hyphen (e.g. &lt;tt&gt;s0 - s15:c0.c1023&lt;/tt&gt;).<br /> <br /> These components are discussed in the [[NB_MLS#Security Levels | Security Levels]] section. <br /> <br /> |}<br /> <br /> <br /> However note that:<br /> # Access decisions regarding a subject make use of all the components of the [[NB_SC | security context]].<br /> # Access decisions regarding an object make use of all the components of the security context, however: <br /> :: a) the user is either set to a special user called &lt;tt&gt;system_u&lt;/tt&gt; or it is set to the SELinux user id of the creating process (as it serves no real purpose other than it can be used for audit purposes within logs). <br /> :: b) the role is not relevant to security decisions and is always set to a special SELinux internal role of &lt;tt&gt;object_r&lt;/tt&gt;.<br /> <br /> Therefore for an object, the type (and level for MLS) are the only relevant security fields that are used in access decisions. <br /> <br /> Examples of using &lt;tt&gt;system_u&lt;/tt&gt; and &lt;tt&gt;object_r&lt;/tt&gt; can be seen in the file system after relabeling and running the &lt;tt&gt;ls -Z&lt;/tt&gt; command on various directories.<br /> <br /> The examples below show security contexts for processes, directories and files (note that the policy did not support MCS or MLS, therefore no &lt;tt&gt;level&lt;/tt&gt; field):<br /> <br /> '''Example Process Security Context:'''<br /> &lt;pre&gt;<br /> # These are process security contexts taken from a ps -Z command <br /> # (edited for clarity) that show four processes:<br /> <br /> LABEL PID TTY CMD<br /> user_u:unconfined_r:unconfined_t 2539 pts/0 bash<br /> user_u:message_filter_r:ext_gateway_t 3134 pts/0 secure_server<br /> user_u:message_filter_r:int_gateway_t 3138 pts/0 secure_server<br /> user_u:unconfined_r:unconfined_t 3146 pts/0 ps<br /> <br /> # Note the bash and ps processes are running under the <br /> # unconfined_t domain, however the secure_server has two instances<br /> # running under two different domains (ext_gateway_t and <br /> # int_gateway_t). Also note that they are using the <br /> # message_filter_r role whereas bash and ps use unconfined_r.<br /> #<br /> # These results were obtained by running the system in permissive<br /> # mode (as in enforcing mode the gateway processes would not be shown).<br /> &lt;/pre&gt;<br /> <br /> '''Example Object Security Context:'''<br /> &lt;pre&gt;<br /> # These are the message queue directory object security contexts <br /> # taken from an ls -Zd command (edited for clarity):<br /> <br /> system_u:object_r:in_queue_t /user/message_queue/in_queue<br /> system_u:object_r:out_queue_t /user/message_queue/out_queue<br /> <br /> # Note that they are instantiated with system_u and object_r<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> # These are the message queue file object security contexts <br /> # taken from an ls -Z command (edited for clarity):<br /> <br /> /user/message_queue/in_queue:<br /> user_u:object_r:in_file_t Message-1<br /> user_u:object_r:in_file_t Message-2<br /> <br /> /user/message_queue/out_queue:<br /> user_u:object_r:out_file_t Message-10<br /> user_u:object_r:out_file_t Message-11<br /> <br /> # Note that they are instantiated with user_u as that was the <br /> # SELinux user id of the process that created the files (see the<br /> # process example above). The role remained as object_r.<br /> &lt;/pre&gt;<br /> <br /> ----<br /> &lt;references/&gt;<br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/Selinux_subject Selinux subject 2010-09-13T23:27:56Z <p>Jaxelson: creating redirect</p> <hr /> <div>#REDIRECT[[NB Subjects]]</div> Jaxelson https://selinuxproject.org/page/SELinux_contexts SELinux contexts 2010-09-13T23:26:45Z <p>Jaxelson: creating redirect</p> <hr /> <div>#REDIRECT[[NB SC]]</div> Jaxelson https://selinuxproject.org/page/Guide/Contexts Guide/Contexts 2010-09-13T23:26:33Z <p>Jaxelson: /* Contexts */ linking selinux contexts</p> <hr /> <div>== Contexts ==<br /> <br /> [[SELinux contexts]] are composed of 4 pieces: selinux user, role, type, and range.<br /> <br /> &lt;pre&gt;<br /> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c255<br /> user : role : type : range <br /> &lt;/pre&gt;<br /> <br /> The selinux range is composed of a low and high level:<br /> <br /> &lt;pre&gt;<br /> s0-s0:c0.c255<br /> low-high <br /> &lt;/pre&gt;<br /> <br /> Each level is composed a MLS sensitivity and a set of categories:<br /> <br /> &lt;pre&gt;<br /> s0:c0.c255<br /> sensitivity:categories<br /> &lt;/pre&gt;<br /> <br /> Categories are can be specified individually:<br /> <br /> &lt;pre&gt;<br /> c0,c5,c10<br /> &lt;/pre&gt;<br /> <br /> Or treated as an ordered set:<br /> <br /> &lt;pre&gt;<br /> c0.c10<br /> &lt;/pre&gt;<br /> <br /> Where this would mean all categories between c0 and c10 (inclusive).<br /> <br /> === Displaying Contexts ===<br /> <br /> Display the context of...<br /> <br /> ... your shell:<br /> <br /> &lt;pre&gt;<br /> $ id -Z<br /> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c255<br /> &lt;/pre&gt;<br /> <br /> ... a file:<br /> <br /> &lt;pre&gt;<br /> $ ls -Z /bin/bash<br /> system_u:object_r:shell_exec_t:s0 /bin/bash<br /> &lt;/pre&gt;<br /> <br /> ... a process:<br /> <br /> &lt;pre&gt;<br /> $ ps -Z<br /> LABEL PID TTY TIME CMD<br /> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c255 23912 pts/3 00:00:00 bash<br /> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c255 25101 pts/3 00:00:00 ps<br /> &lt;/pre&gt;<br /> <br /> === Changing Contexts ===<br /> <br /> Change the context of...<br /> <br /> ... a file:<br /> <br /> &lt;pre&gt;<br /> $ touch /tmp/myfile<br /> $ ls -Z /tmp/myfile<br /> unconfined_u:object_r:user_tmp_t:s0 /tmp/myfile<br /> $ chcon -t user_home_t /tmp/myfile<br /> $ ls -Z /tmp/myfile<br /> unconfined_u:object_r:user_home_t:s0 /tmp/myfile<br /> &lt;/pre&gt;<br /> <br /> ... a file (persistently across relabels):<br /> <br /> &lt;pre&gt;<br /> # touch /var/cache/myfile<br /> # ls -Z /var/cache/myfile <br /> unconfined_u:object_r:var_t:s0 /var/cache/myfile<br /> # semanage fcontext -a -t user_home_t /var/cache/myfile <br /> # restorecon /var/cache/myfile <br /> # ls -Z /var/cache/myfile <br /> system_u:object_r:user_home_t:s0 /var/cache/myfile<br /> &lt;/pre&gt;<br /> <br /> ... your shell:<br /> <br /> &lt;pre&gt;<br /> $ id -Z<br /> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c255<br /> $ newrole -r system_r -t unconfined_t<br /> Password:<br /> $ id -Z<br /> unconfined_u:system_r:unconfined_t:s0-s0:c0.c255<br /> &lt;/pre&gt;<br /> <br /> ... a program when started (temporary):<br /> <br /> &lt;pre&gt;<br /> $ runcon system_u:system_r:crond_t:s0:c0.c255 /bin/bash<br /> $ id -Z<br /> system_u:system_r:crond_t:s0:c0.c255<br /> &lt;/pre&gt;<br /> <br /> === Resetting Contexts ===<br /> <br /> Reset the context of...<br /> <br /> ... a file:<br /> <br /> &lt;pre&gt;<br /> $ restorecon /tmp/myfile<br /> &lt;/pre&gt;</div> Jaxelson https://selinuxproject.org/page/Selinux_contexts Selinux contexts 2010-09-13T23:25:58Z <p>Jaxelson: created redirect</p> <hr /> <div>#REDIRECT[[NB SC]]</div> Jaxelson https://selinuxproject.org/page/Selinux_context Selinux context 2010-09-13T23:25:37Z <p>Jaxelson: created redirect</p> <hr /> <div>#REDIRECT[[NB SC]]</div> Jaxelson https://selinuxproject.org/page/NB_TE NB TE 2010-09-13T23:21:41Z <p>Jaxelson: /* Type Enforcement (TE) */ linked mandatory access control</p> <hr /> <div>''See Also: [[TypeEnforcement]]''<br /> = Type Enforcement (TE) =<br /> SELinux makes use of a specific style of type enforcement&lt;ref name=&quot;ftn5&quot;&gt;&lt;sup&gt;There are various &quot;type enforcement&quot; technologies. &lt;/sup&gt;&lt;/ref&gt; (TE) to enforce [[mandatory access control]]. For SELinux it means that all [[NB_Subjects | subjects]] and [[NB_Objects | objects]] have a type identifier associated to them that can then be used to enforce rules laid down in a policy. <br /> <br /> The SELinux type identifier is a simple variable-length string that is defined in the policy and then associated to a [[NB_SC | security context]]. It is also used in the majority of [[PolicyLanguage | SELinux language statements and rules]] used to build a policy that will, when loaded into the security server, enforce the policy.<br /> <br /> Because the type identifier (or just &quot;type&quot;) is associated to all subjects and objects, it can sometimes be difficult to distinguish what the type is actually associated with (it's not helped by the fact that by convention, type identifiers all end in &quot;&lt;tt&gt;_t&lt;/tt&gt;&quot;). In the end it comes down to understanding how they are allocated in the policy itself and how they are used by SELinux services. <br /> <br /> Basically if the type identifier is used to reference a subject it is referring to a GNU / Linux process or domain (i.e. domain type). If the type identifier is used to reference an object then it is specifying its object type (i.e. file type).<br /> <br /> While SELinux refers to a subject as being an active process that is associated to a domain type, the scope of an SELinux type enforcement domain can vary widely. For example in the simple policy built in the [[Building a Basic Policy]] section, all the processes on the system run in the unconfined_t domain, therefore every process is &quot;of type &lt;tt&gt;unconfined_t&lt;/tt&gt;&quot; (that means it can do whatever it likes within the limits of the standard Linux DAC policy).<br /> <br /> It is only when additional policies are implemented in the simple policy (via loadable modules), that areas start to be confined, for example an external gateway is run in its own isolated domain (&lt;tt&gt;ext_gateway_t&lt;/tt&gt;) that cannot be &quot;interfered&quot; with by any of the &lt;tt&gt;unconfined_t&lt;/tt&gt; processes (except to run or transition the gateway process into its own domain). This scenario is similar to the &quot;targeted&quot; policy delivered as standard in Red Hat Fedora where the majority of user space processes run under the unconfined_t domain (although don't think they are equivalent as the policies supplied with the [[Reference Policy]] have areas isolated by various domains and has evolved over years of work).<br /> <br /> == Constraints ==<br /> Within a TE environment the way that subjects are allowed to access an object is via an &lt;tt&gt;allow&lt;/tt&gt; rule, for example:<br /> &lt;pre&gt;<br /> allow unconfined_t ext_gateway_t : process transition;<br /> &lt;/pre&gt;<br /> <br /> This is explained in more detail later, however it states that a process running in the &lt;tt&gt;unconfined_t&lt;/tt&gt; domain has permission to transition a process to the &lt;tt&gt;ext_gateway_t&lt;/tt&gt; domain. However it could be that the policy writer wants to constrain this further and state that this can only happen if the role of the source domain is the same as the role of the target domain. To achieve this a constraint can be imposed using a &lt;tt&gt;constrain&lt;/tt&gt; statement:<br /> &lt;pre&gt;<br /> constrain process transition ( r1 == r2 );<br /> &lt;/pre&gt;<br /> <br /> This states that a process transition can only occur if the source role is the same as the target role, therefore a constraint is a condition that must be satisfied in order for one or more permissions to be granted (i.e. a constraint imposes additional restrictions on TE rules). An example of this can be found in the [[ConstraintStatements | Constraint Statements]] section.<br /> <br /> There are a number of different constraint statements within the policy language to support areas such as MLS (see the [[ConstraintStatements | Constraint Statements]] and [[MLSStatements | MLS Statements]] sections). <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_TE NB TE 2010-09-13T21:21:44Z <p>Jaxelson: linked building a basic policy</p> <hr /> <div>''See Also: [[TypeEnforcement]]''<br /> = Type Enforcement (TE) =<br /> SELinux makes use of a specific style of type enforcement&lt;ref name=&quot;ftn5&quot;&gt;&lt;sup&gt;There are various &quot;type enforcement&quot; technologies. &lt;/sup&gt;&lt;/ref&gt; (TE) to enforce mandatory access control. For SELinux it means that all [[NB_Subjects | subjects]] and [[NB_Objects | objects]] have a type identifier associated to them that can then be used to enforce rules laid down in a policy. <br /> <br /> The SELinux type identifier is a simple variable-length string that is defined in the policy and then associated to a [[NB_SC | security context]]. It is also used in the majority of [[PolicyLanguage | SELinux language statements and rules]] used to build a policy that will, when loaded into the security server, enforce the policy.<br /> <br /> Because the type identifier (or just &quot;type&quot;) is associated to all subjects and objects, it can sometimes be difficult to distinguish what the type is actually associated with (it's not helped by the fact that by convention, type identifiers all end in &quot;&lt;tt&gt;_t&lt;/tt&gt;&quot;). In the end it comes down to understanding how they are allocated in the policy itself and how they are used by SELinux services. <br /> <br /> Basically if the type identifier is used to reference a subject it is referring to a GNU / Linux process or domain (i.e. domain type). If the type identifier is used to reference an object then it is specifying its object type (i.e. file type).<br /> <br /> While SELinux refers to a subject as being an active process that is associated to a domain type, the scope of an SELinux type enforcement domain can vary widely. For example in the simple policy built in the [[Building a Basic Policy]] section, all the processes on the system run in the unconfined_t domain, therefore every process is &quot;of type &lt;tt&gt;unconfined_t&lt;/tt&gt;&quot; (that means it can do whatever it likes within the limits of the standard Linux DAC policy).<br /> <br /> It is only when additional policies are implemented in the simple policy (via loadable modules), that areas start to be confined, for example an external gateway is run in its own isolated domain (&lt;tt&gt;ext_gateway_t&lt;/tt&gt;) that cannot be &quot;interfered&quot; with by any of the &lt;tt&gt;unconfined_t&lt;/tt&gt; processes (except to run or transition the gateway process into its own domain). This scenario is similar to the &quot;targeted&quot; policy delivered as standard in Red Hat Fedora where the majority of user space processes run under the unconfined_t domain (although don't think they are equivalent as the policies supplied with the [[Reference Policy]] have areas isolated by various domains and has evolved over years of work).<br /> <br /> == Constraints ==<br /> Within a TE environment the way that subjects are allowed to access an object is via an &lt;tt&gt;allow&lt;/tt&gt; rule, for example:<br /> &lt;pre&gt;<br /> allow unconfined_t ext_gateway_t : process transition;<br /> &lt;/pre&gt;<br /> <br /> This is explained in more detail later, however it states that a process running in the &lt;tt&gt;unconfined_t&lt;/tt&gt; domain has permission to transition a process to the &lt;tt&gt;ext_gateway_t&lt;/tt&gt; domain. However it could be that the policy writer wants to constrain this further and state that this can only happen if the role of the source domain is the same as the role of the target domain. To achieve this a constraint can be imposed using a &lt;tt&gt;constrain&lt;/tt&gt; statement:<br /> &lt;pre&gt;<br /> constrain process transition ( r1 == r2 );<br /> &lt;/pre&gt;<br /> <br /> This states that a process transition can only occur if the source role is the same as the target role, therefore a constraint is a condition that must be satisfied in order for one or more permissions to be granted (i.e. a constraint imposes additional restrictions on TE rules). An example of this can be found in the [[ConstraintStatements | Constraint Statements]] section.<br /> <br /> There are a number of different constraint statements within the policy language to support areas such as MLS (see the [[ConstraintStatements | Constraint Statements]] and [[MLSStatements | MLS Statements]] sections). <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/Reference_Policy Reference Policy 2010-09-13T21:20:32Z <p>Jaxelson: Redirecting to NB RefPolicy</p> <hr /> <div>#REDIRECT[[NB RefPolicy]]</div> Jaxelson https://selinuxproject.org/page/NB_TE NB TE 2010-09-13T21:20:06Z <p>Jaxelson: /* Type Enforcement (TE) */ linked reference policy</p> <hr /> <div>''See Also: [[TypeEnforcement]]''<br /> = Type Enforcement (TE) =<br /> SELinux makes use of a specific style of type enforcement&lt;ref name=&quot;ftn5&quot;&gt;&lt;sup&gt;There are various &quot;type enforcement&quot; technologies. &lt;/sup&gt;&lt;/ref&gt; (TE) to enforce mandatory access control. For SELinux it means that all [[NB_Subjects | subjects]] and [[NB_Objects | objects]] have a type identifier associated to them that can then be used to enforce rules laid down in a policy. <br /> <br /> The SELinux type identifier is a simple variable-length string that is defined in the policy and then associated to a [[NB_SC | security context]]. It is also used in the majority of [[PolicyLanguage | SELinux language statements and rules]] used to build a policy that will, when loaded into the security server, enforce the policy.<br /> <br /> Because the type identifier (or just &quot;type&quot;) is associated to all subjects and objects, it can sometimes be difficult to distinguish what the type is actually associated with (it's not helped by the fact that by convention, type identifiers all end in &quot;&lt;tt&gt;_t&lt;/tt&gt;&quot;). In the end it comes down to understanding how they are allocated in the policy itself and how they are used by SELinux services. <br /> <br /> Basically if the type identifier is used to reference a subject it is referring to a GNU / Linux process or domain (i.e. domain type). If the type identifier is used to reference an object then it is specifying its object type (i.e. file type).<br /> <br /> While SELinux refers to a subject as being an active process that is associated to a domain type, the scope of an SELinux type enforcement domain can vary widely. For example in the simple policy built in the Building a Basic Policy section of volume 2, all the processes on the system run in the unconfined_t domain, therefore every process is &quot;of type &lt;tt&gt;unconfined_t&lt;/tt&gt;&quot; (that means it can do whatever it likes within the limits of the standard Linux DAC policy).<br /> <br /> It is only when additional policies are implemented in the simple policy (via loadable modules), that areas start to be confined, for example an external gateway is run in its own isolated domain (&lt;tt&gt;ext_gateway_t&lt;/tt&gt;) that cannot be &quot;interfered&quot; with by any of the &lt;tt&gt;unconfined_t&lt;/tt&gt; processes (except to run or transition the gateway process into its own domain). This scenario is similar to the &quot;targeted&quot; policy delivered as standard in Red Hat Fedora where the majority of user space processes run under the unconfined_t domain (although don't think they are equivalent as the policies supplied with the [[Reference Policy]] have areas isolated by various domains and has evolved over years of work).<br /> <br /> == Constraints ==<br /> Within a TE environment the way that subjects are allowed to access an object is via an &lt;tt&gt;allow&lt;/tt&gt; rule, for example:<br /> &lt;pre&gt;<br /> allow unconfined_t ext_gateway_t : process transition;<br /> &lt;/pre&gt;<br /> <br /> This is explained in more detail later, however it states that a process running in the &lt;tt&gt;unconfined_t&lt;/tt&gt; domain has permission to transition a process to the &lt;tt&gt;ext_gateway_t&lt;/tt&gt; domain. However it could be that the policy writer wants to constrain this further and state that this can only happen if the role of the source domain is the same as the role of the target domain. To achieve this a constraint can be imposed using a &lt;tt&gt;constrain&lt;/tt&gt; statement:<br /> &lt;pre&gt;<br /> constrain process transition ( r1 == r2 );<br /> &lt;/pre&gt;<br /> <br /> This states that a process transition can only occur if the source role is the same as the target role, therefore a constraint is a condition that must be satisfied in order for one or more permissions to be granted (i.e. a constraint imposes additional restrictions on TE rules). An example of this can be found in the [[ConstraintStatements | Constraint Statements]] section.<br /> <br /> There are a number of different constraint statements within the policy language to support areas such as MLS (see the [[ConstraintStatements | Constraint Statements]] and [[MLSStatements | MLS Statements]] sections). <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/SELinux_models SELinux models 2010-09-13T21:08:43Z <p>Jaxelson: /* Introduction to SELinux security models and concepts */ linking security context</p> <hr /> <div>== Introduction to SELinux security models and concepts ==<br /> <br /> <br /> SELinux implements a security model that is a combination of SELinux User Identities, Role-Based Access control and [[Type Enforcement]]. Optional models that can be implemented are User-Based Access Control, Multi Level Security or Multi Category Security. Each of these models have a Security attribute, and the combination of these Security attributes is called a [[Security context]].<br /> <br /> == SELinux User Identities ==<br /> <br /> <br /> The SELinux User Identity attribute is the first attribute in the Security context. This attribute is used to assign SELinux Roles and Security Level ranges, or Security Category ranges to Linux User Identities. SELinux User Identities are independent of the Linux User Identities. Constraints in the security policy define whether SELinux User Identities can be changed. <br /> <br /> == Role-Based Access Control ==<br /> <br /> <br /> The Role-based Access Control attribute is the second attribute in the Security context. This attribute is used to assign Security domains to SELinux User Identities. Role-Based Access Control is only applicable to processes. The SELinux Role attribute in Security contexts for objects is generic.<br /> <br /> == Type Enforcement ==<br /> <br /> <br /> The Type Enforcement attribute is the third attribute in the Security context. This attribute is used to assign types to processes and objects. These types can be used to define how processes and objects can interact. Type transitions define whether types for processes and objects can be changed.<br /> <br /> <br /> Optional models and concepts<br /> ----<br /> <br /> <br /> == User-Based Access Control ==<br /> <br /> <br /> The User-Based Access Control attribute is the first attribute in the Security context. User-Based Access Control is an optional extension to the SELinux User Identity concept. This User-Based Access Control concept is used to achieve SELinux User Identity separation. Constraints in the security policy define how SELinux User Identities can interact with each others resources.<br /> <br /> == Multi Level Security ==<br /> <br /> <br /> The Multi Level Security attribute is the fourth attribute in the Security context. This attribute is used to assign Security levels and Security compartments to processes and objects to enforce confidentiality. Constraints in the security policy define how processes and files can interact. Processes are forced to operate on specified Security Levels, and in specified Security Compartments. The Multi Level Security model enforces a &quot;no read up and no write down&quot; policy. Multi Level Security and Multi Category Security are mutually exclusive.<br /> <br /> == Multi Category Security ==<br /> <br /> <br /> The Multi Category Security attribute is the fourth attribute in the Security context. This attribute is used to assign Security Categories to processes and objects. The Security level attribute in Multi Category Security contexts is generic. Constraints in the security policy define how processes and files can interact. Multi Category Security is a implementation of Multi Level Security where the use of assigned Security Categories is to the discretion of the user. Multi Category Security and Multi Level Security are mutually exclusive.<br /> <br /> --[[User:DominickGrift|DominickGrift]] 06:31, 2 July 2009 (PDT)</div> Jaxelson https://selinuxproject.org/page/Type_Enforcement Type Enforcement 2010-09-13T21:08:16Z <p>Jaxelson: created redirect</p> <hr /> <div>#REDIRECT[[NB TE]]</div> Jaxelson https://selinuxproject.org/page/SELinux_models SELinux models 2010-09-13T21:07:47Z <p>Jaxelson: /* Introduction to SELinux security models and concepts */ messed up type enforcement link</p> <hr /> <div>== Introduction to SELinux security models and concepts ==<br /> <br /> <br /> SELinux implements a security model that is a combination of SELinux User Identities, Role-Based Access control and [[Type Enforcement]]. Optional models that can be implemented are User-Based Access Control, Multi Level Security or Multi Category Security. Each of these models have a Security attribute, and the combination of these Security attributes is called a Security context.<br /> <br /> == SELinux User Identities ==<br /> <br /> <br /> The SELinux User Identity attribute is the first attribute in the Security context. This attribute is used to assign SELinux Roles and Security Level ranges, or Security Category ranges to Linux User Identities. SELinux User Identities are independent of the Linux User Identities. Constraints in the security policy define whether SELinux User Identities can be changed. <br /> <br /> == Role-Based Access Control ==<br /> <br /> <br /> The Role-based Access Control attribute is the second attribute in the Security context. This attribute is used to assign Security domains to SELinux User Identities. Role-Based Access Control is only applicable to processes. The SELinux Role attribute in Security contexts for objects is generic.<br /> <br /> == Type Enforcement ==<br /> <br /> <br /> The Type Enforcement attribute is the third attribute in the Security context. This attribute is used to assign types to processes and objects. These types can be used to define how processes and objects can interact. Type transitions define whether types for processes and objects can be changed.<br /> <br /> <br /> Optional models and concepts<br /> ----<br /> <br /> <br /> == User-Based Access Control ==<br /> <br /> <br /> The User-Based Access Control attribute is the first attribute in the Security context. User-Based Access Control is an optional extension to the SELinux User Identity concept. This User-Based Access Control concept is used to achieve SELinux User Identity separation. Constraints in the security policy define how SELinux User Identities can interact with each others resources.<br /> <br /> == Multi Level Security ==<br /> <br /> <br /> The Multi Level Security attribute is the fourth attribute in the Security context. This attribute is used to assign Security levels and Security compartments to processes and objects to enforce confidentiality. Constraints in the security policy define how processes and files can interact. Processes are forced to operate on specified Security Levels, and in specified Security Compartments. The Multi Level Security model enforces a &quot;no read up and no write down&quot; policy. Multi Level Security and Multi Category Security are mutually exclusive.<br /> <br /> == Multi Category Security ==<br /> <br /> <br /> The Multi Category Security attribute is the fourth attribute in the Security context. This attribute is used to assign Security Categories to processes and objects. The Security level attribute in Multi Category Security contexts is generic. Constraints in the security policy define how processes and files can interact. Multi Category Security is a implementation of Multi Level Security where the use of assigned Security Categories is to the discretion of the user. Multi Category Security and Multi Level Security are mutually exclusive.<br /> <br /> --[[User:DominickGrift|DominickGrift]] 06:31, 2 July 2009 (PDT)</div> Jaxelson https://selinuxproject.org/page/SELinux_models SELinux models 2010-09-13T21:07:30Z <p>Jaxelson: /* Introduction to SELinux security models and concepts */</p> <hr /> <div>== Introduction to SELinux security models and concepts ==<br /> <br /> <br /> SELinux implements a security model that is a combination of SELinux User Identities, Role-Based Access control and [Type Enforcement]. Optional models that can be implemented are User-Based Access Control, Multi Level Security or Multi Category Security. Each of these models have a Security attribute, and the combination of these Security attributes is called a Security context.<br /> <br /> == SELinux User Identities ==<br /> <br /> <br /> The SELinux User Identity attribute is the first attribute in the Security context. This attribute is used to assign SELinux Roles and Security Level ranges, or Security Category ranges to Linux User Identities. SELinux User Identities are independent of the Linux User Identities. Constraints in the security policy define whether SELinux User Identities can be changed. <br /> <br /> == Role-Based Access Control ==<br /> <br /> <br /> The Role-based Access Control attribute is the second attribute in the Security context. This attribute is used to assign Security domains to SELinux User Identities. Role-Based Access Control is only applicable to processes. The SELinux Role attribute in Security contexts for objects is generic.<br /> <br /> == Type Enforcement ==<br /> <br /> <br /> The Type Enforcement attribute is the third attribute in the Security context. This attribute is used to assign types to processes and objects. These types can be used to define how processes and objects can interact. Type transitions define whether types for processes and objects can be changed.<br /> <br /> <br /> Optional models and concepts<br /> ----<br /> <br /> <br /> == User-Based Access Control ==<br /> <br /> <br /> The User-Based Access Control attribute is the first attribute in the Security context. User-Based Access Control is an optional extension to the SELinux User Identity concept. This User-Based Access Control concept is used to achieve SELinux User Identity separation. Constraints in the security policy define how SELinux User Identities can interact with each others resources.<br /> <br /> == Multi Level Security ==<br /> <br /> <br /> The Multi Level Security attribute is the fourth attribute in the Security context. This attribute is used to assign Security levels and Security compartments to processes and objects to enforce confidentiality. Constraints in the security policy define how processes and files can interact. Processes are forced to operate on specified Security Levels, and in specified Security Compartments. The Multi Level Security model enforces a &quot;no read up and no write down&quot; policy. Multi Level Security and Multi Category Security are mutually exclusive.<br /> <br /> == Multi Category Security ==<br /> <br /> <br /> The Multi Category Security attribute is the fourth attribute in the Security context. This attribute is used to assign Security Categories to processes and objects. The Security level attribute in Multi Category Security contexts is generic. Constraints in the security policy define how processes and files can interact. Multi Category Security is a implementation of Multi Level Security where the use of assigned Security Categories is to the discretion of the user. Multi Category Security and Multi Level Security are mutually exclusive.<br /> <br /> --[[User:DominickGrift|DominickGrift]] 06:31, 2 July 2009 (PDT)</div> Jaxelson https://selinuxproject.org/page/NB_XWIN NB XWIN 2010-09-13T21:06:50Z <p>Jaxelson: </p> <hr /> <div>= SELinux X-Windows Support =<br /> The SELinux X-Windows (XSELinux) implementation provides fine grained access control over the majority of the X-server objects (known as resources). The Reference Policy modules have also been updated to enforce policy using the XSELinux object manager (OM).<br /> <br /> This section will only give a high level description of the infrastructure based on the [http://taiga.selinuxproject.org/~rhaines/diagrams/26-x-windows.png X-Server and XSELinux Object Manager] diagram, however the &quot;[http://www.nsa.gov/research/_files/selinux/papers/xorg07-paper.pdf Application of the Flask Architecture to the X Window System Server]&quot; paper has a good overview of how the object manager (OM) has been implemented, although it does not cover areas such as polyinstantiation. There are also some sample X-widows applications for experimenting with policy in the Experimenting with X-Windows section of volume 2 (and also in the [[Experimenters_Corner | Experimenters Corner]] section). <br /> <br /> The object classes and permissions are listed in the [[ObjectClassesPerms | X Windows Object Classes]] section.<br /> <br /> <br /> == Infrastructure Overview ==<br /> It is important to note that the X-windows OM operates on the low level window objects of the X-server. A windows manager (such as Gnome or twm) would then sit above this, however they (the windows manager or even the lower level Xlib) would not be aware of the policy being enforced by SELinux. Therefore there can be situations where X-windows applications get bitter &amp; twisted at the denial of a service. This can result in either opening the policy more than desired, just letting the application keep aborting, or modifying the application.<br /> <br /> Using the [http://taiga.selinuxproject.org/~rhaines/diagrams/26-x-windows.png X-Server and XSELinux Object Manager] diagram, the major components that form the overall XSELinux OM are (top left to right):<br /> <br /> : '''The Policy''' - The Reference Policy has been updated to support the XSELinux OM and F-12 is now operational from policy version &lt;tt&gt;selinux-policy-3.6.32-100.fc12&lt;/tt&gt; for &lt;tt&gt;targeted&lt;/tt&gt; and &lt;tt&gt;mls&lt;/tt&gt; versions (Note that in F-12 the OM is enabled for mls and disabled for targeted policies via the &lt;tt&gt;xserver-object-manager&lt;/tt&gt; boolean).<br /> <br /> : &lt;tt&gt;'''libselinux'''&lt;/tt&gt; - This library provides the necessary interfaces between the OM , the SELinux userspace services (e.g. reading configuration information and providing the AVC), and kernel services (e.g. security server for access decisions and policy update notification).<br /> <br /> : &lt;tt&gt;'''x_contexts&lt;/tt&gt; File''' - This contains context configuration information that is required by the OM for labeling certain objects. The OM reads its contents using the &lt;tt&gt;selabel_lookup&lt;/tt&gt; function.<br /> <br /> : '''XSELinux Object Manager''' - This is an X-extension for the X-server process that mediates all access decisions between the the X-server (via the XACE interface) and the SELinux security server (via &lt;tt&gt;libselinux&lt;/tt&gt;). The OM is initialised before any X-clients connect to the X-server. <br /> <br /> : The OM has added X-protocol extensions to allow contexts to be set and retrieved by userspace SELinux-aware applications. These are shown in Table 1 and used in the [[Experimenters_Corner | Experimenting with X-Windows section]].<br /> <br /> : '''XACE Interface''' - This is a standards based 'X Access Control Extension' (XACE) that can be used by other access control security extensions, not only SELinux. Note that if other security extensions are linked at the same time, then the X-function will only succeed if allowed by all the security extensions in the chain.<br /> <br /> : The interface is defined in the &quot;[http://www.x.org/releases/X11R7.5/%20doc/security/XACE-Spec.pdf X Access Control Extension Specification]&quot;. This specification also defines the hooks available to OMs and how they should be used. The provision of polyinstantiation services for properties and selections is also discussed. The XACE interface is a similar service to the LSM that supports the kernel OMs.<br /> <br /> : '''X-server''' - This is the core X-windows server process that handles all request and responses to/from X-clients using the X-protocol. The XSELinux OM is intercepting these request/responses via XACE and enforcing policy decisions.<br /> <br /> : '''X-clients''' - These connect to the X-server are are typically windows managers such as Gnome, twm or KDE. The default for F-12 is the Gnome desktop manager. <br /> <br /> : '''Kernel-Space Services''' - These are discussed in the [[NB_LSM | Linux Security Module and SELinux]] section.<br /> <br /> <br /> {| border=&quot;1&quot;<br /> | '''Function Name'''<br /> | '''Minor Opcode'''<br /> | '''Parameters'''<br /> | '''Comments'''<br /> <br /> |-<br /> | SELinuxQueryVersion<br /> | &lt;center&gt;0&lt;/center&gt;<br /> | None<br /> | Returns the XSELinux version. F-12 returns 1.0<br /> <br /> |-<br /> | SELinuxSetDeviceCreateContext<br /> | &lt;center&gt;1&lt;/center&gt;<br /> | Context+Len<br /> | This is used by SELinux-aware applications for setting the context on device data.<br /> <br /> |-<br /> | SELinuxGetDeviceCreateContext<br /> | &lt;center&gt;2&lt;/center&gt;<br /> | None<br /> | Get the context set on the device data. This is for use by SELinux-aware applications.<br /> <br /> |-<br /> | SELinuxSetDeviceContext<br /> | &lt;center&gt;3&lt;/center&gt;<br /> | DeviceID + Context+Len<br /> | This is used by SELinux-aware applications for setting the context on selected &lt;tt&gt;x_device&lt;/tt&gt; object.<br /> <br /> |-<br /> | SELinuxGetDeviceContext<br /> | &lt;center&gt;4&lt;/center&gt;<br /> | DeviceID<br /> | Get context of the selected &lt;tt&gt;x_device&lt;/tt&gt; object.<br /> <br /> |-<br /> | SELinuxSetWindowCreateContext<br /> | &lt;center&gt;5&lt;/center&gt;<br /> | Context+Len<br /> | This is used by SELinux-aware applications for setting the context on windows data.<br /> <br /> |-<br /> | SELinuxGetWindowCreateContext<br /> | &lt;center&gt;6&lt;/center&gt;<br /> | None<br /> | Get the context set on the window data. This is for use by SELinux-aware applications.<br /> <br /> |-<br /> | SELinuxGetWindowContext<br /> | &lt;center&gt;7&lt;/center&gt;<br /> | WindowID<br /> | Get the process context that this window is running under (&lt;tt&gt;x_drawable&lt;/tt&gt; object ??)<br /> <br /> |-<br /> | SELinuxSetPropertyCreateContext<br /> | &lt;center&gt;8&lt;/center&gt;<br /> | Context+Len<br /> | This is used by SELinux-aware applications for setting the context on property data.<br /> <br /> |-<br /> | SELinuxGetPropertyCreateContext<br /> | &lt;center&gt;9&lt;/center&gt;<br /> | None<br /> | Get the context set on the property data. This is for use by SELinux-aware applications.<br /> <br /> |-<br /> | SELinuxSetPropertyUseContext<br /> | &lt;center&gt;10&lt;/center&gt;<br /> | Context+Len<br /> | This is for use by SELinux-aware applications for setting the context on the property object itself.<br /> <br /> |-<br /> | SELinuxGetPropertyUseContext<br /> | &lt;center&gt;11&lt;/center&gt;<br /> | None<br /> | Get the property object context. This is for use by SELinux-aware applications.<br /> <br /> |-<br /> | SELinuxGetPropertyContext<br /> | &lt;center&gt;12&lt;/center&gt;<br /> | WindowID + AtomID<br /> | Get context of the &lt;tt&gt;x_property&lt;/tt&gt; object.<br /> <br /> |-<br /> | SELinuxGetPropertyDataContext<br /> | &lt;center&gt;13&lt;/center&gt;<br /> | WindowID + AtomID<br /> | Get the context of the property data. This could be the policy default or that set by the &lt;tt&gt;SELinuxSetPropertyCreateContext&lt;/tt&gt; (9) function. <br /> <br /> |-<br /> | SELinuxListProperties<br /> | &lt;center&gt;14&lt;/center&gt;<br /> | WindowID<br /> | List the contexts of properties associated with the selected WindowID.<br /> <br /> |-<br /> | SELinuxSetSelectionCreateContext<br /> | &lt;center&gt;15&lt;/center&gt;<br /> | Context+Len<br /> | This is used by SELinux-aware applications for setting the context on selected data.<br /> <br /> |-<br /> | SELinuxGetSelectionCreateContext<br /> | &lt;center&gt;16&lt;/center&gt;<br /> | None<br /> | Get the context set on the selected data. This is for use by SELinux-aware applications.<br /> <br /> |-<br /> | SELinuxSetSelectionUseContext<br /> | &lt;center&gt;17&lt;/center&gt;<br /> | Context+Len<br /> | This is for use by SELinux-aware applications for setting the context on the selection object itself.<br /> <br /> |-<br /> | SELinuxGetSelectionUseContext<br /> | &lt;center&gt;18&lt;/center&gt;<br /> | None<br /> | Get the selection object context. This is for use by SELinux-aware applications.<br /> <br /> |-<br /> | SELinuxGetSelectionContext<br /> | &lt;center&gt;19&lt;/center&gt;<br /> | AtomID<br /> | Get context of the &lt;tt&gt;x_selection&lt;/tt&gt; object.<br /> <br /> |-<br /> | SELinuxGetSelectionDataContext<br /> | &lt;center&gt;20&lt;/center&gt;<br /> | AtomID<br /> | Get the context of the selected data. This could be the policy default or that set by the &lt;tt&gt;SELinuxSetSelectionCreateContext&lt;/tt&gt; (15) function. <br /> <br /> |-<br /> | SELinuxListSelections<br /> | &lt;center&gt;21&lt;/center&gt;<br /> | None<br /> | List the selection atoms for this display. The main difference in the listings is that when the &lt;tt&gt;PRIMARY&lt;/tt&gt; selection atom is polyinstantiated, multiple entries can returned. One has the context of the atom itself, and one entry for each process (or x-client) that has an active polyinstantiated entry, for example:<br /> <br /> Atom: PRIMARY - label defined in the&lt;tt&gt; x_contexts&lt;/tt&gt; file (this is also for non-poly listing):<br /> <br /> Object Context: system_u:object_r:primary_xselection_t<br /> Data Context: system_u:object_r:primary_xselection_t<br /> <br /> Atom: PRIMARY - Labels for client 1:<br /> <br /> Object Context: system_u:object_r:x_select_paste1_t<br /> Data Context: system_u:object_r:x_select_paste1_t<br /> <br /> Atom: PRIMARY - Labels for client 2:<br /> <br /> Object Context: system_u:object_r:x_select_paste2_t<br /> Data Context: system_u:object_r:x_select_paste2_t<br /> <br /> |-<br /> | SELinuxGetClientContext<br /> | &lt;center&gt;22&lt;/center&gt;<br /> | ResourceID<br /> | This function will return the process context any valid X resource ID is running under (or the &lt;tt&gt;x_client&lt;/tt&gt; object ?).<br /> <br /> |}<br /> ''Table 1: The XSELinux Functions - Supported by the object manager as X-protocol extensions. Note that some functions will return the default contexts, while others (2, 6, 9, 11, 16, 18) will not return a value unless one has been set the the appropriate function (1, 5, 8, 10, 15, 17) by an SELinux-aware application.''<br /> <br /> <br /> === Polyinstantiation ===<br /> The OM / XACE services support polyinstantiation of properties and selections as these form the InterClient Communication (ICC) that allows X-clients to communicate and exchange information. This allows properties and selections to be grouped into different membership areas so that one group does not know of the exsistance of the others. To implement polyinstantiation the &lt;tt&gt;poly_&lt;/tt&gt; keyword is required in the [[PolicyConfigurationFiles#contexts.2Fx_contexts_File | x_contexts file]] for the required selections and/or properties, there is then a corresponding [[TypeRules#type_member_Statement | type_member rule]] in the policy to enforce the separation.<br /> <br /> The Experimenting with X-Windows section in volume 2 has examples of using polyinstantiation for selections and then comparing the results to non-polyinstantiated cases.<br /> <br /> Note that the current Reference Policy (build 20091117) does not implement polyinstantiation, instead the MLS policy version uses the [[MLSStatements#mlsconstrain_Statement | mlsconstrain statement]] to limit the scope of these.<br /> <br /> <br /> == Configuration Information ==<br /> This section covers:<br /> <br /> * How to determine the OM X-extension opcode.<br /> * How to configure the OM in permissive mode.<br /> * How to disable the OM when using the Reference policy.<br /> * The &lt;tt&gt;x-contexts&lt;/tt&gt; configuration file.<br /> * The OMs &lt;tt&gt;SELinuxGet/Set..&lt;/tt&gt; functions (shown in Table 1).<br /> <br /> === Determine OM X-extension Opcode ===<br /> The object manager is treated as an X-server extension and its major opcode can be queried using Xlib &lt;tt&gt;XQueryExtension&lt;/tt&gt; function as follows:<br /> &lt;pre&gt;<br /> // Get the SELinux Extension opcode<br /> if (!XQueryExtension (dpy, &quot;SELinux&quot;, &amp;opcode, &amp;event, &amp;error)) {<br /> perror (&quot;XSELinux extension not available&quot;);<br /> exit (1);<br /> }<br /> else<br /> printf (&quot;XQueryExtension for XSELinux Extension - Opcode: %d <br /> Events: %d Error: %d \n&quot;, opcode, event, error);<br /> // Have XSELinux Object Manager<br /> &lt;/pre&gt;<br /> <br /> === Configure OM in Permissive Mode ===<br /> If the X-server object manager needs to be run in permissive mode the following entry can be added to the &lt;tt&gt;xorg.conf&lt;/tt&gt; file (normally in &lt;tt&gt;/etc&lt;/tt&gt;):<br /> &lt;pre&gt;<br /> Section &quot;Module&quot;<br /> SubSection &quot;extmod&quot;<br /> Option &quot;SELinux mode permissive&quot;<br /> EndSubSection<br /> EndSection<br /> &lt;pre&gt;<br /> <br /> === Disable the OM ===<br /> The Reference Policy has a boolean that can be used to disable the x-server object manager if is not required by:<br /> &lt;pre&gt;<br /> setsebool -P xserver_object_manager false <br /> &lt;/pre&gt;<br /> <br /> === The x_contexts File ===<br /> The &lt;tt&gt;x_contexts&lt;/tt&gt; file contains labels and initial context information that is required by the OM to initialise the service and then to label objects as they are created. The policy will also need to be aware of the context information being used as it will use this to enforce policy or transition to a new context. A typical entry is as follows:<br /> &lt;pre&gt;<br /> # object_type object_name context<br /> selection PRIMARY system_u:object_r:clipboard_xselection_t<br /> &lt;/pre&gt;<br /> or for polyinstantiation support:<br /> &lt;pre&gt;<br /> # object_type object_name context<br /> poly_selection PRIMARY system_u:object_r:clipboard_xselection_t<br /> &lt;/pre&gt;<br /> <br /> The &lt;tt&gt;object_name&lt;/tt&gt; can contain '&lt;tt&gt;*&lt;/tt&gt;' for 'any' or '&lt;tt&gt;?&lt;/tt&gt;' for 'substitute'.<br /> <br /> The OM uses the &lt;tt&gt;selabel&lt;/tt&gt; functions (such as &lt;tt&gt;selabel_lookup&lt;/tt&gt;) that are a part of &lt;tt&gt;libselinux&lt;/tt&gt; (see the [[LibselinuxAPISummary | libselinux API]] section) to fetch the relevant information from the&lt;tt&gt; x_contexts&lt;/tt&gt; file.<br /> <br /> The valid &lt;tt&gt;object_type&lt;/tt&gt; entries are &lt;tt&gt;client&lt;/tt&gt;, &lt;tt&gt;property&lt;/tt&gt;, &lt;tt&gt;poly_property&lt;/tt&gt;, &lt;tt&gt;extension&lt;/tt&gt;, &lt;tt&gt;selection&lt;/tt&gt;, &lt;tt&gt;poly_selection&lt;/tt&gt; and &lt;tt&gt;events&lt;/tt&gt;.<br /> <br /> The &lt;tt&gt;object_name&lt;/tt&gt; entries can be any valid X-server resource name that is defined in the X-server source code and can typically be found in the &lt;tt&gt;protocol.txt&lt;/tt&gt; and &lt;tt&gt;BuiltInAtoms&lt;/tt&gt; source files (in the &lt;tt&gt;dix&lt;/tt&gt; directory of the &lt;tt&gt;xorg-server&lt;/tt&gt; source package), or user generated via the Xlib libraries (e.g. &lt;tt&gt;XInternAtom&lt;/tt&gt;). Note that if an &lt;tt&gt;object_name&lt;/tt&gt; has both poly and non-poly entries in the file, the non-poly entry takes precedence (i.e. the poly entry is ignored by the OM).<br /> <br /> Note that for systems using the Reference Policy all X-clients connecting remotely will be allocated a security context from the &lt;tt&gt;x_contexts&lt;/tt&gt; file of:<br /> &lt;pre&gt;<br /> # object_type object_name context<br /> client * system_u:object_r:remote_t<br /> &lt;/pre&gt;<br /> [[Experimenters_Corner | Experimenters Corner]] section has examples of adding additional entries to the &lt;tt&gt;x_contexts&lt;/tt&gt; file.<br /> <br /> A full description of the &lt;tt&gt;x_contexts&lt;/tt&gt; file format is given in the [[PolicyConfigurationFiles#contexts.2Fx_contexts_File | contexts/x_contexts File]] section.<br /> <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_VM NB VM 2010-09-13T21:05:34Z <p>Jaxelson: </p> <hr /> <div>= SELinux Virtual Machine Support =<br /> SELinux support is available in the KVM/QEMU and Xen virtual machine (VM) technologies&lt;ref name=&quot;ftn29&quot;&gt;KVM (Kernel-based Virtual Machine) and Xen are classed as 'bare metal' hypervisors and they rely on other services to manage the overall VM environment. QEMU (Quick Emulator) is an emulator that emulates the BIOS and I/O device functionality and can be used standalone or with KVM and Xen.&lt;/ref&gt; that are discussed in the sections that follow, however the package documentation should be read for how these products actually work and how they are configured. <br /> <br /> Currently the main SELinux support for virtualisation is via &lt;tt&gt;libvirt&lt;/tt&gt; that is an open-source virtualisation API that can be used to dynamically load guest VMs on behalf of the virtualisation product. Security extensions were added as a part of the [http://selinuxproject.org/page/SVirt Svirt] project and the SELinux implementation for the KVM/QEMU package (&lt;tt&gt;qemu-kvm&lt;/tt&gt; and &lt;tt&gt;libvirt&lt;/tt&gt; rpms) is discussed using some examples. The Xen product has Flask/TE services that can be builtas an optional service, although it can also use the security enhanced &lt;tt&gt;libvirt&lt;/tt&gt; services as well.<br /> <br /> The sections that follow give an introduction to KVM/QEMU and then the &lt;tt&gt;libvirt&lt;/tt&gt; support with some examples that make use of the Virtual Machine Manager (&lt;tt&gt;virt-manager&lt;/tt&gt; rpm) to configure VMs, an overview of the Xen implementation then follows.<br /> <br /> == KVM / QEMU Support ==<br /> KVM is a kernel loadable module that uses the Linux kernel as a hypervisorand makes use of a modified QEMU emulator to support the hardware I/O emulation. The &quot;[http://www.redhat.com/f/pdf/rhev/DOC-KVM.pdf Kernel-based Virtual Machine]&quot; document gives a good overview of how KVM and QEMU are implemented. It also provides an introduction the virtualisation in general. <br /> <br /> The SELinux support for VMs is implemented by the &lt;tt&gt;libvirt&lt;/tt&gt; sub-system that is used to manage the VM images using a Virtual Machine Manager, and as KVM is based on Linux it has SELinux support by default. There are also Reference Policy modules to support the overall infrastructure (KVM support is in various kernel and system modules with a &lt;tt&gt;virt&lt;/tt&gt; module supporting the &lt;tt&gt;libvirt&lt;/tt&gt; services). The [http://taiga.selinuxproject.org/~rhaines/diagrams/20-KVM.png KVM Environment] diagram shows a high level overview with two VMs running in their own domains. The libsvirt Support section below shows how to configure these and their VM image files.<br /> <br /> <br /> == libvirt Support ==<br /> The Svirt project added security hooks into the &lt;tt&gt;libvirt&lt;/tt&gt; library that is used by the &lt;tt&gt;libvirtd&lt;/tt&gt; daemon. This daemon is used by a number of VM products (such as KVM/QEMU and Xen) to start their VMs running as guest operating systems. <br /> <br /> The security hooks can be utilised by any security mechanism by the VM supplier providing a product specific libvirt [http://libvirt.org/drvqemu.html driver] that loads and manages the images. The SELinux implementation (when SELinux is enabled on the host system) supports four methods of labeling VM images, processes and their resources with support from the Reference Policy &lt;tt&gt;modules/services/virt.*&lt;/tt&gt; loadable module&lt;ref name=&quot;ftn30&quot;&gt;The various images would have been labeled by the &lt;tt&gt;virt&lt;/tt&gt; module installation process (see the &lt;tt&gt;virt.fc&lt;/tt&gt; module file or the policy &lt;tt&gt;file_contexts&lt;/tt&gt; file &lt;tt&gt;libvirt&lt;/tt&gt; entries). If not, then need to ensure it is relabeled by the most appropriate SELinux tool.&lt;/ref&gt;. To support this labeling, &lt;tt&gt;libvirt&lt;/tt&gt; requires an MCS or MLS enabled policy as the &lt;tt&gt;level&lt;/tt&gt; entry of the security context is used (&lt;tt&gt;user:role:type:level&lt;/tt&gt;) .<br /> <br /> === Default Mode ===<br /> The default mode is where each VM is run under its own dynamically configured domain and image file therefore isolating the VMs from each other (i.e. every time the system is rebooted a different and unique MCS label will be generated to confine each VM to its own domain). This mode is implemented as follows:<br /> <br /> * An initial context for the process is obtained from the &lt;tt&gt;/etc/selinux/&lt;policy_name&gt;/contexts/virtual_domain_context&lt;/tt&gt; file (the default is &lt;tt&gt;system_u:system_r:svirt_t:s0&lt;/tt&gt;).<br /> * An initial context for the image file label is obtained from the &lt;tt&gt;/etc/selinux/&lt;policy_name&gt;/contexts/virtual_image_context&lt;/tt&gt; file. The default is &lt;tt&gt;system_u:system_r:svirt_image_t:s0&lt;/tt&gt; that allows read/write of image files.<br /> * When the image is used to start the VM a random MCS &lt;tt&gt;level&lt;/tt&gt; is generated and added to the process context and the image object context. The process and image objects are then transitioned to the context by the&lt;tt&gt; libselinux&lt;/tt&gt; API calls &lt;tt&gt;setfilecon&lt;/tt&gt; and &lt;tt&gt;setexeccon&lt;/tt&gt; respectively (see &lt;tt&gt;security_selinux.c&lt;/tt&gt; in the &lt;tt&gt;libvirt &lt;/tt&gt;source). The following example shows two VM sessions having different label as they were launched during the same boot session:<br /> <br /> {| border=&quot;1&quot;<br /> | '''VM'''<br /> | '''Object'''<br /> | '''Dynamically assigned security context '''<br /> <br /> |-<br /> | VM1<br /> | Process<br /> | &lt;tt&gt;system_u:system_r:svirt_t:s0:c585,c813&lt;/tt&gt;<br /> <br /> |-<br /> | VM1<br /> | File<br /> | &lt;tt&gt;system_u:system_r:svirt_image_t:s0:c585,c813&lt;/tt&gt;<br /> <br /> |-<br /> | VM2<br /> | Process<br /> | &lt;tt&gt;system_u:system_r:svirt_t:s0:c535,c601&lt;/tt&gt;<br /> <br /> |-<br /> | VM2<br /> | File<br /> | &lt;tt&gt;system_u:system_r:svirt_image_t:s0:c535,c601&lt;/tt&gt;<br /> <br /> |}<br /> <br /> <br /> The running image &lt;tt&gt;ls -Z&lt;/tt&gt; and &lt;tt&gt;ps -eZ&lt;/tt&gt; are as follows and for completeness an &lt;tt&gt;ls -Z&lt;/tt&gt; is shown when both VMs have been stopped:<br /> &lt;pre&gt;<br /> # Both VMs running:<br /> ls -Z /var/lib/libvirt/images<br /> system_u:object_r:svirt_image_t:s0:c585,c813 Test_VM1.img<br /> system_u:object_r:svirt_image_t:s0:c535,c601 Test_VM2.img<br /> <br /> ps -eZ | grep qemu<br /> system_u:system_r:svirt_t:s0:c585,c813 8707 ? 00:00:44 qemu<br /> system_u:system_r:svirt_t:s0:c1022,c535 8796 ? 00:00:37 qemu<br /> <br /> # Both VMs stopped (note that the categories are now missing AND the type has changed from svirt_image_t to virt_image_t):<br /> ls -Z /var/lib/libvirt/images<br /> system_u:object_r:virt_image_t:s0 Test_VM1.img<br /> system_u:object_r:virt_image_t:s0 Test_VM2.img<br /> &lt;/pre&gt;<br /> <br /> <br /> === Shared Image Mode ===<br /> If the disk image has been set to shared, then a dynamically allocated &lt;tt&gt;level&lt;/tt&gt; will be generated for each VM process instance, however there will be a single instance of the disk image. <br /> <br /> The Virtual Machine Manager can be used to set the image as shareable by checking the &lt;tt&gt;Shareable&lt;/tt&gt; box as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/21-Shareable.png Setting the image as Shareable or Readonly] screen.<br /> <br /> This will set the image (&lt;tt&gt;Test_VM1.xml&lt;/tt&gt;) resource XML configuration file located in the &lt;tt&gt;/etc/libvirt/qemu&lt;/tt&gt; directory &lt;tt&gt;&lt;disk&gt;&lt;/tt&gt; contents as follows:<br /> &lt;pre&gt;<br /> # /etc/libvirt/qemu/Test_VM1.xml:<br /> &lt;disk type='file' device='disk'&gt;<br /> &lt;driver name='qemu' type='raw'/&gt;<br /> &lt;source file='/var/lib/libvirt/images/Test_VM1.img'/&gt;<br /> &lt;target dev='hda' bus='ide'/&gt;<br /> &lt;shareable/&gt;<br /> &lt;/disk&gt;<br /> &lt;/pre&gt;<br /> <br /> As the two VMs will share the same image, the &lt;tt&gt;Test_VM1&lt;/tt&gt; image needs to be cloned and its XML file &lt;tt&gt;&lt;disk&gt;&lt;/tt&gt; contents are as follows (note that it has the same shared image source file name):<br /> &lt;pre&gt;<br /> # /etc/libvirt/qemu/Test_VM1-clone.xml:<br /> &lt;disk type='file' device='disk'&gt;<br /> &lt;driver name='qemu' type='raw'/&gt;<br /> &lt;source file='/var/lib/libvirt/images/Test_VM1.img'/&gt;<br /> &lt;target dev='hda' bus='ide'/&gt;<br /> &lt;shareable/&gt;<br /> &lt;/disk&gt;<br /> &lt;/pre&gt;<br /> <br /> Now that the image has been configured as shareable, the following initialisation process will take place:<br /> <br /> * An initial context for the process is obtained from the &lt;tt&gt;/etc/selinux/&lt;policy_name&gt;/contexts/virtual_domain_context&lt;/tt&gt; file (the default is &lt;tt&gt;system_u:system_r:svirt_t:s0&lt;/tt&gt;).<br /> * An initial context for the image file label is obtained from the &lt;tt&gt;/etc/selinux/&lt;policy_name&gt;/contexts/virtual_image_context&lt;/tt&gt; file. The default is &lt;tt&gt;system_u:system_r:svirt_image_t:s0&lt;/tt&gt; that allows read/write of image files.<br /> * When the image is used to start the VM a random MCS level is generated and added to the process context (but not the image object). The process and image objects are then transitioned to the appropriate context by the&lt;tt&gt; libselinux&lt;/tt&gt; API calls &lt;tt&gt;setfilecon&lt;/tt&gt; and &lt;tt&gt;setexeccon&lt;/tt&gt; respectively. The following example shows each VM having the same file label but different process labels:<br /> <br /> {| border=&quot;1&quot;<br /> | '''VM'''<br /> | '''Object'''<br /> | '''Default security context '''<br /> <br /> |-<br /> | VM1<br /> | Process<br /> | &lt;tt&gt;system_u:system_r:svirt_t:s0:c231,c245&lt;/tt&gt;<br /> <br /> |-<br /> | VM1<br /> | File<br /> | &lt;tt&gt;system_u:system_r:svirt_image_t:s0&lt;/tt&gt;<br /> <br /> |-<br /> | VM2<br /> | Process<br /> | &lt;tt&gt;system_u:system_r:svirt_t:s0:c695,c894&lt;/tt&gt;<br /> <br /> |-<br /> | VM1<br /> | File<br /> | &lt;tt&gt;system_u:system_r:svirt_image_t:s0&lt;/tt&gt;<br /> <br /> |}<br /> <br /> <br /> The running image &lt;tt&gt;ls -Z&lt;/tt&gt; and &lt;tt&gt;ps -eZ&lt;/tt&gt; are as follows and for completeness an &lt;tt&gt;ls -Z&lt;/tt&gt; is shown when both VMs have been stopped:<br /> &lt;pre&gt;<br /> # Both VMs running and sharing same image as Test_VM1 was cloned:<br /> ls -Z /var/lib/libvirt/images<br /> system_u:object_r:svirt_image_t:s0 Test_VM1.img<br /> <br /> ps -eZ | grep qemu<br /> system_u:system_r:svirt_t:s0:c231,c254 6748 ? 00:01:17 qemu<br /> system_u:system_r:svirt_t:s0:c695,c894 7664 ? 00:00:03 qemu<br /> <br /> # Both VMs stopped (note that the type has remained as svirt_image_t)<br /> ls -Z /var/lib/libvirt/images<br /> system_u:object_r:svirt_image_t:s0 Test_VM1.img<br /> &lt;/pre&gt;<br /> <br /> === Readonly Image Mode ===<br /> The &lt;tt&gt;readonly&lt;/tt&gt; configuration sequence is similar to the &lt;tt&gt;shared&lt;/tt&gt; option shown above with a dynamically allocated level generated for each VM process instance and the disk image can be shared. The major differences are that the disk image will be read only by setting the image context to &lt;tt&gt;virt_content_t&lt;/tt&gt; (that enforces read only - see the &lt;tt&gt;virt.if&lt;/tt&gt; module interface file - &lt;tt&gt;read_blk_files_pattern&lt;/tt&gt;) instead of &lt;tt&gt;svirt_image_t&lt;/tt&gt; (that allows read/write - &lt;tt&gt;rw_blk_files_pattern&lt;/tt&gt;). <br /> <br /> The Virtual Machine Manager can be used to set the image as read only by checking the &lt;tt&gt;Readonly&lt;/tt&gt; box as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/21-Shareable.png Setting the image as Shareable or Readonly] screen. This will set the image (&lt;tt&gt;Test_VM1.xml&lt;/tt&gt;) resource XML configuration file located in the &lt;tt&gt;/etc/libvirt/qemu&lt;/tt&gt; directory &lt;tt&gt;&lt;disk&gt;&lt;/tt&gt; contents as follows:<br /> &lt;pre&gt;<br /> # /etc/libvirt/qemu/Test_VM1.xml:<br /> &lt;disk type='file' device='disk'&gt;<br /> &lt;driver name='qemu' type='raw'/&gt;<br /> &lt;source file='/var/lib/libvirt/images/Test_VM1.img'/&gt;<br /> &lt;target dev='hda' bus='ide'/&gt;<br /> &lt;readonly/&gt;<br /> &lt;/disk&gt;<br /> &lt;/pre&gt;<br /> <br /> As the two VMs will share the same image the &lt;tt&gt;Test_VM1&lt;/tt&gt; image needs to be cloned and its XML file &lt;tt&gt;&lt;disk&gt;&lt;/tt&gt; contents will be as follows:<br /> &lt;pre&gt;<br /> # /etc/libvirt/qemu/Test_VM1-clone.xml:<br /> &lt;disk type='file' device='disk'&gt;<br /> &lt;driver name='qemu' type='raw'/&gt;<br /> &lt;source file='/var/lib/libvirt/images/Test_VM1.img'/&gt;<br /> &lt;target dev='hda' bus='ide'/&gt;<br /> &lt;readonly/&gt;<br /> &lt;/disk&gt;<br /> &lt;/pre&gt;<br /> <br /> Now that the image has been configured as &lt;tt&gt;readonly&lt;/tt&gt;, the following initialisation process will take place:<br /> <br /> * An initial context for the process is obtained from the &lt;tt&gt;/etc/selinux/&lt;policy_name&gt;/contexts/virtual_domain_context&lt;/tt&gt; file (the default is &lt;tt&gt;system_u:system_r:svirt_t:s0&lt;/tt&gt;).<br /> * An initial context for the image file label is obtained from the &lt;tt&gt;/etc/selinux/&lt;policy_name&gt;/contexts/virtual_image_context&lt;/tt&gt; file. The default for read only images is &lt;tt&gt;system_u:system_r:virt_content_t:s0&lt;/tt&gt; as discussed above. <br /> * When the image is used to start the VM a random MCS level is generated and added to the process context (but not the image object). The process and image objects are then transitioned to the appropriate context by the&lt;tt&gt; libselinux&lt;/tt&gt; API calls &lt;tt&gt;setfilecon&lt;/tt&gt; and &lt;tt&gt;setexeccon&lt;/tt&gt; respectively. The following example shows each VM having the same file label but different process labels:<br /> <br /> <br /> {| border=&quot;1&quot;<br /> | '''VM'''<br /> | '''Object'''<br /> | '''Default security context '''<br /> <br /> |-<br /> | VM1<br /> | Process<br /> | &lt;tt&gt;system_u:system_r:svirt_t:s0:c103,c950&lt;/tt&gt;<br /> <br /> |-<br /> | VM1<br /> | File<br /> | &lt;tt&gt;system_u:system_r:virt_content_t:s0&lt;/tt&gt;<br /> <br /> |-<br /> | VM2<br /> | Process<br /> | &lt;tt&gt;system_u:system_r:svirt_t:s0:c312,c820&lt;/tt&gt;<br /> <br /> |-<br /> | VM1<br /> | File<br /> | &lt;tt&gt;system_u:system_r:virt_content_t:s0&lt;/tt&gt;<br /> <br /> |}<br /> <br /> <br /> The running image &lt;tt&gt;ls -Z&lt;/tt&gt; and &lt;tt&gt;ps -eZ&lt;/tt&gt; are as follows and for completeness an &lt;tt&gt;ls -Z&lt;/tt&gt; is shown when both VMs have been stopped:<br /> &lt;pre&gt;<br /> # Both VMs running and sharing same image as Test_VM1 was cloned:<br /> ls -Z /var/lib/libvirt/images<br /> system_u:object_r:virt_content_t:s0 Test_VM1.img<br /> <br /> ps -eZ | grep qemu<br /> system_u:system_r:svirt_t:s0:c103,c950 8756 ? 00:01:08 qemu<br /> system_u:system_r:svirt_t:s0:c312,c820 9246 ? 00:01:03 qemu<br /> <br /> # Both VMs stopped (note that the type remained as virt_content_t),<br /> # however if the disk type was reset to &lt;shared/&gt;, then it would be<br /> # reset back to virt_image_t:s0 once the VM was running again.<br /> ls -Z /var/lib/libvirt/images<br /> system_u:object_r:virt_content_t:s0 Test_VM1.img<br /> &lt;/pre&gt;<br /> <br /> === Static Labeling ===<br /> It is possible to set static labels on each image file, however a consequence of this is that the image cannot be cloned therefore an image for each VM will be required. This is the method used to configure VMs on MLS systems as there is a known label that would define the security level. With this method it is also possible to configure two or more VMs with the same security context so that they can share resources.<br /> <br /> If using the Virtual Machine Manager GUI, then by default it will start each VM running as they are built, therefore they need to be stopped and then configured for static labels and the image file will also need to be relabeled. An example VM configuration follows where the VM has been created as &lt;tt&gt;Static_VM1&lt;/tt&gt; using the F-12 &lt;tt&gt;targeted&lt;/tt&gt; policy in enforcing mode (just so all errors are flagged during the build):<br /> <br /> * Once the VM has been built, it will need to be stopped from the &lt;tt&gt;Static_VM1 Virtual Machine&lt;/tt&gt; screen. Display the &lt;tt&gt;Security&lt;/tt&gt; menu and select &lt;tt&gt;selinux&lt;/tt&gt; as the &lt;tt&gt;Model&lt;/tt&gt; and check the &lt;tt&gt;Static&lt;/tt&gt; check box. The required security context can then be set - for this example &lt;tt&gt;svirt_t&lt;/tt&gt; has been chosen as it is a valid context as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/22-Static.png Static Configuration] screen.<br /> <br /> This context will be written to the &lt;tt&gt;Static_VM1.xml&lt;/tt&gt; file in the &lt;tt&gt;/etc/libvirt/qemu&lt;/tt&gt; directory as follows:<br /> &lt;pre&gt;<br /> &lt;seclabel type='static' model='selinux'&gt;<br /> &lt;label&gt;system_u:system_r:svirt_t:s0:c1022.c1023&lt;/label&gt;<br /> &lt;/seclabel&gt;<br /> &lt;/pre&gt;<br /> <br /> * If the VM is now started an error will be shown as follows as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/23-image-start-error.png Image Start Error] screen.<br /> <br /> : This is because the image file label is incorrect as by default it is labeled &lt;tt&gt;virt_image_t&lt;/tt&gt; when the VM image is built (and &lt;tt&gt;svirt_t&lt;/tt&gt; does not have read/write permission for this label):<br /> &lt;pre&gt;<br /> # The default label of the image at build time:<br /> system_u:object_r:virt_image_t:s0 Static_VM1.img<br /> &lt;/pre&gt;<br /> <br /> There are a number of ways to fix this, such as adding an allow rule or changing the image file label. In this example the image file label will be changed using &lt;tt&gt;chcon&lt;/tt&gt; as follows:<br /> &lt;pre&gt;<br /> # This command is executed from /var/lib/libvirt/images<br /> #<br /> # This sets the correct type:<br /> chcon -t svirt_image_t Static_VM1.img<br /> &lt;/pre&gt;<br /> <br /> If required, the image can also be relabeled so that the &lt;tt&gt;[level]&lt;/tt&gt; is the same as the process using &lt;tt&gt;chcon&lt;/tt&gt; as follows:<br /> &lt;pre&gt;<br /> # This command is executed from /var/lib/libvirt/images<br /> #<br /> # Set the MCS label to match the process (optional step):<br /> chcon -l s0:c1022,c1023 Static_VM1.img<br /> &lt;/pre&gt;<br /> <br /> * Now that the image has been relabeled, the VM can now be started. <br /> <br /> The following example shows two VMs (the &lt;tt&gt;unconfined_t&lt;/tt&gt; configuration is discussed below):<br /> <br /> <br /> {| border=&quot;1&quot;<br /> | '''VM'''<br /> | '''Object'''<br /> | '''Static security context '''<br /> <br /> |-<br /> | VM1<br /> | Process<br /> | &lt;tt&gt;system_u:system_r:svirt_t:s0:c1022,c1023&lt;/tt&gt;<br /> <br /> |-<br /> | VM1<br /> | File<br /> | &lt;tt&gt;system_u:system_r:svirt_image_t:s0:c1022,c1023&lt;/tt&gt;<br /> <br /> |-<br /> | VM2<br /> | Process<br /> | &lt;tt&gt;system_u:system_r:unconfined_t:s0:c11,c22&lt;/tt&gt;<br /> <br /> |-<br /> | VM2<br /> | File<br /> | &lt;tt&gt;system_u:system_r:virt_image_t:s0&lt;/tt&gt;<br /> <br /> |}<br /> <br /> <br /> The running image &lt;tt&gt;ls -Z&lt;/tt&gt; and &lt;tt&gt;ps -eZ&lt;/tt&gt; are as follows, and for completeness an &lt;tt&gt;ls -Z&lt;/tt&gt; is shown when both VMs have been stopped:<br /> &lt;pre&gt;<br /> # Both VMs running:<br /> ls -Z /var/lib/libvirt/images<br /> system_u:object_r:svirt_image_t:s0:c1022,c1023 Static_VM1.img<br /> system_u:object_r:virt_image_t:s0:c11,c22 Static_VM2.img<br /> <br /> ps -eZ | grep qemu<br /> system_u:system_r:svirt_t:s0:c585,c813 6707 ? 00:00:45 qemu<br /> system_u:system_r:unconfined_t:s0:c11,c22 6796 ? 00:00:26 qemu<br /> <br /> # Both VMs stopped (note that Static_VM1.img was relabeled svirt_image_t to enable it to run, however Static_VM2.img is still labeled<br /> # virt_image_t and runs okay. This is because the process is run as unconfined_t that is allowed to use virt_image_t):<br /> <br /> system_u:object_r:svirt_image_t:s0:c1022,c1023 Static_VM1.img<br /> system_u:object_r:virt_image_t:s0 Static_VM2.img<br /> &lt;/pre&gt;<br /> <br /> ==== Configuring the unconfined_t image ====<br /> The objective of this section is to configure a VM domain that the targeted policy does not currently support. The domain chosen is &lt;tt&gt;unconfined_t&lt;/tt&gt; as that is the default for general users and requires a minimal additional policy module. The steps required to enable the VM are: <br /> <br /> * Using the Virtual Machine Manager, generate a VM (this has been called &lt;tt&gt;Static_VM2&lt;/tt&gt;).<br /> * Stop the VM and set a static context of &lt;tt&gt;system_u:system_r:unconfined_t:s0:c11,c22&lt;/tt&gt;. This context will be written to the &lt;tt&gt;Static_VM2.xml&lt;/tt&gt; file in the &lt;tt&gt;/etc/libvirt/qemu&lt;/tt&gt; directory as follows:<br /> &lt;pre&gt;<br /> &lt;seclabel type='static' model='selinux'&gt;<br /> &lt;label&gt;system_u:system_r:unconfined_t:s0:c11,c22&lt;/label&gt;<br /> &lt;/seclabel&gt;<br /> &lt;/pre&gt;<br /> <br /> * Before attempting to start the VM clear the audit log first so that a module can be generated with &lt;tt&gt;audit2allow&lt;/tt&gt; to allow the VM to start:<br /> &lt;pre&gt;<br /> &gt; /var/log/audit/audit.log<br /> &lt;/pre&gt;<br /> <br /> * Now if the VM is started the following [http://taiga.selinuxproject.org/~rhaines/diagrams/24-image-execution-error.png Image Execution Error] will be shown on the screen.<br /> <br /> This is because the &lt;tt&gt;libvirt&lt;/tt&gt; daemon does not have permission to transition the VM process to the &lt;tt&gt;unconfined_t&lt;/tt&gt; domain. The audit log AVC entry would be:<br /> &lt;pre&gt;<br /> type=AVC msg=audit(1271080140.988:30): avc: denied { transition } for pid=2000 comm=&quot;libvirtd&quot; path=&quot;/usr/bin/qemu&quot; dev=dm-0 ino=71778 scontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_t:s0:c11,c22 tclass=process<br /> <br /> type=SYSCALL msg=audit(1271080140.988:30): arch=40000003 syscall=11 success=no exit=-13 a0=b425c470 a1=b427f610 a2=b42a4a68 a3=0 items=0 ppid=1999 pid=2000 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm=&quot;libvirtd&quot; exe=&quot;/usr/sbin/libvirtd&quot; subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null)<br /> &lt;/pre&gt;<br /> <br /> * To generate a loadable module that will allow the transition use the following commands:<br /> &lt;pre&gt;<br /> # These cmds will generate an unconfinedvm.pp module package:<br /> <br /> cat /var/log/audit/audit.log | audit2allow -M unconfinedvm &gt; unconfinedvm.te<br /> <br /> # Once the package has been generated, it needs to be activated:<br /> semodule -i unconfinedvm.pp<br /> &lt;/pre&gt;<br /> <br /> * Once the module has been loaded and the policy rebuilt, the VM can now be started. For reference the module file generated by &lt;tt&gt;audit2allow&lt;/tt&gt; consists of the following:<br /> &lt;pre&gt;<br /> module unconfinedvm 1.0;<br /> <br /> require {<br /> type unconfined_t;<br /> type virtd_t;<br /> class process transition;<br /> }<br /> <br /> #============= virtd_t ==============<br /> allow virtd_t unconfined_t:process transition;<br /> &lt;/pre&gt;<br /> <br /> <br /> == Xen Support ==<br /> This is not supported by SELinux in the usual way as it is built into the actual Xen software as a 'Flask/TE' extension&lt;ref name=&quot;ftn31&quot;&gt;This is a version of the SELinux security server, avc etc. that has been specifically ported for the Xen implementation.&lt;/ref&gt; for the XSM (Xen Security Module). Also the Xen implementation has its own built-in policy (&lt;tt&gt;xen.te&lt;/tt&gt;) and supporting definitions for access vectors, security classes and initial SIDs for the policy. These Flask/TE components run in Domain 0 as part of the domain management and control supporting the Virtual Machine Monitor (VMM) as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/25-xen.png Xen Hypervisor] diagram. <br /> <br /> The &quot;[http://www.xen.org/files/Marketing/HowDoesXenWork.pdf How Does Xen Work]&quot; document describes the basic operation of Xen, the &quot;[http://www.xen.org/files/xensummit_4/xsm-summit-041707_Coker.pdf Xen Security Modules]&quot; document describes the XSM/Flask implementation, and the &lt;tt&gt;xsm-flask.txt&lt;/tt&gt; file in the Xen source package describes how SELinux and its supporting policy is implemented.<br /> <br /> However (just to confuse the issue), there is another Xen policy module (also called &lt;tt&gt;xen.te&lt;/tt&gt;) in the Reference Policy to support the management of images etc. via the Xen console.<br /> <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_TE NB TE 2010-09-13T21:05:25Z <p>Jaxelson: </p> <hr /> <div>''See Also: [[TypeEnforcement]]''<br /> = Type Enforcement (TE) =<br /> SELinux makes use of a specific style of type enforcement&lt;ref name=&quot;ftn5&quot;&gt;&lt;sup&gt;There are various &quot;type enforcement&quot; technologies. &lt;/sup&gt;&lt;/ref&gt; (TE) to enforce mandatory access control. For SELinux it means that all [[NB_Subjects | subjects]] and [[NB_Objects | objects]] have a type identifier associated to them that can then be used to enforce rules laid down in a policy. <br /> <br /> The SELinux type identifier is a simple variable-length string that is defined in the policy and then associated to a [[NB_SC | security context]]. It is also used in the majority of [[PolicyLanguage | SELinux language statements and rules]] used to build a policy that will, when loaded into the security server, enforce the policy.<br /> <br /> Because the type identifier (or just &quot;type&quot;) is associated to all subjects and objects, it can sometimes be difficult to distinguish what the type is actually associated with (it's not helped by the fact that by convention, type identifiers all end in &quot;&lt;tt&gt;_t&lt;/tt&gt;&quot;). In the end it comes down to understanding how they are allocated in the policy itself and how they are used by SELinux services. <br /> <br /> Basically if the type identifier is used to reference a subject it is referring to a GNU / Linux process or domain (i.e. domain type). If the type identifier is used to reference an object then it is specifying its object type (i.e. file type).<br /> <br /> While SELinux refers to a subject as being an active process that is associated to a domain type, the scope of an SELinux type enforcement domain can vary widely. For example in the simple policy built in the Building a Basic Policy section of volume 2, all the processes on the system run in the unconfined_t domain, therefore every process is &quot;of type &lt;tt&gt;unconfined_t&lt;/tt&gt;&quot; (that means it can do whatever it likes within the limits of the standard Linux DAC policy).<br /> <br /> It is only when additional policies are implemented in the simple policy (via loadable modules), that areas start to be confined, for example an external gateway is run in its own isolated domain (&lt;tt&gt;ext_gateway_t&lt;/tt&gt;) that cannot be &quot;interfered&quot; with by any of the &lt;tt&gt;unconfined_t&lt;/tt&gt; processes (except to run or transition the gateway process into its own domain). This scenario is similar to the &quot;targeted&quot; policy delivered as standard in Red Hat Fedora where the majority of user space processes run under the unconfined_t domain (although don't think they are equivalent as the policies supplied with the Reference Policy have areas isolated by various domains and has evolved over years of work).<br /> <br /> == Constraints ==<br /> Within a TE environment the way that subjects are allowed to access an object is via an &lt;tt&gt;allow&lt;/tt&gt; rule, for example:<br /> &lt;pre&gt;<br /> allow unconfined_t ext_gateway_t : process transition;<br /> &lt;/pre&gt;<br /> <br /> This is explained in more detail later, however it states that a process running in the &lt;tt&gt;unconfined_t&lt;/tt&gt; domain has permission to transition a process to the &lt;tt&gt;ext_gateway_t&lt;/tt&gt; domain. However it could be that the policy writer wants to constrain this further and state that this can only happen if the role of the source domain is the same as the role of the target domain. To achieve this a constraint can be imposed using a &lt;tt&gt;constrain&lt;/tt&gt; statement:<br /> &lt;pre&gt;<br /> constrain process transition ( r1 == r2 );<br /> &lt;/pre&gt;<br /> <br /> This states that a process transition can only occur if the source role is the same as the target role, therefore a constraint is a condition that must be satisfied in order for one or more permissions to be granted (i.e. a constraint imposes additional restrictions on TE rules). An example of this can be found in the [[ConstraintStatements | Constraint Statements]] section.<br /> <br /> There are a number of different constraint statements within the policy language to support areas such as MLS (see the [[ConstraintStatements | Constraint Statements]] and [[MLSStatements | MLS Statements]] sections). <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_Subjects NB Subjects 2010-09-13T21:05:17Z <p>Jaxelson: </p> <hr /> <div>= Subjects =<br /> A subject is an active entity generally in the form of a person, process, or device that causes information to flow among objects or changes the system state. <br /> <br /> Within SELinux a subject is generally an active process and has a security context associated with it, however a process can also be referred to as an object depending on the context in which it is being taken, for example:<br /> <br /> # A running process (i.e. an active entity) is a subject because it causes information to flow among objects or can change the system state.<br /> # The process can also be referred to as an object because each process has an associated object class&lt;ref name=&quot;ftn8&quot;&gt;&lt;sup&gt;The object class and its associated permissions are explained in the [[ObjectClassesPerms | Process Object Class]] section.&lt;/sup&gt;&lt;/ref&gt; called &quot;process&quot;. This process &quot;object&quot;, defines what permissions the policy is allowed to grant or deny on the active process. <br /> <br /> An example is given of the above scenarios in the [[NB_Objects#Allowing a Process Access to Resources | Allowing a Process Access to Resources]] section.<br /> <br /> In SELinux subjects can be:<br /> <br /> '''Trusted''' - Generally these are commands, applications etc. that have been written or modified to support specific SELinux functionality to enforce the security policy (e.g. the kernel, init, pam, xinetd and login). However, it can also cover any application that the organisation is willing to trust as a part of the overall system. Although (depending on your paranoia level), the best policy is to trust nothing until it has been verified that it conforms to the security policy. Generally these trusted applications would run in either their own domain (e.g. the audit daemon could run under &lt;tt&gt;auditd_t&lt;/tt&gt;) or grouped together (e.g. the semanage and semodule commands could be grouped under &lt;tt&gt;semanage_t&lt;/tt&gt;).<br /> <br /> '''Untrusted''' - Everything else.<br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_SQL NB SQL 2010-09-13T21:05:02Z <p>Jaxelson: </p> <hr /> <div>= SELinux PostgreSQL Support =<br /> This section gives an overview of the SE-PostgreSQL (version 8.4) extensions to support SELinux in F-12 and how the database context information is managed. It assumes some basic knowledge of PostrgreSQL that can be found at the following web site:<br /> <br /> : [http://wiki.postgresql.org/wiki/Main_Page http://wiki.postgresql.org/wiki/Main_Page]<br /> <br /> For a more in-depth overview of SE-PostgreSQL the &quot;[http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Security-Enhanced PostgreSQL Security Wiki]&quot; is recommended.<br /> <br /> == SE-PostgreSQL Overview ==<br /> SE-PostgreSQL adds SELinux mandatory access controls (MAC) to database objects such as databases, tables, columns, rows (tuples), procedures and blobs (binary large objects)&lt;ref name=&quot;ftn32&quot;&gt;Version 8.5 will support additional database objects.&lt;/ref&gt;. Figure 1 shows a simple database with one table, two columns and three rows, each with their object class and associated security context. The database object classes and permissions are described in the [[ObjectClassesPerms | Object Classes and Permissions]] section.<br /> <br /> {| border=&quot;1&quot;<br /> | colspan=&quot;5&quot; | <br /> <br /> |-<br /> | <br /> | colspan=&quot;3&quot; | &lt;center&gt;'''database''' (db_database)&lt;/center&gt;<br /> &lt;center&gt;security_context = 'unconfined_u:object_r:sepgsql_db_t:s0:c999'&lt;/center&gt;<br /> | <br /> <br /> |-<br /> | colspan=&quot;3&quot; | &lt;center&gt;'''table ('''db_table)&lt;/center&gt;<br /> &lt;center&gt;security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c10'&lt;/center&gt;<br /> <br /> |-<br /> | <br /> | &lt;center&gt;'''column 1''' (db_column)&lt;/center&gt;<br /> &lt;center&gt;security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c20'&lt;/center&gt;<br /> | &lt;center&gt;'''column 2''' (db_column)&lt;/center&gt;<br /> &lt;center&gt;security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c30'&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''row 1''' (db_tuple)&lt;/center&gt;<br /> &lt;center&gt;security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c100'&lt;/center&gt;<br /> | &lt;center&gt;1:1 Information&lt;/center&gt;<br /> | &lt;center&gt;1:2 Information&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''row 2''' (db_tuple)&lt;/center&gt;<br /> &lt;center&gt;security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c200'&lt;/center&gt;<br /> | &lt;center&gt;2:1 Information&lt;/center&gt;<br /> | &lt;center&gt;2:2 Information&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''row 3''' (db_tuple)&lt;/center&gt;<br /> &lt;center&gt;security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c300'&lt;/center&gt;<br /> | &lt;center&gt;3:1 Information&lt;/center&gt;<br /> | &lt;center&gt;3:2 Information&lt;/center&gt;<br /> <br /> |}<br /> <br /> {| border=&quot;1&quot;<br /> | <br /> | <br /> | <br /> <br /> |}<br /> ''Figure 1: Database Security Context Information - Showing the security contexts that can be associated to a database, table, columns and rows. It is also possible to associate security contexts to procedures and blobs.''<br /> <br /> <br /> [[NB_SQL#???? | SE-PostgreSQL Database Example]] has a walk-through on how to install SE-PostgreSQL on F-12 with setting up a database, adding tables etc. to show how the security context is used to enforce access control. <br /> <br /> To use SE-PostgreSQL each GNU / Linux user must have a valid PostgreSQL database role (not to be confused with an SELinux role). The default installation shown in the [[NB_SQL#SE-PostgreSQL_Database_Example| SE-PostgreSQL Database Example]] section automatically adds a user called &lt;tt&gt;sepgsql&lt;/tt&gt; with a suitable database role.<br /> <br /> If a client is connecting remotely and labeled networking is required, then it is possible to use IPSec or NetLabel as discussed in the [[NB_Networking | SELinux Networking Support]] section (the &quot;[http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Security-Enhanced PostgreSQL Security Wiki]&quot; also covers these methods of connectivity with examples). <br /> <br /> Using the [http://taiga.selinuxproject.org/~rhaines/diagrams/28-sepostgresql.png SE-PostgreSQL Services] diagram, the database client application (that could be provided by an API for Perl/PHP or some other programming language) connects to a database and executes SQL commands. As the SQL commands are processed by PostgreSQL, each operation performed on an object managed by the object manager (OM) is checked to see if this is allowed by the security policy or not. If the internal AVC does not hold the cached decision then the SELinux kernel Security Server is asked to resolve the query, with the result being cached internally by the OM.<br /> <br /> Because PostgreSQL (and therefore SE-PostgreSQL) handles processes, files and directories as part of database operations, the OM also handles permissions for these objects where needed (see the &lt;tt&gt;sepostgresql-8.4.2-2583.fc12.src&lt;/tt&gt; rpm - &lt;tt&gt;perms.c&lt;/tt&gt; source code) by re-mapping these permissions internally.<br /> <br /> SE-PostgreSQL supports SELinux services via the &lt;tt&gt;libselinux&lt;/tt&gt; library, however it does not use the &lt;tt&gt;libselinux&lt;/tt&gt; AVC API functions as it provides its own services. The AVC audits are logged into the &lt;tt&gt;sepostgresql.log&lt;/tt&gt; file as described in the [#3.20.2.6.Logging Security Events|outline Logging Security Events] section.<br /> <br /> The SE-PostgreSQL extensions to support MAC access control are described in the SE-PostgreSQL Extensions section below.<br /> <br /> <br /> == SE-PostgreSQL Extensions ==<br /> The following sections describe the areas that have been extended to manage the security context information and enforce access control. There are a number of examples shown in the [[NB_SQL#SE-PostgreSQL_Database_Example | SE-PostgreSQL Database Example]] section that contains a walk-through of the installation, set-up and using SE-PostgreSQL to build a simple database with a single table, two columns and then adding a number of rows.<br /> <br /> The main areas expanded are:<br /> <br /> * Adding an object manager that utilises SELinux support for policy enforcement via &lt;tt&gt;libselinux&lt;/tt&gt; as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/28-sepostgresql.png SE-PostgreSQL Services] diagram. This runs as the &lt;tt&gt;sepostgresql&lt;/tt&gt; server (replacing the &lt;tt&gt;postgresql&lt;/tt&gt; server).<br /> <br /> : The PostgreSQL internal tables (the system catalog) have also been enhanced to support security context information and are described in the [[NB_SQL#Internal_Tables | Internal Tables]] section.<br /> <br /> * Extending SQL statements to support a security context field.<br /> * Adding additional SQL functions to support viewing and updating security context information.<br /> * Modifying utilities to support security context information.<br /> <br /> The sections that follow give a brief overview of the extensions added to support SE-PostgreSQL.<br /> <br /> === Extended SQL Statements ===<br /> The following SQL Statements have been extended to add a &lt;tt&gt;SECURITY_CONTEXT = 'security_context'&lt;/tt&gt; field to support SE-PostgreSQL: <br /> <br /> {| border=&quot;1&quot;<br /> | CREATE DATABASE<br /> | ALTER DATABASE<br /> <br /> |-<br /> | CREATE TABLE<br /> | ALTER TABLE<br /> <br /> |-<br /> | CREATE FUNCTION<br /> | ALTER FUNCTION<br /> <br /> |}<br /> <br /> <br /> For example to create a table with a specific security context, execute:<br /> &lt;pre&gt;<br /> testdb=# CREATE TABLE info () SECURITY_CONTEXT = 'unconfined_u:object_r:sepgsql_table_t:s0:c10';<br /> CREATE TABLE<br /> &lt;/pre&gt;<br /> <br /> === Additional SQL Functions ===<br /> The following functions have been added to manage the additional security context entries (examples are shown in [[NB_SQL#SE-PostgreSQL_Database_Example | SE-PostgreSQL Database Example]] section):<br /> <br /> {| border=&quot;1&quot;<br /> | sepgsql_getcon<br /> | Returns the client security context.<br /> <br /> |-<br /> | sepgsql_server_getcon<br /> | Returns security context of the &lt;tt&gt;sepostgresql&lt;/tt&gt; server.<br /> <br /> |-<br /> | sepgsql_get_user <br /> sepgsql_set_user<br /> | Returns or sets the user portion of the security context.<br /> <br /> |-<br /> | sepgsql_get_role<br /> sepgsql_set_role<br /> | Returns or sets the role portion of the security context.<br /> <br /> |-<br /> | sepgsql_get_type<br /> sepgsql_set_type<br /> | Returns or sets the type portion of the security context.<br /> <br /> |-<br /> | sepgsql_get_range<br /> sepgsql_set_range<br /> | Returns or sets the range portion of the security context.<br /> <br /> |-<br /> | lo_get_security<br /> lo_set_security<br /> | Returns or sets the security context of a binary large object.<br /> <br /> |-<br /> | security_reclaim_label<br /> | Reclaims orphaned security context entries from the internal &lt;tt&gt;pg_security&lt;/tt&gt; table.<br /> <br /> |-<br /> | security_label_to_secid<br /> | Returns the &lt;tt&gt;secid&lt;/tt&gt; column entry from the &lt;tt&gt;pg_security&lt;/tt&gt; table for the requested security context.<br /> <br /> |}<br /> <br /> === Additional Utilities ===<br /> The &lt;tt&gt;pg_dump&lt;/tt&gt; and &lt;tt&gt;pg_dumpall&lt;/tt&gt; backup and restore utilities have been made SELinux-aware so that the security context is maintained.<br /> <br /> An additional utility called &lt;tt&gt;sepg_ctl&lt;/tt&gt; is also supplied that can be used to start, stop, restart, reload configuration files and report the status of a &lt;tt&gt;postgresql&lt;/tt&gt; or &lt;tt&gt;sepostgresql&lt;/tt&gt; server. &lt;tt&gt;sepg_ctl --help&lt;/tt&gt; will list all the options.<br /> <br /> === Additional postgresql.conf Entries ===<br /> The &lt;tt&gt;postgresql.conf&lt;/tt&gt; file has the following additional entries added to manage the &lt;tt&gt;sepostgresql&lt;/tt&gt; process&lt;ref name=&quot;ftn33&quot;&gt;For the default installation described in the [[NB_SQL#SE-PostgreSQL_Database_Example | SE-PostgreSQL Database Example]] section, the configuration file is located at &lt;tt&gt;/var/lib/sepgsql/data/postgresql.conf&lt;/tt&gt;.&lt;/ref&gt;: <br /> <br /> {| border=&quot;1&quot;<br /> | sepostgresql<br /> | SE-PostgreSQL activation option &lt;tt&gt;on&lt;/tt&gt; or &lt;tt&gt;off&lt;/tt&gt;. The default is &lt;tt&gt;on&lt;/tt&gt;.<br /> <br /> |-<br /> | sepostgresql_mcstrans<br /> | If &lt;tt&gt;on&lt;/tt&gt; (the default) SE-PostgreSQL uses &lt;tt&gt;mcstrans&lt;/tt&gt; to translate the raw security context to a readable text field. If &lt;tt&gt;off&lt;/tt&gt; the context is not translated.<br /> <br /> |-<br /> | sepostgresql_row_level<br /> | If &lt;tt&gt;on&lt;/tt&gt; (the default), then row-level access controls (the &lt;tt&gt;db_tuple&lt;/tt&gt; object class) will be enforced. If &lt;tt&gt;off&lt;/tt&gt; row-level access control is not enforced.<br /> <br /> |}<br /> <br /> <br /> === Internal Tables ===<br /> To support the overall database operation PostgreSQL has internal tables in the system catalog that hold information relating to user databases, tables etc. This section will only highlight the internal tables and their columns used by SE-PostgreSQL to support the object classes and security context entries using examples taken from the [[NB_SQL#SE-PostgreSQL_Database_Example | SE-PostgreSQL Database Example]] section.<br /> <br /> Table 1 describes each of the tables used by SE-PostgreSQL to support security context relationships with example &lt;tt&gt;SELECT&lt;/tt&gt; statements to retrieve the relevant information. The only internal table to actually hold security context strings is the &lt;tt&gt;pg_security&lt;/tt&gt; table as all others reference these strings using identifiers as described in Table 2. <br /> <br /> {| border=&quot;1&quot;<br /> | '''Internal Table Name'''<br /> | '''Object'''<br /> | '''Object Class'''<br /> | '''Comments'''<br /> <br /> |-<br /> | pg_database<br /> | Database<br /> | db_database<br /> | The &lt;tt&gt;datname&lt;/tt&gt; column holds the database name.<br /> <br /> &lt;pre&gt;<br /> SELECT datname, security_context FROM pg_database WHERE datname = 'testdb';<br /> <br /> datname | security_context<br /> ---------+-------------------------------------<br /> testdb | unconfined_u:object_r:sepgsql_db_t:s0<br /> &lt;/pre&gt;<br /> <br /> |-<br /> | pg_class<br /> | Table<br /> | db_table<br /> | The &lt;tt&gt;relname&lt;/tt&gt; column holds the table name.<br /> <br /> The &lt;tt&gt;relnatts&lt;/tt&gt; column holds the number of columns in this table.<br /> <br /> The &lt;tt&gt;relfilenode&lt;/tt&gt; column value is that contained in the &lt;tt&gt;pg_security.relid&lt;/tt&gt; entry for each row of the table (as they are related). <br /> <br /> &lt;pre&gt;<br /> SELECT relname, security_context, relnatts, relfilenode FROM pg_class WHERE relname = 'info';<br /> <br /> relname | security_context | relnatts | relfilenode<br /> ---------+-----------------------------------------------+------------+-------------<br /> info | unconfined_u:object_r:sepgsql_table_t:s0:c10 | 2 | 16389<br /> &lt;/pre&gt;<br /> <br /> |-<br /> | pg_attribute<br /> | Column<br /> | db_column<br /> | The &lt;tt&gt;attname&lt;/tt&gt; column holds the column name.<br /> <br /> The &lt;tt&gt;attnum&lt;/tt&gt; column holds the column number.<br /> <br /> The &lt;tt&gt;attrelid&lt;/tt&gt; column value is that contained in the &lt;tt&gt;pg_security.relid&lt;/tt&gt; entry for each row of the table (as they are related). <br /> <br /> &lt;pre&gt;<br /> SELECT attname, security_context, attnum, attrelid FROM pg_attribute WHERE attrelid = 'info'::regclass AND<br /> attnum &gt; 0;<br /> <br /> attname | security_context | attnum | attrelid<br /> -------------+-----------------------------------------------+--------+-----------<br /> user_name | unconfined_u:object_r:sepgsql_table_t:s0:c20 | 1 | 16389<br /> email_addr | unconfined_u:object_r:sepgsql_table_t:s0:c30 | 2 | 16389<br /> &lt;/pre&gt;<br /> <br /> |-<br /> | pg_security<br /> | Row<br /> | db_tuple<br /> | The &lt;tt&gt;pg_security&lt;/tt&gt; table holds the security context strings and pointers for all objects including the rows (or tuples) as described in Table 2.<br /> <br /> |}<br /> ''Table 1: PostgreSQL Internal Tables - Note that each table has other columns containing information, however only that relevant to the overview are described.''<br /> <br /> <br /> Table 2 describes each of the columns defined in the &lt;tt&gt;pg_security&lt;/tt&gt; table with example entries after the table.<br /> <br /> {| border=&quot;1&quot;<br /> ! &lt;center&gt;pg_security Column&lt;/center&gt;<br /> ! Comment<br /> <br /> |-<br /> | secid<br /> | The unique identifier for this security context. The context is unique for this database (the &lt;tt&gt;datid&lt;/tt&gt; column) and related OID (the &lt;tt&gt;relid&lt;/tt&gt; column for the table, procedure, row etc.).<br /> <br /> |-<br /> | datid<br /> | The OID of the database to which this entry refers. This can be obtained from the &lt;tt&gt;pg_stat_database&lt;/tt&gt; table as shown in the following example (that will list all contexts used by this instance of the database):<br /> <br /> &lt;pre&gt;<br /> SELECT datname, secid, relid, secattr FROM pg_security, pg_stat_database WHERE pg_security.datid = pg_stat_database.datid AND<br /> datname='testdb';<br /> &lt;/pre&gt;<br /> <br /> |-<br /> | relid<br /> | The OID of an object (table, column etc.) or the related ID of a row. <br /> <br /> This section will only describe the table, column and row entries for &lt;tt&gt;relid&lt;/tt&gt;. There are many others that relate to internal OIDs used by PostgreSQL that are beyond the scope of this Notebook&lt;ref name=&quot;ftn34&quot;&gt;Note that the database context (OID = &lt;tt&gt;1262&lt;/tt&gt; in the &lt;tt&gt;relid&lt;/tt&gt; column) is listed as being under the &lt;tt&gt;datid&lt;/tt&gt; of database '0'. The best way to retrieve the actual database context is by: &lt;tt&gt;SELECT security_context FROM pg_database WHERE datname = '...'&lt;/tt&gt;;&lt;/ref&gt;.<br /> <br /> For tables an OID of '&lt;tt&gt;1259&lt;/tt&gt;' is assigned. These relate to table names in the &lt;tt&gt;pg_class&lt;/tt&gt; internal table. <br /> <br /> For columns an OID of '&lt;tt&gt;1249&lt;/tt&gt;' is assigned. These relate to column names in the &lt;tt&gt;pg_attribute&lt;/tt&gt; internal table. <br /> <br /> For rows inserted into a table this is the related &lt;tt&gt;pg_class.relfilenode&lt;/tt&gt; and &lt;tt&gt;pg_attribute.attrelid&lt;/tt&gt; entry for that table / column.<br /> <br /> |-<br /> | seckind<br /> | This is currently 'l' for label.<br /> <br /> |-<br /> | secattr<br /> | Text string of the security context for the object (database, table etc.).<br /> <br /> |}<br /> ''Table 2: &lt;tt&gt;pg_security&lt;/tt&gt; Table Columns''<br /> <br /> <br /> <br /> The following are example entries with comments taken from the &lt;tt&gt;pg_security table&lt;/tt&gt; columns that were displayed using &lt;tt&gt;SELECT * FROM pg_security;&lt;/tt&gt;:<br /> &lt;pre&gt;<br /> # datid '1' is for an internal PostgreSQL database.<br /> # relid '3764' is the pg_ts_template OID<br /> # Therefore this context is assigned to a system template object.<br /> <br /> secid | datid | relid | seckind | secattr <br /> ------+-------+-------+---------+--------------------------------------------<br /> 3380 | 1 | 3764 | l | unconfined_u:object_r:sepgsql_sysobj_t:s0<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> # datid '1' is for an internal PostgreSQL database.<br /> # relid '1255' is the pg_proc (procedure) OID<br /> # Therefore this context is assigned to a system procedure object.<br /> <br /> secid | datid | relid | seckind | secattr <br /> ------+-------+-------+---------+--------------------------------------------<br /> 3397 | 1 | 1255 | l | unconfined_u:object_r:sepgsql_db_t:s0<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> # datid '0' is assigned to an internal database.<br /> # relid '1262' is the pg_database (database) OID<br /> # Therefore this context entry is assigned to database objects. <br /> #<br /> # Note that datid = 0 and relid = 1262 entries define contexts assigned to <br /> # database instances including 'testdb' (but see next example).<br /> <br /> secid | datid | relid | seckind | secattr <br /> ------+-------+-------+---------+--------------------------------------------<br /> 3399 | 0 | 1262 | l | unconfined_u:object_r:sepgsql_db_t:s0<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> # This example is for the 'testdb' database after altering its context from the<br /> # above default to 'unconfined_u:object_r:sepgsql_db_t:s0:c888' using:<br /> <br /> ALTER DATABASE testdb SECURITY_CONTEXT = 'unconfined_u:object_r:sepgsql_db_t:s0:c888'<br /> <br /> # This will insert an additional entry into the pg_security table as follows:<br /> <br /> secid | datid | relid | seckind | secattr <br /> ------+-------+-------+---------+--------------------------------------------<br /> 3400 | 0 | 1262 | l | unconfined_u:object_r:sepgsql_db_t:s0:c888<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> # datid '16384' is assigned by the system as the identifier for testdb database.<br /> # relid '1259' is the pg_class (table) OID<br /> # Therefore this entry is for a table in the testdb database.<br /> <br /> secid | datid | relid | seckind | secattr <br /> ------+-------+-------+---------+--------------------------------------------<br /> 16385 | 16384 | 1259 | l | unconfined_u:object_r:sepgsql_table_t:s0:c10<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> # datid '16384' is assigned by the system as the identifier for testdb database.<br /> # relid '1249' is the pg_attribute (column) OID<br /> # Therefore this entry is for a column in a table in the testdb database.<br /> <br /> secid | datid | relid | seckind | secattr <br /> ------+-------+-------+---------+--------------------------------------------<br /> 16386 | 16384 | 1249 | l | unconfined_u:object_r:sepgsql_table_t:s0<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> # datid '16384' is assigned by the system as the identifier for testdb database.<br /> # relid '16389' is a system pointer back to the table (pg_class.relfilenode) and<br /> # column (pg_attribute.attrelid) in testdb database for a row of data.<br /> # Therefore this entry represents the context for a row (tuple) of data in a<br /> # table of the testdb database.<br /> <br /> secid | datid | relid | seckind | secattr <br /> -------+-------+-------+---------+--------------------------------------------<br /> 16393 | 16384 | 16389 | l | unconfined_u:object_r:sepgsql_table_t:s0:c110<br /> &lt;/pre&gt;<br /> <br /> === Logging Security Events ===<br /> SE-PostgreSQL manages its own AVC audit entries in the &lt;tt&gt;/var/log/sepostgresql.log&lt;/tt&gt; file and by default only errors are logged (i.e. it does not add AVC entries into the standard &lt;tt&gt;audit.log&lt;/tt&gt;). To be able to see greater detail then the boolean &lt;tt&gt;sepgsql_enable_audit_allow&lt;/tt&gt; can be enabled (although this does show much gory detail). A pre-requisite is that the &lt;tt&gt;sepostgresql-devel&lt;/tt&gt; policy module is installed. If the SE-PostgreSQL package has been installed as shown in the [[NB_SQL#SE-PostgreSQL_Database_Example | SE-PostgreSQL Database Example]] section, then the policy module would have been installed but not activated. To activate the module:<br /> &lt;pre&gt;<br /> semodule -i /usr/share/selinux/packages/sepostgresql-devel.pp<br /> &lt;/pre&gt;<br /> <br /> Once installed, the boolean can be enabled by:<br /> &lt;pre&gt;<br /> setsebool -P sepgsql_enable_audit_allow on<br /> &lt;/pre&gt;<br /> <br /> The following examples show an &lt;tt&gt;sepostgresql.log&lt;/tt&gt; sequence when the &lt;tt&gt;sepgsql_enable_audit_allow&lt;/tt&gt; boolean has been enabled and a user connects to a database and then performs a &lt;tt&gt;SELECT&lt;/tt&gt; statement.<br /> <br /> The following commands are executed:<br /> &lt;pre&gt;<br /> # Connect to a database with the psql client:<br /> psql testdb<br /> <br /> # Issue a SELECT statement to retrieve information:<br /> testdb=# SELECT user_name, email_addr, security_context FROM info;<br /> <br /> user_name | email_addr | security_context <br /> ----------+--------------------+-------------------------------------------<br /> fred | fred@yahoo.com | unconfined_u:object_r:sepgsql_table_t:s0:c100<br /> derf | derf@hotmail.com | unconfined_u:object_r:sepgsql_table_t:s0:c110<br /> george | george@hotmail.com | unconfined_u:object_r:sepgsql_table_t:s0:c120<br /> (3 rows)<br /> &lt;/pre&gt;<br /> <br /> And the resulting &lt;tt&gt;sepostgresql.log&lt;/tt&gt; entries would be:<br /> &lt;pre&gt;<br /> # This is the 'psql testdb' sequence:<br /> LOG: SELinux: granted { access } scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 <br /> tcontext=unconfined_u:object_r:sepgsql_db_t:s0 tclass=db_database name=testdb<br /> <br /> # This is the 'SELECT user_name, email_addr, security_context FROM info;' sequence of events.<br /> LOG: SELinux: granted { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 <br /> tcontext=unconfined_u:object_r:sepgsql_table_t:s0:c10 tclass=db_table name=info<br /> STATEMENT: SELECT user_name, email_addr, security_context FROM info;<br /> <br /> LOG: SELinux: granted { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023<br /> tcontext=unconfined_u:object_r:sepgsql_table_t:s0 tclass=db_column name=info.security_context<br /> STATEMENT: SELECT user_name, email_addr, security_context FROM info;<br /> <br /> LOG: SELinux: granted { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 <br /> tcontext=unconfined_u:object_r:sepgsql_table_t:s0:c20 tclass=db_column name=info.user_name<br /> STATEMENT: SELECT user_name, email_addr, security_context FROM info;<br /> <br /> LOG: SELinux: granted { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 <br /> tcontext=unconfined_u:object_r:sepgsql_table_t:s0:c30 tclass=db_column name=info.email_addr<br /> STATEMENT: SELECT user_name, email_addr, security_context FROM info;<br /> &lt;/pre&gt;<br /> <br /> = SE-PostgreSQL Database Example =<br /> == Introduction ==<br /> This section gives a run through installing and running a very simple database to show some of the SE-PostgreSQL features. The &quot;[http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Security-Enhanced PostgreSQL Security Wiki]&quot; contains a more complete coverage of the principles, however it does not have a simple walk-through.<br /> <br /> The areas covered are:<br /> * Install &lt;tt&gt;sepostgresql&lt;/tt&gt; using &lt;tt&gt;yum&lt;/tt&gt;. It assumes that &lt;tt&gt;postgresql&lt;/tt&gt; or &lt;tt&gt;sepostgresql&lt;/tt&gt; are not installed.<br /> * Initialise a database cluster so that &lt;tt&gt;sepostgresql&lt;/tt&gt; can be started.<br /> * Create a database called &lt;tt&gt;testdb&lt;/tt&gt;.<br /> * Using the PostgreSQL terminal client &lt;tt&gt;psql&lt;/tt&gt; create a simple table with two columns and insert 4 rows (or tuples) of data demonstrating how to add and show the security context information associated with these objects. To enable the security context information to be distinguished between the various objects the following will be used:<br /> <br /> {| border=&quot;1&quot;<br /> | '''Name'''<br /> | '''Object'''<br /> | '''Context used'''<br /> <br /> |-<br /> | Database (&lt;tt&gt;testdb&lt;/tt&gt;)<br /> | db_database<br /> | unconfined_u:object_r:sepgsql_db_t:s0<br /> <br /> |-<br /> | Table (&lt;tt&gt;info&lt;/tt&gt;)<br /> | db_table<br /> | unconfined_u:object_r:sepgsql_table_t:s0:c10<br /> <br /> |-<br /> | Column 1 (&lt;tt&gt;user_name&lt;/tt&gt;)<br /> | db_column<br /> | unconfined_u:object_r:sepgsql_table_t:s0:c20<br /> <br /> |-<br /> | Column 2 (&lt;tt&gt;email_addr&lt;/tt&gt;)<br /> | db_column<br /> | unconfined_u:object_r:sepgsql_table_t:s0:c30<br /> <br /> |-<br /> | Row 1<br /> | db_tuple<br /> | unconfined_u:object_r:sepgsql_table_t:s0:c100<br /> <br /> |-<br /> | Row 2<br /> | db_tuple<br /> | unconfined_u:object_r:sepgsql_table_t:s0:c110<br /> <br /> |-<br /> | Row 3<br /> | db_tuple<br /> | unconfined_u:object_r:sepgsql_table_t:s0:c120<br /> <br /> |-<br /> | Row 4<br /> | db_tuple<br /> | unconfined_u:object_r::unconfined_t:s0:c130<br /> <br /> |}<br /> <br /> * Finally run some &lt;tt&gt;sepostgresql&lt;/tt&gt; specific functions and explain their results.<br /> <br /> <br /> The following assumptions have been made:<br /> # The user has a basic knowledge of databases and the SQL language.<br /> # SE-PostgreSQL or PostgreSQL are not installed.<br /> # The system used is Fedora 12 with the targeted policy (&lt;tt&gt;selinux-policy-targeted-3.6.32-103.fc12.noarch&lt;/tt&gt;). This would have installed the postgresql policy modules by default.<br /> # Generally when adding entries to a database SE-PostgreSQL will use a default security context, however in this walk-through all entries will have specific security context defined for them (except the database (&lt;tt&gt;testdb&lt;/tt&gt;) that will use the SE-PostgreSQL default).<br /> <br /> == SE-PostgreSQL Walk-through ==<br /> Install &lt;tt&gt;sepostgresql&lt;/tt&gt; using &lt;tt&gt;yum&lt;/tt&gt;. This will install all the required components including &lt;tt&gt;postgresql&lt;/tt&gt;:<br /> &lt;pre&gt;<br /> yum install sepostgresql<br /> &lt;/pre&gt;<br /> <br /> On the authors machine, the following were installed:<br /> &lt;pre&gt;<br /> rpm -qa | grep postgresql<br /> <br /> sepostgresql-8.4.2-2583.fc12.i686<br /> postgresql-libs-8.4.3-1.fc12.i686<br /> postgresql-8.4.3-1.fc12.i686<br /> postgresql-server-8.4.3-1.fc12.i686<br /> &lt;/pre&gt;<br /> <br /> Ensure SELinux is in enforcing mode:<br /> &lt;pre&gt;<br /> setenforce 1<br /> &lt;/pre&gt;<br /> <br /> Once &lt;tt&gt;sepostgresql&lt;/tt&gt; is installed a database cluster needs to be initialised. As part of the &lt;tt&gt;sepostgresql&lt;/tt&gt; installation an init script (&lt;tt&gt;/etc/init.d/sepostgresql&lt;/tt&gt;) was added that will manage this process:<br /> &lt;pre&gt;<br /> service sepostgresql initdb<br /> Initializing database:<br /> &lt;/pre&gt;<br /> <br /> For information, the database cluster will be built by the above process in &lt;tt&gt;/var/lib/sepgsql/data&lt;/tt&gt;. Note that an &lt;tt&gt;sepgsql&lt;/tt&gt; user and group were also added as a part of the installation process:<br /> &lt;pre&gt;<br /> ls -lZ /var/lib/sepgsql<br /> drwx------. 2 sepgsql sepgsql system_u:object_r:postgresql_db_t:s0 backups<br /> drwx------. 2 sepgsql sepgsql unconfined_u:object_r:postgresql_db_t:s0 data<br /> &lt;/pre&gt;<br /> <br /> Once the database cluster has been initialised it can be started by:<br /> &lt;pre&gt;<br /> service sepostgresql start<br /> Starting sepostgresql service: [ OK ]<br /> &lt;/pre&gt;<br /> <br /> This demo will create the test database and tables etc. as the &lt;tt&gt;sepgsql&lt;/tt&gt; user:<br /> &lt;pre&gt;<br /> su - sepgsql<br /> &lt;/pre&gt;<br /> <br /> Optionally, once logged on as the &lt;tt&gt;sepgsql&lt;/tt&gt; user, the PostgreSQL &lt;tt&gt;createuser&lt;/tt&gt; command can be used to allow other GNU / Linux users to access PostgreSQL by:<br /> &lt;pre&gt;<br /> createuser [login_name]<br /> <br /> # for example:<br /> createuser root<br /> Shall the new role be a superuser? (y/n) y<br /> # This would allow root to use the PostgreSQL commands to manage<br /> # the database as a superuser.<br /> &lt;/pre&gt;<br /> <br /> Now the &lt;tt&gt;testdb&lt;/tt&gt; database itself needs to be created by the PostgreSQL &lt;tt&gt;createdb&lt;/tt&gt; command:<br /> &lt;pre&gt;<br /> createdb testdb<br /> &lt;/pre&gt;<br /> <br /> Once created, the PostgreSQL interactive terminal (&lt;tt&gt;psql&lt;/tt&gt;) needs to be loaded so that SQL statements can be run against the database:<br /> &lt;pre&gt;<br /> # This command will load psql and connect it to the testdb database:<br /> psql testdb<br /> &lt;/pre&gt;<br /> <br /> Now that &lt;tt&gt;psql&lt;/tt&gt; is active and connected to the &lt;tt&gt;testdb&lt;/tt&gt; database SQL statements can be run. The first one is to display the security context of the database that requires some knowledge of how SE-PostgreSQL holds its internal parameters. As explained in the [[NB_SQL | SELinux PostgreSQL Support]] section the main internal tables of interest are &lt;tt&gt;pg_database&lt;/tt&gt;, &lt;tt&gt;pg_class&lt;/tt&gt;, &lt;tt&gt;pg_attribute&lt;/tt&gt; and &lt;tt&gt;pg_security&lt;/tt&gt;, with &lt;tt&gt;pg_database&lt;/tt&gt; holding the database name. Therefore if the following SQL statement is executed, the security context of the &lt;tt&gt;testdb&lt;/tt&gt; database will be returned:<br /> &lt;pre&gt;<br /> testdb=# SELECT datname, security_context FROM pg_database <br /> WHERE datname = 'testdb';<br /> <br /> datname | security_context <br /> ---------+---------------------------------------<br /> testdb | unconfined_u:object_r:sepgsql_db_t:s0<br /> (1 row)<br /> &lt;/pre&gt;<br /> <br /> Now a table (&lt;tt&gt;info&lt;/tt&gt;) will be created that will have two columns (&lt;tt&gt;user_name&lt;/tt&gt; and &lt;tt&gt;email_addr&lt;/tt&gt;). A unique security context will be given to each object created as follows:<br /> &lt;pre&gt;<br /> testdb=# CREATE TABLE info (user_name CHAR(10) SECURITY_CONTEXT = 'unconfined_u:object_r:sepgsql_table_t:s0:c20', <br /> email_addr CHAR(20) SECURITY_CONTEXT = 'unconfined_u:object_r:sepgsql_table_t:s0:c30'<br /> ) SECURITY_CONTEXT = 'unconfined_u:object_r:sepgsql_table_t:s0:c10';<br /> CREATE TABLE<br /> &lt;/pre&gt;<br /> <br /> Now that the table has been created, the security context of each object can be displayed by querying SE-PostgreSQL internal tables.<br /> <br /> The SQL statement to retrieve the table object &lt;tt&gt;info&lt;/tt&gt; security context is as follows, note that the &lt;tt&gt;pg_class&lt;/tt&gt; internal table holds the table name:<br /> &lt;pre&gt;<br /> testdb=# SELECT relname, security_context FROM pg_class WHERE relname = 'info'; <br /> <br /> relname | security_context <br /> ---------+----------------------------------------------<br /> info | unconfined_u:object_r:sepgsql_table_t:s0:c10<br /> (1 row)<br /> &lt;/pre&gt;<br /> <br /> The SQL statement to retrieve the column object &lt;tt&gt;user_name&lt;/tt&gt; is as follows, note that the &lt;tt&gt;pg_attribute&lt;/tt&gt; internal table holds the column name:<br /> &lt;pre&gt;<br /> testdb=# SELECT attname, security_context FROM pg_attribute WHERE attname = 'user_name';<br /> <br /> attname | security_context <br /> -----------+----------------------------------------------<br /> user_name | unconfined_u:object_r:sepgsql_table_t:s0:c20<br /> (1 row)<br /> &lt;/pre&gt;<br /> <br /> And the SQL statement to retrieve the column object &lt;tt&gt;email_addr&lt;/tt&gt; is as follows:<br /> &lt;pre&gt;<br /> testdb=# SELECT attname, security_context FROM pg_attribute WHERE attname = 'email_addr';<br /> <br /> attname | security_context <br /> ------------+----------------------------------------------<br /> email_addr | unconfined_u:object_r:sepgsql_table_t:s0:c30<br /> (1 row)<br /> &lt;/pre&gt;<br /> <br /> Now that the table and its columns have been created, it is now possible to insert information into the database. Each row (or tuple) will now be added with its own unique security context.<br /> <br /> Insert Row 1:<br /> &lt;pre&gt;<br /> testdb=# INSERT INTO info (security_context, user_name, email_addr) <br /> VALUES ('unconfined_u:object_r:sepgsql_table_t:s0:c100', 'fred', 'fred@yahoo.com');<br /> INSERT 0 1<br /> &lt;/pre&gt;<br /> <br /> Show Row 1 security context, note that only the table name info is specified (i.e. no internal table name required):<br /> &lt;pre&gt;<br /> testdb=# SELECT user_name, email_addr, security_context FROM info;<br /> <br /> user_name | email_addr | security_context <br /> -----------+-----------------+-------------------------------------------<br /> fred | fred@yahoo.com | unconfined_u:object_r:sepgsql_table_t:s0:c100<br /> (1 row)<br /> &lt;/pre&gt;<br /> <br /> Insert Rows 2 and 3 each with a unique security context:<br /> &lt;pre&gt;<br /> testdb=# INSERT INTO info (security_context, user_name, email_addr) VALUES <br /> ('unconfined_u:object_r:sepgsql_table_t:s0:c110', 'derf', 'derf@hotmail.com');<br /> INSERT 0 1<br /> <br /> testdb=# INSERT INTO info (security_context, user_name, email_addr) VALUES<br /> ('unconfined_u:object_r:sepgsql_table_t:s0:c120', 'george', 'george@hotmail.com');<br /> INSERT 0 1<br /> &lt;/pre&gt;<br /> <br /> Show Rows 1, 2 and 3 security context:<br /> &lt;pre&gt;<br /> testdb=# SELECT user_name, email_addr, security_context FROM info;<br /> <br /> user_name | email_addr | security_context <br /> ----------+--------------------+--------------------------------------------<br /> fred | fred@yahoo.com | unconfined_u:object_r:sepgsql_table_t:s0:c100<br /> derf | derf@hotmail.com | unconfined_u:object_r:sepgsql_table_t:s0:c110<br /> george | george@hotmail.com | unconfined_u:object_r:sepgsql_table_t:s0:c120<br /> (3 rows)<br /> &lt;/pre&gt;<br /> <br /> To demonstrate that SE-PostgreSQL will not allow entries to be entered unless the security context is valid, an entry will be made with a type of &lt;tt&gt;unconfined_t&lt;/tt&gt; as this is not valid for the standard targeted policy. It is assumed that SELinux is in enforcing mode:<br /> &lt;pre&gt;<br /> testdb=# INSERT INTO info (security_context, user_name, email_addr) VALUES 'unconfined_u:object_r:unconfined_t:s0:c130', 'hidden', 'hidden@hotmail.com');<br /> ERROR: SELinux: security policy violation<br /> &lt;/pre&gt;<br /> <br /> Now to demonstrate that SE-PostgreSQL will not display information that is not allowed by the policy, set SELinux to permissive mode:<br /> &lt;pre&gt;<br /> setenforce 0<br /> &lt;/pre&gt;<br /> <br /> Now insert the row again:<br /> &lt;pre&gt;<br /> testdb=# INSERT INTO info (security_context, user_name, email_addr)<br /> VALUES 'unconfined_u:object_r:unconfined_t:s0:c130', 'hidden', 'hidden@hotmail.com');<br /> INSERT 0 1<br /> &lt;/pre&gt;<br /> <br /> And then display the information:<br /> &lt;pre&gt;<br /> testdb=# SELECT user_name, email_addr, security_context FROM info;<br /> <br /> user_name | email_addr | security_context <br /> ----------+--------------------+-----------------------------------------<br /> fred | fred@yahoo.com | unconfined_u:object_r:sepgsql_table_t:s0:c100<br /> derf | derf@hotmail.com | unconfined_u:object_r:sepgsql_table_t:s0:c110<br /> george | george@hotmail.com | unconfined_u:object_r:sepgsql_table_t:s0:c120<br /> hidden | hidden@hotmail.com | unconfined_u:object_r:unconfined_t:s0:c130<br /> (4 rows)<br /> &lt;/pre&gt;<br /> <br /> Now set SELinux to enforcing mode:<br /> &lt;pre&gt;<br /> setenforce 1<br /> &lt;/pre&gt;<br /> <br /> And then display the information, note that the 4&lt;sup&gt;th&lt;/sup&gt; row is not displayed:<br /> &lt;pre&gt;<br /> testdb=# SELECT user_name, email_addr, security_context FROM info;<br /> <br /> user_name | email_addr | security_context <br /> ----------+--------------------+-------------------------------------------<br /> fred | fred@yahoo.com | unconfined_u:object_r:sepgsql_table_t:s0:c100<br /> derf | derf@hotmail.com | unconfined_u:object_r:sepgsql_table_t:s0:c110<br /> george | george@hotmail.com | unconfined_u:object_r:sepgsql_table_t:s0:c120<br /> (3 rows)<br /> &lt;/pre&gt;<br /> <br /> <br /> === SE-PostgreSQL Functions ===<br /> This section will demonstrate some of the additional SE-PostgreSQL functions using the example database 'testdb'.<br /> <br /> ==== Get / Set Security Context Components ====<br /> There are functions to get/set the security context components and this example shows the &lt;tt&gt;sepgsql_get/set_range&lt;/tt&gt; function.<br /> <br /> Show the &lt;tt&gt;range&lt;/tt&gt; component:<br /> &lt;pre&gt;<br /> testdb=# SELECT sepgsql_get_range(security_context), user_name, email_addr FROM info;<br /> <br /> sepgsql_getrange | user_name | email_addr <br /> -----------------+-----------+----------------------<br /> s0:c100 | fred | fred@yahoo.com<br /> s0:c110 | derf | derf@hotmail.com <br /> s0:c120 | george | george@hotmail.com<br /> (3 rows)<br /> &lt;/pre&gt;<br /> <br /> Now change the &lt;tt&gt;range&lt;/tt&gt; for the row that contains the user name of 'fred':<br /> &lt;pre&gt;<br /> testdb=# UPDATE info SET security_context = sepgsql_set_range(security_context, 's0:c999') WHERE user_name = 'fred';<br /> UPDATE 1<br /> &lt;/pre&gt;<br /> <br /> Now show the updated &lt;tt&gt;range&lt;/tt&gt; component:<br /> &lt;pre&gt;<br /> testdb=# SELECT sepgsql_get_range(security_context), user_name, email_addr FROM info;<br /> <br /> sepgsql_getrange | user_name | email_addr <br /> -----------------+-----------+----------------------<br /> s0:c110 | derf | derf@hotmail.com <br /> s0:c120 | george | george@hotmail.com<br /> s0:c999 | fred | fred@yahoo.com<br /> (3 rows)<br /> &lt;/pre&gt;<br /> <br /> <br /> ==== Get Connection Information ====<br /> There are two functions to retrieve client and server context information and are shown below.<br /> <br /> Get client context:<br /> &lt;pre&gt;<br /> testdb=# SELECT sepgsql_getcon();<br /> <br /> sepgsql_getcon <br /> -------------------------------------------------------<br /> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023<br /> (1 row)<br /> &lt;/pre&gt;<br /> <br /> Get SE-PostgreSQL server context:<br /> &lt;pre&gt;<br /> testdb=# SELECT sepgsql_server_getcon();<br /> <br /> sepgsql_server_getcon <br /> ---------------------------------------<br /> unconfined_u:system_r:postgresql_t:s0<br /> (1 row)<br /> &lt;/pre&gt;<br /> <br /> ==== Reclaiming Unused Labels ====<br /> When security contexts (labels) are no longer used, they are left in the &lt;tt&gt;pg_security&lt;/tt&gt; table until they are reused or the space reclaimed. The following example runs the &lt;tt&gt;security_reclaim_label&lt;/tt&gt; function that first returns 0, a row is then deleted (remember each row in the example database has a unique label) and the unused label space is then reclaimed.<br /> <br /> Run function to check there whether there are labels to reclaim:<br /> &lt;pre&gt;<br /> SELECT security_reclaim_label();<br /> <br /> security_reclaim_label<br /> ----------------------------<br /> 1<br /> (1 row)<br /> &lt;/pre&gt;<br /> <br /> The function claimed one label as the entry:<br /> &lt;pre&gt;<br /> user_name | email_addr | security_context <br /> -----------+----------------+-------------------------------------------<br /> fred | fred@yahoo.com | unconfined_u:object_r:sepgsql_table_t:s0:c100<br /> &lt;/pre&gt;<br /> <br /> Was changed to:<br /> &lt;pre&gt;<br /> user_name | email_addr | security_context <br /> -----------+----------------+-------------------------------------------<br /> fred | fred@yahoo.com | unconfined_u:object_r:sepgsql_table_t:s0:c999<br /> &lt;/pre&gt;<br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_RefPolicy NB RefPolicy 2010-09-13T20:49:26Z <p>Jaxelson: </p> <hr /> <div>= The Reference Policy =<br /> == Introduction ==<br /> The Reference Policy is now the standard policy source used to build SELinux policies. This provides a single source tree with supporting documentation that can be used to build policies for different purposes such as: confining important daemons, supporting MLS / MCS type policies and locking down systems so that all processes are under SELinux control. <br /> <br /> This section details how the Reference Policy is:<br /> <br /> # Constructed and types of policy builds supported.<br /> # Installation as a full Reference Policy source or as Header files.<br /> # Modifying the configuration files to build new policies.<br /> # Adding new modules to the build.<br /> <br /> === Notebook Reference Policy Information ===<br /> This section makes use of the F-12 distribution that is built from the standard [http://oss.tresys.com/projects/refpolicy/wiki/DownloadRelease Reference Policy ][http://oss.tresys.com/projects/refpolicy/wiki/DownloadRelease VERSION=20090730]&lt;ref name=&quot;ftn53&quot;&gt;The full source code and details are at the following site: [http://oss.tresys.com/projects/refpolicy http://oss.tresys.com/projects/refpolicy].&lt;/ref&gt;. This is modified and distributed by Red Hat as the following RPM:<br /> <br /> : '''selinux-policy-3.6.32-103.fc12.src.rpm'''&lt;ref name=&quot;ftn54&quot;&gt;This RPM can be obtained from the [http://koji.fedoraproject.org/ http://koji.fedoraproject.org] web site.&lt;/ref&gt;<br /> <br /> This core source code is then used to build various policy RPMs that are distributed by Red Hat as:<br /> <br /> : '''selinux-policy-3.6.32-103.fc12.noarch''' - Contains the SELinux /etc/selinux/config file, man pages and the &quot;Policy Header&quot; development environment that is located at /usr/share/selinux/devel<br /> : '''selinux-policy-doc-3.6.32-103.fc12.noarch''' - Contains the html policy documentation that is located at /usr/share/doc/selinux-policy-3.6.32/html<br /> : '''selinux-policy-minimum-3.6.32-103.fc12.noarch'''<br /> : '''selinux-policy-mls-3.6.32-103.fc12.noarch'''<br /> : '''selinux-policy-targeted-3.6.32-103.fc12.noarch'''<br /> <br /> These three rpms contain policy configuration files and the packaged policy modules (*.pp). These will be used to build the particular policy type in &lt;nowiki&gt;/usr/share/selinux/&lt;policy_name&gt;,&lt;/nowiki&gt; the install process will then install the policy in the appropriate &lt;nowiki&gt;/etc/selinux/&lt;policy_name&gt;&lt;/nowiki&gt; directory.<br /> <br /> <br /> == Reference Policy Overview ==<br /> The Reference Policy can be used to build two different formats of a policy:<br /> <br /> # Loadable Module Policy - A policy that has a base module for core services and has the ability to load / unload modules to support applications as required&lt;ref name=&quot;ftn55&quot;&gt;These can be installed by system administrators as required. The dynamic loading / unloading of policies as applications are loaded is not yet supported.&lt;/ref&gt;. This is now the standard used by GNU / Linux distributions.<br /> # Monolithic Policy - A policy that has all the required policy information in a single base policy.<br /> <br /> Each of the policy types are built using module files that define the specific modules required by the policy as detailed in the [[NB_RefPolicy#Reference_Policy_Module_Files | Reference Policy Module Files]] section. Note that the monolithic policy is built using the the same module files, however they are all assembled into a single &quot;base&quot; source file.<br /> <br /> The Reference Policy is now used by all major distributions of SELinux, however each distribution makes its own specific changes to support their &quot;version of the Reference Policy&quot; (as this section should show as the Red Hat F-12 policy distribution has a slightly different build to the standard [http://oss.tresys.com/projects/refpolicy/wiki/DownloadRelease Reference Policy][http://oss.tresys.com/projects/refpolicy/wiki/DownloadRelease VERSION=2.20090730]). <br /> <br /> There are tools such as SLIDE (SELinux integrated development environment) that can be used to make the task of policy development and testing easier when using the Reference Policy source or headers. SLIDE is an [http://eclipse.org/ Eclipse] plugin and details can be found at:<br /> <br /> [http://oss.tresys.com/projects/slide http://oss.tresys.com/projects/slide]<br /> <br /> === Distributing Policies ===<br /> It is possible to distribute the Reference Policy in two forms:<br /> <br /> # As source code that is then used to build policies. This is not the general way policies are distributed as it contains the complete source that most administrators do not need. The [[NB_RefPolicy#Reference_Policy_Source | Reference Policy Source]] section describes the source and the [[NB_RefPolicy#Installing_and_Building_the_Reference_Policy_Source | Installing and Building the Reference Policy Source]] section describes how to install the source and build a policy.<br /> # As &quot;Policy Headers&quot;. This is the most common way to distribute the Reference Policy. Basically, the modules that make up &quot;the distribution&quot; are pre-built and then linked to form a base and optional modules. The &quot;headers&quot; that make-up the policy are then distributed along with makefiles and documentation. A policy writer can then build policy using the core modules supported by the distribution, and using development tools they can add their own policy modules. The [[NB_RefPolicy#Reference_Policy_Headers | Reference Policy Headers]] section describes how these are installed and used to build modules.<br /> <br /> The policy header files for F-12 are distributed in a number of rpms as follows:<br /> <br /> : '''selinux-policy-3.6.32-103.fc12.noarch''' - This package contains the SELinux /etc/selinux/config file, man pages and the &quot;Policy Header&quot; development environment that is located at /usr/share/selinux/devel<br /> : '''selinux-policy-doc-3.6.32-103.fc12.noarch''' - This package contains the html policy documentation that is located at /usr/share/doc/selinux-policy-3.6.32/html<br /> : '''selinux-policy-minimum-3.6.32-103.fc12.noarch'''<br /> : '''selinux-policy-mls-3.6.32-103.fc12.noarch'''<br /> : '''selinux-policy-targeted-3.6.32-103.fc12.noarch'''<br /> : These three packages contain policy configuration files and policy modules (*.pp files) for the particular policy type to be installed. These files are used to build the policy type in /usr/share/selinux/&lt;policy_name&gt; and then install the policy in the /etc/selinux/&lt;policy_name&gt; directory.<br /> : Normally only one policy would be installed and active, however for development purposes all three can be installed.<br /> <br /> === Policy Functionality ===<br /> As can be seen from the policies distributed with F-12 above, they can be classified by the name of the functionality they support (taken from the &lt;tt&gt;NAME&lt;/tt&gt; entry of the &lt;tt&gt;build.conf&lt;/tt&gt; as shown in Table 2), for example the Red Hat policies support&lt;ref name=&quot;ftn56&quot;&gt;Note that Red Hat pre-configure MCS support within all their policies.&lt;/ref&gt;:<br /> <br /> : mminimum - supports a minimal set of confined daemons within their own domains. The remainder run in the unconfined_t space.<br /> <br /> : mls - supports server based MLS systems.<br /> <br /> : targeted - supports a greater number of confined daemons and can also confine other areas and users (this targeted version also supports the older &quot;strict&quot; version). <br /> <br /> For information, the Reference Policy supports the following types (taken from the &lt;tt&gt;TYPE&lt;/tt&gt; entry of the &lt;tt&gt;build.conf&lt;/tt&gt; as shown in Table 2):<br /> <br /> standard - supports confined daemons and can also confine other areas and users (this is an amalgamated version of the older &quot;targeted&quot; and &quot;strict&quot; versions).<br /> <br /> : mcs - As standard but supports MCS labels.<br /> <br /> : mls - supports MLS labels and confines server processes.<br /> <br /> === Reference Policy Module Files ===<br /> The reference policy modules are constructed using a mixture of [[PolicyLanguage | policy language statements]], [[NB_RefPolicy#Reference_Policy_Support_Macros | support macros]] and access interface calls using three principle types of source file:<br /> <br /> : 1. A private policy file that contains statements required to enforce policy on the specific GNU / Linux service being defined within the module. These files are named &lt;nowiki&gt;&lt;module_name&gt;.te&lt;/nowiki&gt;.<br /> <br /> For example the ada.te file shown below has two statements:<br /> :: a) one to state that the ada_t process has permission to write to the stack and memory allocated to a file.<br /> :: b) one that states that if the unconfined module is loaded, then allow the ada_t domain unconfined access. Note that if the flow of this statement is followed it will be seen that many more interfaces and macros are called to build the final raw SELinux language statements. <br /> <br /> : 2. An external interface file that defines the services available to other modules. These files are named &lt;module_name&gt;.if.<br /> <br /> : For example the ada.if file shown below has two interfaces defined for other modules to call (see also the [http://taiga.selinuxproject.org/~rhaines/diagrams/5-1-doc-screen.png Example Documentation Screen Shot] that shows a screen shot of the documentation that can be automatically generated): <br /> :: a) ada_domtrans - that allows another module (running in domain $1) to run the ada application in the ada_t domain.<br /> :: b) ada_run - that allows another module to run the ada application in the ada_t domain (via the ada_domtrans interface), then associate the ada_t domain to the caller defined role ($2) and terminal ($3).<br /> : Provided of course that the caller domain has permission. <br /> <br /> : It should be noted that there are two types of interface specification:<br /> <br /> :: '''Access Interfaces''' - These are the most common and define interfaces that &lt;tt&gt;.te&lt;/tt&gt; modules can call as described in the ada examples. They are generated by the &lt;tt&gt;interface&lt;/tt&gt; macro as detailed in the the [[NB_RefPolicy#interfaceMacro | interface Macro]] section.<br /> <br /> :: '''Template Interfaces''' - These are required whenever a module is required in different domains and allows the type(s) to be redefined by adding a prefix supplied by the calling module. The basic idea is to set up an application in a domain that is suitable for the defined SELinux user and role to access but not others. These are generated by the &lt;tt&gt;template&lt;/tt&gt; macro as detailed in the [[NB_RefPolicy#templateMacro | template Macro]] section that also explains the &lt;tt&gt;openoffice.if&lt;/tt&gt; template.<br /> <br /> : 3. A file labeling file that defines the labels to be added to files for the specified module. These files are named &lt;module_name&gt;.fc. The build process will amalgamate all the .fc files and finally form the [[PolicyConfigurationFiles#contexts/file_contexts | file_contexts]] file that will be used to label the filesystem.<br /> <br /> For example the ada.fc file shown below requires that the specified files are all labeled system_u:object_r:ada_exec_t:s0. <br /> <br /> The &lt;module_name&gt; must be unique within the reference policy source tree and should reflect the specific GNU / Linux service being enforced by the policy.<br /> <br /> The module files are constructed using a mixture of:<br /> <br /> # Policy language statements as defined in the [[PolicyLanguage | SELinux Policy Language]] section.<br /> # Reference Policy macros that are defined in the [[NB_RefPolicy#Reference_Policy_Macros | Reference Policy Macros]] section.<br /> # External interface calls defined within other modules (.te and .if only).<br /> <br /> An example of each file taken from the ada module is as follows:<br /> <br /> '''ada.te file contents:'''<br /> &lt;pre&gt;<br /> policy_module(ada, 1.4.0)<br /> <br /> ########################################<br /> #<br /> # Declarations<br /> #<br /> <br /> type ada_t;<br /> type ada_exec_t;<br /> application_domain(ada_t, ada_exec_t)<br /> role system_r types ada_t;<br /> <br /> ########################################<br /> #<br /> # Local policy<br /> #<br /> <br /> allow ada_t self:process { execstack execmem };<br /> <br /> userdom_use_user_terminals(ada_t)<br /> optional_policy(`<br /> unconfined_domain(ada_t)<br /> ')<br /> &lt;/pre&gt;<br /> <br /> '''ada.if file contents:'''<br /> &lt;pre&gt;<br /> ## &lt;summary&gt;GNAT Ada95 compiler&lt;/summary&gt;<br /> ########################################<br /> ## &lt;summary&gt;<br /> ##Execute the ada program in the ada domain.<br /> ## &lt;/summary&gt;<br /> ## &lt;param name=&quot;domain&quot;&gt;<br /> ##&lt;summary&gt;<br /> ##Domain allowed access.<br /> ##&lt;/summary&gt;<br /> ## &lt;/param&gt;<br /> #<br /> interface(`ada_domtrans',`<br /> gen_require(`<br /> type ada_t, ada_exec_t;<br /> ')<br /> <br /> corecmd_search_bin($1)<br /> domtrans_pattern($1, ada_exec_t, ada_t)<br /> ')<br /> <br /> ########################################<br /> ## &lt;summary&gt;<br /> ##Execute ada in the ada domain, and<br /> ##allow the specified role the ada domain.<br /> ## &lt;/summary&gt;<br /> ## &lt;param name=&quot;domain&quot;&gt;<br /> ##&lt;summary&gt;<br /> ##Domain allowed access.<br /> ##&lt;/summary&gt;<br /> ## &lt;/param&gt;<br /> ## &lt;param name=&quot;role&quot;&gt;<br /> ##&lt;summary&gt;<br /> ##The role to be allowed the ada domain.<br /> ##&lt;/summary&gt;<br /> ## &lt;/param&gt;<br /> ## &lt;param name=&quot;terminal&quot;&gt;<br /> ##&lt;summary&gt;<br /> ##The type of the terminal allow the ada domain to use.<br /> ##&lt;/summary&gt;<br /> ## &lt;/param&gt;<br /> #<br /> interface(`ada_run',`<br /> gen_require(`<br /> type ada_t;<br /> ')<br /> <br /> ada_domtrans($1)<br /> role $2 types ada_t;<br /> ')<br /> &lt;/pre&gt;<br /> '''ada.fc file contents:'''<br /> &lt;pre&gt;<br /> #<br /> # /usr<br /> #<br /> /usr/bin/gnatbind--gen_context(system_u:object_r:ada_exec_t,s0)<br /> /usr/bin/gnatls--gen_context(system_u:object_r:ada_exec_t,s0)<br /> /usr/bin/gnatmake--gen_context(system_u:object_r:ada_exec_t,s0)<br /> /usr/libexec/gcc(/.*)?/gnat1 -- gen_context(system_u:object_r:ada_exec_t,s0)<br /> &lt;/pre&gt;<br /> <br /> === Reference Policy Documentation ===<br /> One of the advantages of the reference policy is that it is possible to automatically generate documentation as a part of the build process. This documentation is defined in XML and generated as HTML files suitable for viewing via a browser. <br /> <br /> The documentation for F-12 can be found in the following locations:<br /> <br /> : '''Distributed as Policy Headers''' - /usr/share/doc/selinux-policy-&lt;version&gt;/html. Where &lt;version&gt; is the version number of the Red Hat release, for the build used in this Notebook the location is:<br /> <br /> :: /usr/share/doc/selinux-policy-3.6.32/html<br /> <br /> : '''Distributed as Policy Source''' - &lt;location&gt;/src/policy/doc/html. Where &lt;location&gt; is the location of the installed source after make install-src has been executed as described in the [[NB_RefPolicy#_Installing_The_Reference_Policy_Source | Installing The Reference Policy Source]] section. The documentation can then be generated using make html, where for the build used in this Notebook the location is:<br /> &lt;pre&gt;<br /> /etc/selinux/targeted-103/src/policy/doc/html<br /> &lt;/pre&gt;<br /> <br /> The [http://taiga.selinuxproject.org/~rhaines/diagrams/5-1-doc-screen.png Example Documentation Screen Shot] shows an example screen of the documentation produced for the ada module interfaces.<br /> <br /> == Reference Policy Source ==<br /> This section will explain the source layout and configuration files, with the actual installation and building covered in the [[NB_RefPolicy#InstallingandBuilingtheReferencePolicySource | Building the Reference Policy Source]] section. <br /> <br /> The source has a README file containing information on the configuration and installation processes that has been used within this section (and updated with the authors comments as necessary). There is also a VERSION file that contains the Reference Policy release date which can be used to obtain the original source from the repository located at:<br /> <br /> : [http://oss.tresys.com/projects/refpolicy http://oss.tresys.com/projects/refpolicy]<br /> <br /> === Source Layout ===<br /> The [http://taiga.selinuxproject.org/~rhaines/diagrams/5-2-ref-policy.png The Reference Policy Source Tree] diagram shows the layout of the reference policy source tree, that once installed would be located at:<br /> <br /> : &lt;tt&gt;&lt;nowiki&gt;/etc/selinux/&lt;policy_name&gt;/src/policy&lt;/nowiki&gt;&lt;/tt&gt;<br /> <br /> The following sections detail the source contents:<br /> <br /> * [[NB_RefPolicy#Reference_Policy_Files_and_Directories | Reference Policy Files and Directories]] - Describes the files and their location.<br /> * [[NB_RefPolicy#Source_Configuration_Files | Source Configuration Files]] - Details the contents of the build.conf and modules.conf configuration files.<br /> * [[NB_RefPolicy#Source_Installation_and_Build_Make_Options | Source Installation and Build Make Options]] - Describes the &lt;tt&gt;make&lt;/tt&gt; targets.<br /> * [[NB_RefPolicy#Modular_Policy_Build_Process | Modular Policy Build Process]] - Describes how the various source files are linked together to form a base policy module (&lt;tt&gt;base.conf&lt;/tt&gt;) during the build process.<br /> <br /> The [[NB_RefPolicy#Installing_and_Building_the_Reference_Policy_Source | Installing and Building the Reference Policy Source]] section then describes how the initial source is installed and configured to allow a version of the F-12 targeted policy to be built.<br /> <br /> === Reference Policy Files and Directories ===<br /> Table 1 shows the major files and their directories with a description of each taken from the README file. All directories are relative to the root of the Reference Policy source directory ./policy.<br /> <br /> Two of these configuration files (build.conf and modules.conf) are further detailed in the [[NB_RefPolicy#Source_Configuration_Files | Source Configuration Files]] section as they define how the policy will be built.<br /> <br /> During the build process, a file is generated in the ./policy directory called either policy.conf or base.conf depending whether a monolithic or modular policy is being built. This file is explained in the [[NB_RefPolicy#Modular_Policy_Build_Structure | Modular Policy Build Structure]] section.<br /> <br /> {| border=&quot;1&quot;<br /> ! File / Directory Name<br /> ! Comments<br /> <br /> |-<br /> | '''Makefile'''<br /> | General rules for building the policy.<br /> <br /> |-<br /> | '''Rules.modular'''<br /> | Makefile rules specific to building loadable module policies.<br /> <br /> |-<br /> | '''Rules.monolithic'''<br /> | Makefile rules specific to building monolithic policies.<br /> <br /> |-<br /> | '''build.conf'''<br /> | Options which influence the building of the policy, such as the policy type and distribution.<br /> <br /> |-<br /> | '''config/appconfig-&lt;type&gt;'''<br /> | Application configuration files for all configurations of the Reference Policy where &lt;type&gt; is taken from the build.conf TYPE entry that are currently: standard, MLS and MCS). These files are used by SELinux-aware programs.<br /> <br /> |-<br /> | '''config/local.users'''<br /> | The file read by load policy for adding SELinux users to the policy on the fly. <br /> <br /> Note that this file is not used in the F-12 modular policy build.<br /> <br /> |-<br /> | '''doc/html/*'''<br /> | When &lt;tt&gt;make html&lt;/tt&gt; has been executed, contains the in-policy XML documentation, presented in web page form <br /> <br /> |-<br /> | '''doc/policy.dtd'''<br /> | The doc/policy.xml file is validated against this DTD.<br /> <br /> |-<br /> | '''doc/policy.xml'''<br /> | This file is generated/updated by the conf and html make targets. It contains the complete XML documentation included in the policy.<br /> <br /> |-<br /> | '''doc/templates/*'''<br /> | Templates used for documentation web pages.<br /> <br /> |-<br /> | '''support/*'''<br /> | Tools used in the build process.<br /> <br /> |-<br /> | '''policy/flask/initial_sids'''<br /> | This file has declarations for each initial SID.<br /> <br /> The file usage in policy generation is described in the [[NB_RefPolicy#Modular_Policy_Build_Structure | Modular Policy Build Structure]] section.<br /> <br /> |-<br /> | '''policy/flask/security_classes'''<br /> | This file has declarations for each security class.<br /> <br /> The file usage in policy generation is described in the [[NB_RefPolicy#Modular_Policy_Build_Structure | Modular Policy Build Structure]] section.<br /> <br /> |-<br /> | '''policy/flask/access_vectors'''<br /> | This file defines the access vectors. Common prefixes for access vectors may be defined at the beginning of the file. After the common prefixes are defined, an access vector may be defined for each security class.<br /> <br /> The file usage in policy generation is described in the [[NB_RefPolicy#Modular_Policy_Build_Structure | Modular Policy Build Structure]] section.<br /> <br /> |-<br /> | '''policy/modules/*'''<br /> | Each directory represents a layer in Reference Policy all of the modules are contained in one of these layers.<br /> <br /> The files present are:<br /> <br /> metadata.xml - describes the layer.<br /> <br /> &lt;module_name&gt;.te, .if &amp; .fc - contains policy source as described in the [[NB_RefPolicy#Reference_Policy_Module_Files | Reference Policy Module Files]] section.<br /> <br /> The file usage in policy generation is described in the [[NB_RefPolicy#Modular_Policy_Build_Structure | Modular Policy Build Structure]] section.<br /> <br /> |-<br /> | '''policy/booleans.conf'''<br /> | This file is generated/updated by the conf make target. It contains the booleans in the policy, and their default values. If tunables are implemented as booleans, tunables will also be included. This file will be installed as the /etc/selinux/NAME/booleans file (note that this is not true for F-12 or any system that implements the modular policy - see the [[NB_RefPolicy#Booleans,_Global_Booleans_and_Tunable_Booleans | Booleans, Global Booleans and Tunable Booleans]] section).<br /> <br /> This file is also included in the F-12 source updates as described in the [[NB_RefPolicy#Installing_and_Building_the_Reference_Policy_Source | Installing and Building the Reference Policy Source]] section.<br /> <br /> |-<br /> | '''policy/constraints'''<br /> | This file defines additional constraints on permissions in the form of boolean expressions that must be satisfied in order for specified permissions to be granted. These constraints are used to further refine the type enforcement rules and the role allow rules. Typically, these constraints are used to restrict changes in user identity or role to certain domains.<br /> <br /> (Note that this file does not contain the MLS / MCS constraints as they are in the &lt;tt&gt;mls&lt;/tt&gt; and &lt;tt&gt;mcs&lt;/tt&gt; files described below).<br /> <br /> The file usage in policy generation is described in the [[NB_RefPolicy#Modular_Policy_Build_Structure | Modular Policy Build Structure]] section.<br /> <br /> |-<br /> | '''policy/global_booleans'''<br /> | This file defines all booleans that have a global scope, their default value, and documentation. See the [[NB_RefPolicy#Booleans,_Global_Booleans_and_Tunable_Booleans | Booleans, Global Booleans and Tunable Booleans]] section.<br /> <br /> |-<br /> | '''policy/global_tunables'''<br /> | This file defines all tunables that have a global scope, their default value, and documentation. See the [[NB_RefPolicy#Booleans,_Global_Booleans_and_Tunable_Booleans | Booleans, Global Booleans and Tunable Booleans]] section.<br /> <br /> |-<br /> | '''policy/mcs'''<br /> | This contains information used to generate the &lt;tt&gt;sensitivity&lt;/tt&gt;, &lt;tt&gt;category&lt;/tt&gt;, &lt;tt&gt;level&lt;/tt&gt; and &lt;tt&gt;mlsconstraint&lt;/tt&gt; statements used to define the MCS configuration.<br /> <br /> The file usage in policy generation is described in the [[NB_RefPolicy#Modular_Policy_Build_Structure |Modular Policy Build Structure]] section.<br /> <br /> |-<br /> | '''policy/mls'''<br /> | This contains information used to generate the &lt;tt&gt;sensitivity&lt;/tt&gt;, &lt;tt&gt;category&lt;/tt&gt;, &lt;tt&gt;level&lt;/tt&gt; and &lt;tt&gt;mlsconstraint&lt;/tt&gt; statements used to define the MLS configuration.<br /> <br /> The file usage in policy generation is described in the [[NB_RefPolicy#Modular_Policy_Build_Structure | Modular Policy Build Structure]] section.<br /> <br /> |-<br /> | '''policy/modules.conf'''<br /> | This file contains a listing of available modules, and how they will be used when building Reference Policy.<br /> <br /> This file is described in the [[NB_RefPolicy#Reference_Policy_Build_Options | Reference Policy Build Options]] section, it is also updated by the F-12 source updates as described in the [[NB_RefPolicy#Installing_and_Building_the_Reference_Policy_Source | Installing and Building the Reference Policy Source]] section.<br /> <br /> |-<br /> | '''policy/policy_capabilities'''<br /> | This file defines the policy capabilities that can be enabled in the policy.<br /> <br /> The file usage in policy generation is described in the [[NB_RefPolicy#Modular_Policy_Build_Structure | Modular Policy Build Structure]] section.<br /> <br /> |-<br /> | '''policy/rolemap'''<br /> | This file contains prefix and user domain type that corresponds to each user role. The contents of this file will be used to expand the per-user domain templates for each module.<br /> <br /> ''Note this is not used in the Reference Policy (commented out in makefiles).''<br /> <br /> |-<br /> | '''policy/users'''<br /> | This file defines the users included in the policy.<br /> <br /> The file usage in policy generation is described in the [[NB_RefPolicy#Modular_Policy_Build_Structure |Modular Policy Build Structure]] section.<br /> <br /> |-<br /> | '''policy/support/*'''<br /> | Reference Policy support macros. These are described in the [[NB_RefPolicy#Reference_Policy_Macros | Reference Policy Macros]] section.<br /> <br /> |-<br /> | '''securetty_types'''<br /> | These files are not part of the standard distribution but is added by the F-12 source updates as described in the [[NB_RefPolicy#Installing_and_Building_the_Reference_Policy_Source | Installing and Building the Reference Policy Source]] section.<br /> <br /> |-<br /> | '''setrans.conf'''<br /> <br /> |}<br /> ''Table 1: The Reference Policy Files and Directories''<br /> <br /> === Source Configuration Files ===<br /> There are two major configuration files (build.conf and modules.conf) that define the policy to be built and are detailed in this section.<br /> <br /> <br /> ==== Reference Policy Build Options - build.conf ====<br /> This file defines the policy type to be built that will influence its name and where the source will be located once it is finally installed. It also configures the MCS / MLS sensitivity and category maximum values. An example file content is shown in the [[NB_RefPolicy#Installing_and_Building_the_Reference_Policy_Source | Installing and Building the Reference Policy Source]] section where it is used to install and then build the policy.<br /> <br /> Table 2 explains the fields that can be defined within this file, however there are a number of &lt;tt&gt;m4&lt;/tt&gt; macro parameters that are set up when this file is read by the build process makefiles. These definitions are shown in Table 3 and are also used within the module source files to control how the policy is built with examples shown in the [[NB_RefPolicy#ifdef/ifndef Parameters | ifdef / ifndef Parameters]] section.<br /> <br /> <br /> {| border=&quot;1&quot;<br /> ! Option<br /> ! Type<br /> ! Comments<br /> <br /> |-<br /> | '''OUTPUT_POLICY'''<br /> | Integer<br /> | Set the version of the policy created when building a monolithic policy. This option has no effect on modular policy.<br /> <br /> |-<br /> | '''TYPE'''<br /> | String<br /> | Available options are standard, mls, and mcs. For a type enforcement only system, set standard. This optionally enables multi-level security (MLS) or multi-category security (MCS) features. This option controls enable_mls, and enable_mcs policy blocks.<br /> <br /> |-<br /> | '''NAME'''<br /> | String (optional)<br /> | Sets the name of the policy; the NAME is used when installing files to e.g., /etc/selinux/NAME and /usr/share/selinux/NAME. If not set, the policy type field (TYPE) is used.<br /> <br /> The policy built under this directory is also controlled by the modules.conf that is described in the [[NB_RefPolicy#Reference_Policy_Build_Options | Reference Policy Build Options]] section.<br /> <br /> |-<br /> | '''DISTRO'''<br /> | String (optional)<br /> | Enable distribution-specific policy. Available options are redhat, rhel4, gentoo, debian, and suse. This option controls distro_redhat, distro_rhel4, distro_suse policy blocks.<br /> <br /> |-<br /> | '''UNK_PERMS'''<br /> | String<br /> | Set the kernel behaviour for handling of permissions defined in the kernel but missing from the policy. The permissions can either be allowed, denied, or the policy loading can be rejected. See the [[NB_LSM#SELinux_Filesystem | SELinux Filesystem]] for more details.<br /> <br /> |-<br /> | '''DIRECT_INITRC'''<br /> | Boolean (&lt;tt&gt;&lt;nowiki&gt;y|n&lt;/nowiki&gt;&lt;/tt&gt;)<br /> | If '&lt;tt&gt;y&lt;/tt&gt;' sysadm will be allowed to directly run init scripts, instead of requiring the run_init tool. This is a build option instead of a tunable since role transitions do not work in conditional policy. This option controls direct_sysadm_daemon policy blocks.<br /> <br /> |-<br /> | '''MONOLITHIC'''<br /> | Boolean (&lt;tt&gt;&lt;nowiki&gt;y|n&lt;/nowiki&gt;&lt;/tt&gt;)<br /> | If '&lt;tt&gt;y&lt;/tt&gt;' a monolithic policy is built, otherwise a modular policy is built.<br /> <br /> |-<br /> | '''UBAC'''<br /> | Boolean (&lt;tt&gt;&lt;nowiki&gt;y|n&lt;/nowiki&gt;&lt;/tt&gt;)<br /> | If '&lt;tt&gt;y&lt;/tt&gt;' User Based Access Control policy is built. The default for Red Hat is '&lt;tt&gt;n&lt;/tt&gt;'. These are defined as constraints in the &lt;tt&gt;policy/constraints&lt;/tt&gt; file. Note Version 1 of the Reference Policy did not have this entry and defaulted to Role Based Access Control.<br /> <br /> |-<br /> | '''MLS_SENS'''<br /> | Integer<br /> | Set the number of sensitivities in the MLS policy. Ignored on standard and MCS policies.<br /> <br /> |-<br /> | '''MLS_CATS'''<br /> | Integer<br /> | Set the number of categories in the MLS policy. Ignored on standard and MCS policies.<br /> <br /> |-<br /> | '''MCS_CATS'''<br /> | Integer<br /> | Set the number of categories in the MCS policy. Ignored on standard and MLS policies.<br /> <br /> |-<br /> | '''QUIET'''<br /> | Boolean (&lt;tt&gt;&lt;nowiki&gt;y|n&lt;/nowiki&gt;&lt;/tt&gt;)<br /> | If '&lt;tt&gt;y&lt;/tt&gt;' the build system will only display status messages and error messages. This option has no effect on policy.<br /> <br /> |}<br /> ''Table 2: build.conf Entries''<br /> <br /> <br /> <br /> {| border=&quot;1&quot;<br /> ! m4 Parameter Name in Makefile<br /> ! From build.conf entry<br /> ! Comments<br /> <br /> |-<br /> | enable_mls<br /> | '''TYPE'''<br /> | Set if MLS policy build enabled.<br /> <br /> |-<br /> | enable_mcs<br /> | '''TYPE'''<br /> | Set if MCS policy build enabled.<br /> <br /> |-<br /> | enable_ubac<br /> | '''UBAC'''<br /> | Set if UBAC set to '&lt;tt&gt;y&lt;/tt&gt;'.<br /> <br /> |-<br /> | mls_num_sens<br /> | '''MLS_SENS'''<br /> | The number of MLS sensitivities configured.<br /> <br /> |-<br /> | mls_num_cats<br /> | '''MLS_CATS'''<br /> | The number of MLS categories configured.<br /> <br /> |-<br /> | mcs_num_cats<br /> | '''MCS_CATS'''<br /> | The number of MCS categories configured.<br /> <br /> |-<br /> | distro_$(DISTRO)<br /> | '''DISTRO'''<br /> | The distro name or blank.<br /> <br /> |-<br /> | direct_sysadm_daemon<br /> | '''DIRECT_INITRC'''<br /> | If &lt;tt&gt;DIRECT_INITRC&lt;/tt&gt; entry set to '&lt;tt&gt;y&lt;/tt&gt;'.<br /> <br /> |-<br /> | hide_broken_symtoms<br /> | <br /> | This is set up in the &lt;tt&gt;Makefile&lt;/tt&gt; and can be used in modules to hide errors with &lt;tt&gt;dontaudit&lt;/tt&gt; rules (or even &lt;tt&gt;allow&lt;/tt&gt; rules).<br /> <br /> |}<br /> ''Table 3: &lt;tt&gt;m4&lt;/tt&gt; parameters set at build time - These have been extracted from the Reference Policy &lt;tt&gt;Makefile&lt;/tt&gt; file.''<br /> <br /> ==== Reference Policy Build Options - policy/modules.conf ====<br /> This file controls what modules are built within the policy with example entries as follows:<br /> &lt;pre&gt;<br /> # Layer: kernel<br /> # Module: kernel<br /> # Required in base<br /> #<br /> # Policy for kernel threads, proc filesystem, unlabeled processes and objects.<br /> # <br /> kernel = base<br /> <br /> # Module: amanda<br /> #<br /> # Automated backup program.<br /> # <br /> amanda = module<br /> <br /> # Layer: admin<br /> # Module: ddcprobe<br /> #<br /> # ddcprobe retrieves monitor and graphics card information<br /> # <br /> ddcprobe = off<br /> &lt;/pre&gt;<br /> <br /> As can be seen the only active line (those without comments&lt;ref name=&quot;ftn57&quot;&gt;The comments are also important as they form part of the documentation when it is generated by the &lt;tt&gt;make html&lt;/tt&gt; target.&lt;/ref&gt;) is:<br /> &lt;pre&gt;<br /> &lt;module_name&gt; = base | module | off<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | module_name<br /> | The name of the module to be included within the build.<br /> <br /> |-<br /> | base<br /> | The module will be in the base module for a modular policy build (build.conf entry MONOLITHIC = n).<br /> <br /> |-<br /> | module<br /> | The module will be built as a loadable module for a modular policy build. If a monolithic policy is being built (build.conf entry MONOLITHIC = y), then this module will be built into the base module.<br /> <br /> |-<br /> | off<br /> | The module will not be included in any build.<br /> <br /> |}<br /> <br /> Generally it is up to the policy writer to decide which modules are in the base and those that are loadable, however there are some modules that MUST be in the base module. To highlight this there is a special entry at the start of the modules interface file (.if) that has the entry &lt;required val='true'&gt; as shown below (taken from the kernel.if file): <br /> &lt;pre&gt;<br /> ## &lt;summary&gt;<br /> ##Policy for kernel threads, proc filesystem, <br /> ##and unlabeled processes and objects.<br /> ## &lt;/summary&gt;<br /> ## &lt;required val=&quot;true&quot;&gt;<br /> ##This module has initial SIDs.<br /> ## &lt;/required&gt;<br /> &lt;/pre&gt;<br /> <br /> The &lt;tt&gt;modules.conf&lt;/tt&gt; file will also reflect that a module is required in the base by adding a comment &quot;Required in base&quot; when the make conf target is executed (as all the &lt;tt&gt;.if&lt;/tt&gt; files are checked during this process and the &lt;tt&gt;modules.conf&lt;/tt&gt; file updated).<br /> &lt;pre&gt;<br /> # Layer: kernel<br /> # Module: kernel<br /> # Required in base<br /> #<br /> # Policy for kernel threads, proc filesystem,and unlabeled processes and objects.<br /> # <br /> kernel = base<br /> &lt;/pre&gt;<br /> <br /> There are 13 modules in the F-12 reference policy source marked as required and are shown in Table 4.<br /> <br /> {| border=&quot;1&quot;<br /> ! Layer<br /> ! Module Name<br /> ! Comments<br /> <br /> |-<br /> | system<br /> | application<br /> | &lt;nowiki&gt;Policy for user executable applications.<br /> <br /> All the interface calls start with 'application_'.&lt;/nowiki&gt;<br /> <br /> |-<br /> | system<br /> | setrans<br /> | &lt;nowiki&gt;Policy for the SELinux MLS/MCS label translation service.<br /> <br /> All the interface calls start with 'setrans_'.<br /> &lt;/nowiki&gt;<br /> |-<br /> | kernel<br /> | corecommands<br /> | &lt;nowiki&gt;Core policy for shells, and generic programs in:<br /> <br /> /bin, /sbin, /usr/bin, and /usr/sbin. <br /> The .fc file sets up the labels for these items. <br /> All the interface calls start with 'corecmd_'.&lt;/nowiki&gt;<br /> <br /> |-<br /> | kernel<br /> | corenetwork<br /> | Policy controlling access to network objects and also contains the initial SIDs for these.<br /> <br /> The &lt;tt&gt;.if&lt;/tt&gt; file is large and automatically generated. All the interface calls start with '&lt;tt&gt;corenet_&lt;/tt&gt;'.<br /> <br /> |-<br /> | kernel<br /> | devices<br /> | This module creates the device node concept and provides the policy for many of the device files. Notable exceptions are the mass storage and terminal devices that are covered by other modules (that is a char or block device file, usually in /dev). All types that are used to label device nodes should use the dev_node macro.<br /> <br /> Additionally this module controls access to three things:<br /> <br /> # the device directories containing device nodes.<br /> # device nodes as a group<br /> # individual access to specific device nodes covered by this module.<br /> <br /> All the interface calls start with '&lt;tt&gt;dev_&lt;/tt&gt;'.<br /> <br /> |-<br /> | kernel<br /> | domain<br /> | Contains the core policy for forming and managing domains.<br /> <br /> All the interface calls start with '&lt;tt&gt;domain_&lt;/tt&gt;'.<br /> <br /> |-<br /> | kernel<br /> | files<br /> | This module contains basic filesystem types and interfaces and includes:<br /> <br /> # The concept of different file types including basic files, mount points, tmp files, etc.<br /> # Access to groups of files and all files.<br /> # Types and interfaces for the basic filesystem layout (/, /etc, /tmp, /usr, etc.).<br /> # Contains the file initial SID.<br /> <br /> All the interface calls start with '&lt;tt&gt;files_&lt;/tt&gt;'.<br /> <br /> |-<br /> | kernel<br /> | filesystem<br /> | Contains the policy for filesystems and the initial SID.<br /> <br /> All the interface calls start with '&lt;tt&gt;fs_&lt;/tt&gt;'.<br /> <br /> |-<br /> | kernel<br /> | kernel<br /> | Contains the policy for kernel threads, proc filesystem, and unlabeled processes and objects. This module has initial SIDs.<br /> <br /> All the interface calls start with '&lt;tt&gt;kernel_&lt;/tt&gt;'.<br /> <br /> |-<br /> | kernel<br /> | mcs<br /> | Policy for Multicategory security. The .te file only contains attributes used in MCS policy.<br /> <br /> All the interface calls start with '&lt;tt&gt;mcs_&lt;/tt&gt;'.<br /> <br /> |-<br /> | kernel<br /> | mls<br /> | Policy for Multilevel security. The .te file only contains attributes used in MLS policy.<br /> <br /> All the interface calls start with '&lt;tt&gt;mls_&lt;/tt&gt;'.<br /> <br /> |-<br /> | kernel<br /> | selinux<br /> | Contains the policy for the kernel SELinux security interface (selinuxfs).<br /> <br /> All the interface calls start with '&lt;tt&gt;selinux_&lt;/tt&gt;'.<br /> <br /> |-<br /> | kernel<br /> | terminal<br /> | Contains the policy for terminals.<br /> <br /> All the interface calls start with '&lt;tt&gt;term_&lt;/tt&gt;'.<br /> <br /> |}<br /> ''Table 4: Mandatory modules.conf Entries''<br /> <br /> <br /> ===== Building the modules.conf File =====<br /> The file can be created by an editor, however it is generally built initially by make conf that will add any additional modules to the file. The file can then be edited to configure the required modules as base, module or off.<br /> <br /> As will be seen in the [[NB_RefPolicy#InstallingandBuilingtheReferencePolicySource | Installing and Building the Reference Policy Source]] section, the reference policy source comes with a number of pre-configured files that are used to produce the required policy including multiple versions of the modules.conf file.<br /> <br /> === Source Installation and Build Make Options ===<br /> This section explains the various make options available that have been taken from the &lt;tt&gt;README&lt;/tt&gt; file. Table 5 describes the general make targets, Table 6 describes the modular policy make targets and Table 7 describes the monolithic policy make targets.<br /> <br /> <br /> {| border=&quot;1&quot;<br /> ! Make Target<br /> ! Comments<br /> <br /> |-<br /> | '''install-src'''<br /> | Install the policy sources into /etc/selinux/NAME/src/policy, where NAME is defined in the build.conf file. If it is not defined, then TYPE is used instead. If a build.conf does not have the information, then the Makefile will default to the current entry in the /etc/selinux/config file or default to refpolicy. A pre-existing source policy will be moved to /etc/selinux/NAME/src/policy.bak.<br /> <br /> |-<br /> | '''conf'''<br /> | Regenerate policy.xml, and update/create modules.conf and booleans.conf. This should be done after adding or removing modules, or after running the bare target. If the configuration files exist, their settings will be preserved. This must be run on policy sources that are checked out from the CVS repository before they can be used.<br /> <br /> |-<br /> | '''clean'''<br /> | Delete all temporary files, compiled policies, and file_contexts. Configuration files are left intact.<br /> <br /> |-<br /> | '''bare'''<br /> | Do the clean make target and also delete configuration files, web page documentation, and policy.xml.<br /> <br /> |-<br /> | '''html'''<br /> | Regenerate policy.xml and create web page documentation in the doc/html directory.<br /> <br /> |-<br /> | '''install-appconfig'''<br /> | Installs the appropriate SELinux-aware configuration files.<br /> <br /> |}<br /> ''Table 5: General Build Make Targets''<br /> <br /> <br /> {| border=&quot;1&quot;<br /> ! Make Target<br /> ! Comments<br /> <br /> |-<br /> | '''base'''<br /> | Compile and package the base module. This is the default target for modular policies.<br /> <br /> |-<br /> | '''modules'''<br /> | Compile and package all Reference Policy modules configured to be built as loadable modules.<br /> <br /> |-<br /> | '''MODULENAME.pp'''<br /> | Compile and package the MODULENAME Reference Policy module.<br /> <br /> |-<br /> | '''all'''<br /> | Compile and package the base module and all Reference Policy modules configured to be built as loadable modules.<br /> <br /> |-<br /> | '''install'''<br /> | Compile, package, and install the base module and Reference Policy modules configured to be built as loadable modules.<br /> <br /> |-<br /> | '''load'''<br /> | Compile, package, and install the base module and Reference Policy modules configured to be built as loadable modules, then insert them into the module store.<br /> <br /> |-<br /> | '''validate'''<br /> | Validate if the configured modules can successfully link and expand.<br /> <br /> |-<br /> | '''install-headers'''<br /> | Install the policy headers into /usr/share/selinux/NAME. The headers are sufficient for building a policy module locally, without requiring the complete Reference Policy sources. The build.conf settings for this policy configuration should be set before using this target.<br /> <br /> |}<br /> ''Table 6: Modular Policy Build Make Targets''<br /> <br /> <br /> {| border=&quot;1&quot;<br /> ! Make Target<br /> ! Comments<br /> <br /> |-<br /> | '''policy'''<br /> | Compile a policy locally for development and testing. This is the default target for monolithic policies.<br /> <br /> |-<br /> | '''install'''<br /> | Compile and install the policy and file contexts.<br /> <br /> |-<br /> | '''load'''<br /> | Compile and install the policy and file contexts, then load the policy.<br /> <br /> |-<br /> | '''enableaudit'''<br /> | Remove all dontaudit rules from policy.conf.<br /> <br /> |-<br /> | '''relabel'''<br /> | Relabel the filesystem.<br /> <br /> |-<br /> | '''checklabels'''<br /> | Check the labels on the filesystem, and report when a file would be relabeled, but do not change its label.<br /> <br /> |-<br /> | '''restorelabels'''<br /> | Relabel the filesystem and report each file that is relabeled.<br /> <br /> |}<br /> ''Table 7: Monolithic Policy Build Make Targets''<br /> <br /> <br /> === Booleans, Global Booleans and Tunable Booleans ===<br /> The three files &lt;tt&gt;booleans.conf&lt;/tt&gt;, &lt;tt&gt;global_booleans&lt;/tt&gt; and &lt;tt&gt;global_tunables&lt;/tt&gt; are built and used as follows:<br /> <br /> {| border=&quot;1&quot;<br /> | booleans.conf<br /> | This file is generated / updated by &lt;tt&gt;make conf&lt;/tt&gt;, and contains all the booleans in the policy with their default values. If tunable and global booleans are implemented then these are also included. <br /> <br /> This file can also be delivered as a part of the reference policy source as shown in the [[NB_RefPolicy#Installing_and_Building_the_Reference_Policy_Source |outline Installing and Building the Reference Policy Source]] section. This is generally because other default values are used for booleans and not those defined within the modules themselves (i.e. distribution specific booleans). When the make install is executed, then this file will be used to set the default values. <br /> <br /> Note that if booleans are updated locally then the policy store will contain a booleans.local file.<br /> <br /> In SELinux enabled systems that support the policy store features (modular policies) this file is not installed as &lt;tt&gt;/etc/selinux/NAME/booleans&lt;/tt&gt;.<br /> <br /> |-<br /> | global_booleans<br /> | These are booleans that have been defined in the &lt;tt&gt;global_tunables&lt;/tt&gt; file using the [[NB_RefPolicy#gen_bool_Macro | gen_bool]] macro. They are normally booleans for managing the overall policy and currently consist of the following (where the default values are &lt;tt&gt;false&lt;/tt&gt;):<br /> <br /> secure_mode<br /> secure_mode_insmod<br /> secure_mode_policyload<br /> <br /> |-<br /> | global_tunables<br /> | These are booleans that have been defined in module files using the [[NB_RefPolicy#gen_tunable_Macro | gen_tunable]] macro and added to the &lt;tt&gt;global_tunables&lt;/tt&gt; file by &lt;tt&gt;make conf&lt;/tt&gt;. The [[NB_RefPolicy#tunable_policy_Macro | tunable_policy]] macros are defined in each module where policy statements or interface calls are required. They are booleans for managing specific areas of policy that are global in scope. An example is &lt;tt&gt;allow_execstack&lt;/tt&gt; that will allow all processes running in &lt;tt&gt;unconfined_t&lt;/tt&gt; to make their stacks executable.<br /> <br /> |}<br /> <br /> <br /> === Modular Policy Build Structure ===<br /> This section explains the way a modular policy is constructed, this does not really need to be known but is used to show the files used that can then be investigated if required. <br /> <br /> When make all or make load or make install are executed the build.conf and modules.conf files are used to define the policy name and what modules will be built in the base and those as individual loadable modules.<br /> <br /> Basically the source modules (&lt;tt&gt;.te&lt;/tt&gt;, &lt;tt&gt;.if&lt;/tt&gt; and &lt;tt&gt;.fc&lt;/tt&gt;) and core flask files are rebuilt in the tmp directory where the reference policy macros&lt;ref name=&quot;ftn58&quot;&gt;These are explained in the [[NB_RefPolicy#Reference_Policy_Macros | Reference Policy Macros]] section.&lt;/ref&gt; in the source modules will be expanded to form actual policy language statements as described in the [[PolicyLanguage | Policy Language]] section. Figure 3 shows these temporary files that are used to form the base.conf&lt;ref name=&quot;ftn59&quot;&gt;The base.conf gets built for modular policies and a policy.conf file gets built for a monolithic policy.&lt;/ref&gt; file during policy generation. <br /> <br /> The &lt;tt&gt;base.conf&lt;/tt&gt; file will consist of language statements taken from the module defined as &lt;tt&gt;base&lt;/tt&gt; in the &lt;tt&gt;modules.conf&lt;/tt&gt; file along with the constraints, users etc. that are required to build a complete policy.<br /> <br /> The individual loadable modules are built in much the same way as shown in Figure 4.<br /> <br /> {| border=&quot;1&quot;<br /> ! Base Policy Component Description<br /> ! Policy Source File Name (relative to ./policy/policy)<br /> ! ./policy/tmp <br /> <br /> File Name<br /> <br /> |-<br /> | The object classes supported by the kernel.<br /> | flask/security_classes<br /> | pre_te_files.conf<br /> <br /> |-<br /> | The initial SIDs supported by the kernel.<br /> | flask/initial_sids<br /> <br /> |-<br /> | The object class permissions supported by the kernel.<br /> | flask/access_vectors<br /> <br /> |-<br /> | This is either the expanded mls or mcs file depending on the type of policy being built.<br /> | mls or mcs<br /> <br /> |-<br /> | These are the policy capabilities that can be configured / enabled to support the policy.<br /> | policy_capabilities<br /> <br /> |-<br /> | This area contains all the attribute, bool, type and typealias statements extracted from the *.te and *.if files that form the base module.<br /> | modules/*/*.te<br /> <br /> modules/*/*.if<br /> <br /> <br /> <br /> | all_attrs_types.conf<br /> <br /> |-<br /> | Contains the global and tunable bools extracted from the conf files. <br /> | global_bools.conf<br /> <br /> global_tunables.conf<br /> | global_bools.conf<br /> <br /> |-<br /> | Contains the rules extracted from each of the modules .te and .if files defined in the modules.conf file as &quot;base&quot;.<br /> | base modules<br /> | only_te_rules.conf<br /> <br /> |-<br /> | Contains the expanded users from the users file.<br /> | users<br /> | all_post.conf<br /> <br /> |-<br /> | Contains the expanded constraints from the constraints file.<br /> | constraints<br /> <br /> |-<br /> | Contains the default SID labeling extracted from the *.te files.<br /> | modules/*/*.te<br /> <br /> |-<br /> | Contains the fs_use_xattr, fs_use_task, fs_use_trans and genfscon statements extracted from each of the modules .te and .if files defined in the modules.conf file as &quot;base&quot;.<br /> | modules/*/*.te<br /> <br /> modules/*/*.if<br /> <br /> <br /> <br /> <br /> |-<br /> | Contains the netifcon, nodecon and portcon statements extracted from each of the modules .te and .if files defined in the modules.conf file as &quot;base&quot;.<br /> | modules/*/*.te<br /> <br /> modules/*/*.if<br /> <br /> <br /> <br /> | <br /> <br /> |-<br /> | Contains the expanded file context file entries extracted from the *.fc files defined in the modules.conf file as &quot;base&quot;.<br /> | modules/*/*.fc<br /> | base.fc.tmp<br /> <br /> |-<br /> | Expanded seusers file.<br /> | seusers<br /> | seusers<br /> <br /> |-<br /> | colspan=&quot;3&quot; | These are the commands used to compile, link and load the base policy module:<br /> <br /> checkmodule base.conf -o tmp/base.mod<br /> <br /> semodule_package -o base.conf -m base_mod -f base_fc -u users_extra -s tmp/seusers<br /> <br /> semodule -s $(NAME) -b base.pp) -i and each module .pp file<br /> <br /> The &quot;NAME&quot; is that defined in the build.conf file.<br /> <br /> |}<br /> ''Figure 3: Base Module Build - This shows the temporary build files used to build the base module &quot;&lt;tt&gt;base.conf&lt;/tt&gt;&quot; as a part of the &quot;make&quot; process. Note that the modules marked as &lt;tt&gt;base&lt;/tt&gt; in &lt;tt&gt;modules.conf&lt;/tt&gt; are built here. ''<br /> <br /> <br /> {| border=&quot;1&quot;<br /> | '''Base Policy Component Description'''<br /> | '''Policy Source File Name '''(relative to ./policy/policy)<br /> | '''./policy/tmp '''<br /> <br /> '''File Name'''<br /> <br /> |-<br /> | For each module defined as &quot;module&quot; in the modules.conf configuration file, a source module is produced that has been extracted from the *.te and *.if file for that module.<br /> | &lt;nowiki&gt;modules/*/&lt;module_name&gt;.te&lt;/nowiki&gt;<br /> <br /> &lt;nowiki&gt;modules/*/&lt;module_name&gt;.if&lt;/nowiki&gt;<br /> <br /> <br /> <br /> | &lt;nowiki&gt;&lt;module_name&gt;.tmp&lt;/nowiki&gt;<br /> <br /> <br /> <br /> <br /> |-<br /> | For each module defined as &quot;module&quot; in the modules.conf configuration file, an object module is produced from executing the checkmodule command shown below.<br /> | tmp/&lt;module_name&gt;.tmp<br /> | &lt;module_name&gt;.mod<br /> <br /> |-<br /> | For each module defined as &quot;module&quot; in the modules.conf configuration file, an expanded file context file is built from the &lt;module_name&gt;.fc file.<br /> | &lt;nowiki&gt;modules/*/&lt;module_name&gt;.fc&lt;/nowiki&gt;<br /> | base.fc.tmp<br /> <br /> |-<br /> | colspan=&quot;3&quot; | This command is used to compile each module:<br /> <br /> &lt;nowiki&gt;checkmodule tmp/&lt;module_name&gt;.tmp -o tmp/&lt;module_name&gt;.mod&lt;/nowiki&gt;<br /> <br /> <br /> Each module is packaged and loaded with the base module using the following commands:<br /> &lt;pre&gt;<br /> semodule_package -o base.conf -m base_mod -f base_fc -u users_extra -s tmp/seusers<br /> <br /> semodule -s $(NAME) -b base.pp) -i and each module .pp file<br /> &lt;/pre&gt;<br /> The &quot;NAME&quot; is that defined in the build.conf file.<br /> <br /> |}<br /> ''Figure 4: Module Build - This shows the module files and the temporary build files used to build each module as a part of the &quot;make&quot; process (i.e. those modules marked as &lt;tt&gt;module&lt;/tt&gt; in &lt;tt&gt;modules.conf&lt;/tt&gt;).''<br /> <br /> <br /> === Creating Additional Layers ===<br /> One objective of the reference policy is to separate the modules into different layers reflecting their &quot;service&quot; (e.g. kernel, system, app etc.). While it can sometimes be difficult to determine where a particular module should reside, it does help separation, however because the way the build process works, each module must have a unique name.<br /> <br /> If a new layer is required, then the following will need to be completed:<br /> <br /> # Create a new layer directory ./policy/modules/LAYERNAME that reflects the layer's purpose.<br /> # In the ./policy/modules/LAYERNAME directory create a metadata.xml file. This is an XML file with a summary tag and optional desc (long description) tag that should describe the purpose of the layer and will be used as a part of the documentation. An example is as follows:<br /> &lt;pre&gt;<br /> &lt;summary&gt;ABC modules for the XYZ components.&lt;/summary&gt;<br /> &lt;/pre&gt;<br /> <br /> == Installing and Building the Reference Policy Source ==<br /> This section explains how to install the F-12 reference policy source that is distributed by Red Hat (however the same principle is followed for the source taken directly from the [http://oss.tresys.com/projects/refpolicy Tresys repository], except that it will not build a compatible policy to that discussed in this section).<br /> <br /> Any F-12 policy source rpm will suffice and can be obtained from the [http://koji.fedoraproject.org/ http://koji.fedoraproject.org] web site, however it is assumed that the source rpm is:<br /> <br /> : '''selinux-policy-3.6.32-103.fc12.src.rpm'''<br /> <br /> The objective of this exercise is to show that the policy built from the above source rpm is an exact replica of the targeted policy distributed as header files in the F-12 targeted rpm:<br /> <br /> : '''selinux-policy-targeted-3.6.32-103.fc12.noarch.rpm'''<br /> <br /> Note that there is a good overview of rebuilding the source policy at Dan Walsh's site:<br /> <br /> : [http://danwalsh.livejournal.com/2009/02/16/ http://danwalsh.livejournal.com/2009/02/16/] <br /> <br /> === Installation and Configuration ===<br /> Install the source by:<br /> &lt;pre&gt;<br /> rpm -Uvh selinux-policy-3.6.32-103.fc12.src.rpm<br /> &lt;/pre&gt;<br /> <br /> The source will be installed in the users home directory under ./rpmbuild/SOURCES where the serefpolicy-3.6.32.tgz will need to be unpacked:<br /> &lt;pre&gt;<br /> cd $HOME/rpmbuild/SOURCES<br /> tar -xzf serefpolicy.tgz<br /> &lt;/pre&gt;<br /> <br /> The &lt;tt&gt;SOURCES&lt;/tt&gt; directory contents will then look like this:<br /> &lt;pre&gt;<br /> booleans-minimum.conf booleans-mls.conf booleans-olpc.conf<br /> booleans-targeted.conf config.tgz customizable_types<br /> Makefile.devel modules-minimum.conf modules-mls.conf<br /> modules-olpc.conf modules-targeted.conf policy-20100106.patch<br /> policy-F12.patch policygentool securetty_types-minimum<br /> securetty_types-mls securetty_types-olpc securetty_types-targeted<br /> serefpolicy-3.6.32 serefpolicy-3.6.32.tgz setrans-minimum.conf<br /> setrans-mls.conf setrans-olpc.conf setrans-targeted.conf<br /> users-minimum users-mls users-olpc<br /> users-targeted<br /> &lt;/pre&gt;<br /> <br /> The files with minimum, targeted, mls and olpc within their names are the specific configuration files used within the Reference Policy for that particular Red Hat policy type. <br /> <br /> The latest patches now need to be applied to the source tree as follows:<br /> &lt;pre&gt;<br /> patch -p0 &lt;policy-F12.patch<br /> <br /> patch -p0 &lt;policy-20100106.patch<br /> &lt;/pre&gt;<br /> <br /> The &lt;tt&gt;config.tgz&lt;/tt&gt; is Red Hat's updated configuration files this will need to be unpacked and replace the original set of files:<br /> &lt;pre&gt;<br /> # Unpack the archive:<br /> tar -xzf config.tgz<br /> <br /> # move to source directory:<br /> cd serefpolicy-3.6.32<br /> <br /> # save the old files:<br /> mv config config.org<br /> <br /> # and copy over the new Red Hat files<br /> cp -r ../config config<br /> &lt;/pre&gt;<br /> <br /> As the &quot;targeted&quot; policy is being built, the files shown in Table 8 left hand column need to be copied to the location and named as shown in the right hand column.<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;'''Configuration File:'''&lt;/center&gt;<br /> | &lt;center&gt;'''Installed as Reference Policy Configuration File:'''&lt;/center&gt;<br /> <br /> |-<br /> | booleans-targeted.conf<br /> | ./serefpolicy-3.6.32/policy/booleans.conf<br /> <br /> |-<br /> | customizable_types<br /> | ./serefpolicy-3.6.32/config/appconfig-mcs/ customizable_types<br /> <br /> |-<br /> | modules-targeted.conf<br /> | ./serefpolicy-3.6.32/policy/modules.conf<br /> <br /> |-<br /> | securetty_types-targeted<br /> | ./serefpolicy-3.6.32/config/appconfig-mcs/ securetty_types<br /> <br /> |-<br /> | setrans-targeted.conf<br /> | ./serefpolicy-3.6.32/config/appconfig-mcs/ setrans.conf<br /> <br /> |-<br /> | users-targeted.conf<br /> | ./serefpolicy-3.6.32/policy/users<br /> <br /> |}<br /> ''Table 8: Red Hat specific policy configuration files - This example builds a &quot;targeted&quot; policy.''<br /> <br /> <br /> The serefpolicy-3.6.32 directory will now contain the source code with the latest patches for this release (3.6.32-103) of the Red Hat Reference Policy and the correct configuration files for a targeted policy.<br /> <br /> The ./serefpolicy-3.6.32/build.conf must now be modified to allow the source to be installed in its final location and have the correct parameters set for the build. The entries that need to be updated in the build.conf file are highlighted below&lt;ref name=&quot;ftn60&quot;&gt;The README file in this directory contains helpful information on installation of the source, headers, documentation etc. The only point the &lt;tt&gt;README&lt;/tt&gt; will not cover are the Red Hat specific configuration files that need to be copied over as shown in Table 8.&lt;/ref&gt;:<br /> &lt;pre&gt;<br /> #<br /> # Policy build options<br /> #<br /> <br /> # Policy version<br /> # By default, checkpolicy will create the highest version policy it supports. <br /> # Setting this will override the version. This only has an effect for<br /> # monolithic policies.<br /> #OUTPUT_POLICY = 18<br /> <br /> # Policy Type<br /> # standard, mls, mcs. Note Red Hat always build the MCS Policy Type as their “targeted” version.<br /> TYPE = mcs<br /> <br /> # Policy Name<br /> # If set, this will be used as the policy name. Otherwise the policy type <br /> # will be used for the name. This entry is also used by the &quot;make install-src&quot; process to copy the source to the:<br /> # /etc/selinux/targeted-103/src/policy directory.<br /> NAME = targeted-103<br /> <br /> # Distribution<br /> # Some distributions have portions of policy for programs or configurations <br /> # specific to the distribution. Setting this will enable options for the<br /> # distribution. redhat, gentoo, debian, suse, and rhel4 are current options.<br /> # Fedora users should enable redhat.<br /> DISTRO = redhat<br /> <br /> # Unknown Permissions Handling<br /> # The behaviour for handling permissions defined in the kernel but missing from <br /> # the policy. The permissions can either be allowed, denied, or the policy <br /> # loading can be rejected.<br /> # allow, deny, and reject are current options. Red Hat use allow for all<br /> # policies except MLS that uses 'deny'.<br /> UNK_PERMS = allow<br /> <br /> # Direct admin init<br /> # Setting this will allow sysadm to directly run init scripts, instead of <br /> # requiring run_init. This is a build option, as role transitions do not work in<br /> # conditional policy.<br /> DIRECT_INITRC = n<br /> <br /> # Build monolithic policy. Putting n here will build a loadable module policy.<br /> MONOLITHIC = n<br /> <br /> # User-based access control (UBAC)<br /> # Enable UBAC for role separations. Note Red Hat disable UBAC.<br /> UBAC = n<br /> <br /> # Number of MLS Sensitivities<br /> # The sensitivities will be s0 to s(MLS_SENS-1). Dominance will be in increasing<br /> # numerical order with s0 being lowest.<br /> MLS_SENS = 16<br /> <br /> # Number of MLS Categories. Note Red Hat use 1024 categories for MLS and MCS.<br /> # The categories will be c0 to c(MLS_CATS-1).<br /> MLS_CATS = 1024<br /> <br /> # Number of MCS Categories<br /> # The categories will be c0 to c(MLS_CATS-1).<br /> MCS_CATS = 1024<br /> <br /> # Set this to y to only display status messages during build.<br /> QUIET = n<br /> &lt;/pre&gt;<br /> <br /> The policy source is now in a position to be installed at its default location that will be derived from the NAME = targeted-103 entry and will therefore be located at:<br /> <br /> : /etc/selinux/targeted-103/src/policy<br /> <br /> === Building the targeted Policy Type ===<br /> From the ./serefpolicy-3.6.32 directory run the following command:<br /> &lt;pre&gt;<br /> make install-src<br /> &lt;/pre&gt;<br /> <br /> This will copy the source code to its final location making any directories required.<br /> <br /> Once the copy process is complete the policy can be built and the modules loaded into the policy store&lt;ref name=&quot;ftn61&quot;&gt;Note that the term &quot;load&quot; is not loading the policy as the active policy, but just building the base policy + the modules and installing them ready to be activated if required&lt;/ref&gt; by running the following commands:<br /> &lt;pre&gt;<br /> # Go to the source location:<br /> cd /etc/selinux/targeted-103/src/policy<br /> &lt;/pre&gt;<br /> &lt;pre&gt;<br /> # To ensure a clean source build:<br /> make clean<br /> &lt;/pre&gt;<br /> &lt;pre&gt;<br /> # Build the policy modules and load into the policy store:<br /> make load<br /> &lt;/pre&gt;<br /> &lt;pre&gt;<br /> # Finally copy over two files that are not automatically <br /> # managed by the build process. These are held in the<br /> # config/appconfig-mcs directory.<br /> #<br /> cp config/appconfig-mcs/setrans.conf /etc/selinux/targeted-103<br /> <br /> # Need to over-write the old version of this file with this one:<br /> cp config/appconfig-mcs/customizable_types /etc/selinux/targeted-103/contexts<br /> &lt;/pre&gt;<br /> <br /> The policy will now be built as a targeted policy that will be an exact copy of the policy distributed in the following rpm:<br /> <br /> : '''selinux-policy-targeted-3.6.32-103.fc12.noarch.rpm'''<br /> <br /> === Checking the Build ===<br /> Now that the targeted policy has been built, the policy binary file can be compared to the one that is distributed and built by the following rpm:<br /> <br /> : '''selinux-policy-targeted-3.6.32-103.fc12.noarch'''<br /> <br /> The binary files sizes of both policies should be 4,776,004 bytes. <br /> &lt;pre&gt;<br /> ls -l /etc/selinux/targeted/policy<br /> -rw-r--r-- root root 4776004 &lt;date+time&gt; policy.24<br /> <br /> ls -l /etc/selinux/targeted-103/policy<br /> -rw-r--r-- root root 4776004 &lt;date+time&gt; policy.24<br /> &lt;/pre&gt;<br /> <br /> Note that the binaries would not be an exact comparison due to time stamps etc., therefore the SETools sediffx utility should be run against the two binary policies&lt;ref name=&quot;ftn62&quot;&gt;Be aware that comparing these two policies on a low specification machine will take hours. It is best to select a few items for comparison first.&lt;/ref&gt; which should show that they are the same and give the results shown in [http://taiga.selinuxproject.org/~rhaines/diagrams/5-5-Two-Policies.png &quot;Comparing the two &quot;targeted&quot; policies using &lt;tt&gt;sediffx&lt;/tt&gt;&quot;] screen shots.<br /> <br /> === Running with the new Policy ===<br /> To run the system using the new &lt;tt&gt;targeted-103&lt;/tt&gt; build edit the &lt;tt&gt;/etc/selinux/config&lt;/tt&gt; file entry to read &lt;tt&gt;SELINUXTYPE=targeted-103&lt;/tt&gt;, and then run the following commands:<br /> &lt;pre&gt;<br /> touch /.autorelabel<br /> reboot<br /> &lt;/pre&gt;<br /> <br /> During reboot, the system will be relabeled and the policy loaded (hopefully with no errors).<br /> <br /> == Reference Policy Headers ==<br /> This method of building policy and adding new modules is used for distributions that do not require access to the source code. <br /> <br /> Note that the Reference Policy header and the [[NB_RefPolicy#Using_F-12_Supplied_Headers | Red Hat F-12 policy header installations]] are slightly different as described below.<br /> <br /> === Building and Installing the Header Files ===<br /> To be able to fully build the policy headers from the reference policy source two steps are required:<br /> <br /> # Ensure the source is installed and configured as described in the [[NB_RefPolicy#Installing_and_Building_the_Reference_Policy_Source | Installing and Building the Reference Policy Source]] section. This is because the &lt;tt&gt;make load&lt;/tt&gt; (or &lt;tt&gt;make install&lt;/tt&gt;) command will package all the modules as defined in the &lt;tt&gt;modules.conf&lt;/tt&gt; file, producing a &lt;tt&gt;base.pp&lt;/tt&gt; and the relevant &lt;tt&gt;.pp&lt;/tt&gt; packages. The build process will then install these files in the &lt;tt&gt;/usr/share/selinux/&lt;policy_name&gt;&lt;/tt&gt; directory.<br /> # Execute the &lt;tt&gt;make install-headers&lt;/tt&gt; command that will:<br /> : a) Produce a &lt;tt&gt;build.conf&lt;/tt&gt; file that represents the contents of the master &lt;tt&gt;build.conf&lt;/tt&gt; file and place it in the &lt;tt&gt;/usr/share/selinux/&lt;policy_name&gt;/include&lt;/tt&gt; directory.<br /> : b) Produce the XML documentation set that reflects the source and place it in the &lt;tt&gt;/usr/share/selinux/&lt;policy_name&gt;/include&lt;/tt&gt; directory.<br /> : c) Copy a development &lt;tt&gt;Makefile&lt;/tt&gt; for building from policy headers to the &lt;tt&gt;/usr/share/selinux/&lt;policy_name&gt;/include&lt;/tt&gt; directory.<br /> : d) Copy the support macros &lt;tt&gt;.spt&lt;/tt&gt; files to the &lt;tt&gt;/usr/share/selinux/&lt;policy_name&gt;/include/support&lt;/tt&gt; directory.<br /> : e) Copy the module interface files (&lt;tt&gt;.if&lt;/tt&gt;) to the relevant module directories at:<br /> :: &lt;tt&gt;/usr/share/selinux/&lt;policy_name&gt;/include/modules&lt;/tt&gt;.<br /> <br /> The directory structure for the &lt;tt&gt;targeted-103&lt;/tt&gt; build generated above (edited for readability) would be:<br /> &lt;pre&gt;<br /> # The policy packages:<br /> targeted-103/abrt.pp<br /> ....<br /> targeted-103/base.pp<br /> <br /> # Build / Configuration files:<br /> targeted-103/include/build.conf<br /> targeted-103/include/Makefile<br /> targeted-103/include/rolemap # Note this file is not used by F-12<br /> <br /> # XML Documentation:<br /> targeted-103/include/global_tunables.xml<br /> targeted-103/include/global_booleans.xml<br /> targeted-103/include/apps.xml<br /> targeted-103/include/roles.xml<br /> targeted-103/include/system.xml<br /> targeted-103/include/kernel.xml<br /> targeted-103/include/services.xml<br /> targeted-103/include/admin.xml<br /> <br /> # Support Macros:<br /> targeted-103/include/support/ipc_patterns.spt<br /> ...<br /> ...<br /> <br /> # The module interface files in their relevant directories:<br /> targeted-103/include/admin/acct.if<br /> ..<br /> targeted-103/include/apps/ada.if<br /> ..<br /> targeted-103/include/kernel/corecommands.if<br /> ..<br /> targeted-103/include/roles/auditadm.if<br /> ..<br /> targeted-103/include/services/abrt.if<br /> ...<br /> targeted-103/include/system/application.if<br /> ...<br /> &lt;/pre&gt;<br /> <br /> === Using the Header Files ===<br /> Note that this section describes the standard Reference Policy headers, the F-12 installation is slightly different and described in the [[NB_RefPolicy#Using_F-12_Supplied_Headers | Using F-12 Supplied Headers]] section. <br /> <br /> Once the headers are installed as defined above, new modules can be built in any local directory. An example set of module files are located in the reference policy source at /etc/selinux/targeted-103/src/policy/&lt;tt&gt;doc&lt;/tt&gt; and are called &lt;tt&gt;example.te&lt;/tt&gt;, &lt;tt&gt;example.if&lt;/tt&gt;, and &lt;tt&gt;example.fc&lt;/tt&gt;.<br /> <br /> During the header build process a &lt;tt&gt;Makefile&lt;/tt&gt; was included in the headers directory. This &lt;tt&gt;Makefile&lt;/tt&gt; can be used to build the example modules by using makes &lt;tt&gt;-f&lt;/tt&gt; option as follows (assuming that the example module files are in the local directory):<br /> &lt;pre&gt;<br /> make -f &lt;tt&gt;/usr/share/selinux/&lt;policy_name&gt;/include/Makefile&lt;/tt&gt;<br /> &lt;/pre&gt;<br /> <br /> However there is another &lt;tt&gt;Makefile&lt;/tt&gt; that can be installed in the users home directory (&lt;tt&gt;$HOME&lt;/tt&gt;) that will call the master &lt;tt&gt;Makefile&lt;/tt&gt;. This is located at /etc/selinux/targeted-103/src/policy/&lt;tt&gt;doc&lt;/tt&gt; in the reference policy source and is called &lt;tt&gt;Makefile.example&lt;/tt&gt;. This is shown below (note that it extracts the &lt;tt&gt;&lt;policy_name&gt;&lt;/tt&gt; from the SELinux &lt;tt&gt;config&lt;/tt&gt; file):<br /> &lt;pre&gt;<br /> AWK ?= gawk<br /> <br /> NAME ?= $(shell $(AWK) -F= '/^SELINUXTYPE/{ print $$2 }' /etc/selinux/config)<br /> SHAREDIR ?= /usr/share/selinux<br /> HEADERDIR := $(SHAREDIR)/$(NAME)/include<br /> <br /> include $(HEADERDIR)/Makefile<br /> &lt;/pre&gt;<br /> <br /> Table 9 shows the make targets for modules built from headers.<br /> <br /> {| border=&quot;1&quot;<br /> ! Make Target<br /> ! Comments<br /> <br /> |-<br /> | '''MODULENAME.pp'''<br /> | Compile and package the MODULENAME local module.<br /> <br /> |-<br /> | '''all'''<br /> | Compile and package the modules in the current directory.<br /> <br /> |-<br /> | '''load'''<br /> | Compile and package the modules in the current directory, then insert them into the module store.<br /> <br /> |-<br /> | '''refresh'''<br /> | Attempts to reinsert all modules that are currently in the module store from the local and system module packages.<br /> <br /> |-<br /> | '''xml'''<br /> | Build a policy.xml from the XML included with the base policy headers and any XML in the modules in the current directory.<br /> <br /> |}<br /> ''Table 9: Header Policy Build Make Targets''<br /> <br /> <br /> === Using F-12 Supplied Headers ===<br /> The F-12 distribution installs the headers in a slightly different manner as Red Hat installs:<br /> <br /> * The packaged files under the &lt;tt&gt;/usr/share/selinux/&lt;policy_name&gt;&lt;/tt&gt;, these files may be &lt;tt&gt;.pp&lt;/tt&gt; files or &lt;tt&gt;.pp.bz2&lt;/tt&gt; depending on the version of rpm installed (later ones compressed the packages). They are installed by the &lt;nowiki&gt;selinux-policy-&lt;policy_name&gt;-3.6.32-103.fc12.noarch&lt;/nowiki&gt; type rpms.<br /> * The development header files are installed in the /usr/share/selinux/devel directory by the selinux-policy-3.6.32-103.fc12.noarch rpm. Red Hat also include an additional application called &lt;tt&gt;policygentool&lt;/tt&gt; that allows users to generate policy by answering various questions. This tool is described in the [http://docs.fedoraproject.org/selinux-user-guide/f12/en-US/index.html Fedora 12 SELinux User Guide]. The example modules are also in this directory and the &lt;tt&gt;Makefile&lt;/tt&gt; is also slightly different to that used by the Reference Policy source.<br /> * The documentation is supplied in the selinux-policy-doc-3.6.32-103.fc12.noarch type rpms and would be installed (for this version), in the /usr/share/doc/selinux-policy-3.6.32/html directory.<br /> <br /> == Reference Policy Support Macros ==<br /> This section explains some of the support macros used to build reference policy source modules (see Table 10 for the list). These macros are located at:<br /> <br /> * &lt;tt&gt;./policy/policy/support&lt;/tt&gt; for the reference policy source.<br /> * &lt;tt&gt;/usr/share/selinux/&lt;policy_name&gt;/include/support&lt;/tt&gt; for reference policy installed header files.<br /> * &lt;tt&gt;/usr/share/selinux/devel/support&lt;/tt&gt; for Red Hat installed header files.<br /> <br /> They consist of the following files:<br /> : &lt;tt&gt;loadable_module.spt&lt;/tt&gt; - Loadable module support.<br /> : &lt;tt&gt;misc_macros.spt&lt;/tt&gt; - Generate users, bools and security contexts.<br /> : &lt;tt&gt;mls_mcs_macros.spt&lt;/tt&gt; - MLS / MCS support.<br /> : &lt;tt&gt;file_patterns.spt&lt;/tt&gt; - Sets up allow rules via parameters for files and directories.<br /> : &lt;tt&gt;ipc_patterns.spt&lt;/tt&gt; - Sets up allow rules via parameters for Unix domain sockets.<br /> : &lt;tt&gt;misc_patterns.spt&lt;/tt&gt; - Domain and process transitions.<br /> : &lt;tt&gt;obj_perm_sets.spt&lt;/tt&gt; - Object classes and permissions.<br /> <br /> <br /> {| border=&quot;1&quot;<br /> | '''Macro Name'''<br /> | '''Function'''<br /> | '''Macro file name'''<br /> <br /> |-<br /> | policy_module<br /> | For adding the module statement and mandatory &lt;tt&gt;require&lt;/tt&gt; block entries.<br /> | loadable_module.spt<br /> <br /> |-<br /> | gen_require<br /> | For use in interfaces to optionally insert a &lt;tt&gt;require&lt;/tt&gt; block<br /> <br /> |-<br /> | template<br /> | Generate &lt;tt&gt;template&lt;/tt&gt; interface block<br /> <br /> |-<br /> | interface<br /> | Generate the access &lt;tt&gt;interface&lt;/tt&gt; block<br /> <br /> |-<br /> | optional_policy<br /> | Optional policy handling <br /> <br /> |-<br /> | gen_tunable<br /> | Tunable declaration<br /> <br /> |-<br /> | tunable_policy<br /> | Tunable policy handling<br /> <br /> |-<br /> | gen_user<br /> | Generate an SELinux user<br /> | misc_macros.spt<br /> <br /> <br /> <br /> <br /> |-<br /> | gen_context<br /> | Generate a security context<br /> <br /> |-<br /> | gen_bool<br /> | Generate a boolean<br /> <br /> |-<br /> | gen_cats<br /> | Declares categories &lt;tt&gt;c0&lt;/tt&gt; to &lt;tt&gt;c(N-1)&lt;/tt&gt;<br /> | mls_mcs_macros.spt<br /> <br /> <br /> <br /> <br /> |-<br /> | gen_sens<br /> | Declares sensitivities &lt;tt&gt;s0&lt;/tt&gt; to &lt;tt&gt;s(N-1)&lt;/tt&gt; with dominance in increasing numeric order with &lt;tt&gt;s0&lt;/tt&gt; lowest, &lt;tt&gt;s(N-1)&lt;/tt&gt; highest.<br /> <br /> |-<br /> | gen_levels<br /> | Generate levels from &lt;tt&gt;s0&lt;/tt&gt; to &lt;tt&gt;(N-1)&lt;/tt&gt; with categories &lt;tt&gt;c0&lt;/tt&gt; to &lt;tt&gt;(M-1)&lt;/tt&gt;<br /> <br /> |-<br /> | mls_systemlow<br /> | Basic level names for system low and high<br /> <br /> |-<br /> | mls_systemhigh<br /> <br /> |-<br /> | mcs_systemlow<br /> <br /> |-<br /> | mcs_systemhigh<br /> <br /> |-<br /> | mcs_allcats<br /> | Allocates all categories<br /> <br /> |}<br /> ''Table 10: Support Macros described in this section''<br /> <br /> Notes:<br /> # The macro calls can be in any configuration file read by the build process and are contained in (for example) the &lt;tt&gt;users&lt;/tt&gt;, &lt;tt&gt;mls&lt;/tt&gt;, &lt;tt&gt;mcs&lt;/tt&gt; and &lt;tt&gt;constraints&lt;/tt&gt; files.<br /> # There are four main m4 &lt;tt&gt;ifdef&lt;/tt&gt; parameters used within modules:<br /> ## &lt;tt&gt;enable_mcs&lt;/tt&gt; - this is used to test if the MCS policy is being built.<br /> ## &lt;tt&gt;enable_mls&lt;/tt&gt; - this is used to test if the MLS policy is being built.<br /> ## &lt;tt&gt;enable_ubac&lt;/tt&gt; - this enables the user based access control within the &lt;tt&gt;constraints&lt;/tt&gt; file.<br /> ## &lt;tt&gt;hide_broken_symptoms&lt;/tt&gt; - this is used to hide errors in modules with &lt;tt&gt;dontaudit&lt;/tt&gt; rules. <br /> <br /> These are also mentioned in Table 3 as they are set by the initial build process with examples shown in the [[NB_RefPolicy#ifdef_/_ifndef_Parameters | ifdef / ifndef Parameters]] section.<br /> <br /> # The macro examples in this section have been taken from the reference policy module files and shown in each relevant ''''Example Macro'''' section. The macros are then expanded by the build process to form modules containing the policy language statements and rules in the &lt;tt&gt;tmp&lt;/tt&gt; directory. These files have been extracted and modified for readability, then shown in each relevant ''''Expanded Macro'''' section. <br /> # An example policy that has had macros expanded is shown in the [[NB_RefPolicy#Module_Expansion_Process | Module Expansion Process]] section.<br /> # Be aware that spaces between macro names and their parameters are not allowed:<br /> <br /> Allowed:<br /> &lt;pre&gt;<br /> policy_module(ftp, 1.7.0)<br /> &lt;/pre&gt;<br /> <br /> Not allowed:<br /> &lt;pre&gt;<br /> policy_module (ftp, 1.7.0)<br /> &lt;/pre&gt;<br /> <br /> === Loadable Policy Macros ===<br /> The loadable policy module support macros are located in the &lt;tt&gt;loadable_module.spt&lt;/tt&gt; file.<br /> <br /> ==== policy_module Macro ====<br /> This macro will add the module Statement to a loadable module, and automatically add a require Statement with pre-defined information for all loadable modules such as the system_r role, kernel classes and permissions, and optionally MCS / MLS information (&lt;tt&gt;sensitivity&lt;/tt&gt; and &lt;tt&gt;category&lt;/tt&gt; statements).<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> policy_module(module_name,version)<br /> &lt;/pre&gt;<br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | policy_module<br /> | The policy_module macro keyword.<br /> <br /> |-<br /> | module_name<br /> | The module identifier that must be unique in the module layers.<br /> <br /> |-<br /> | version_number<br /> | The module version number in M.m.m format (where M = major version number and m = minor version numbers).<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the modules/services/ftp.te module:<br /> #<br /> policy_module(ftp, 1.7.0)<br /> &lt;/pre&gt;<br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # This is the expanded macro from the tmp/ftp.tmp file:<br /> #<br /> module ftp 1.7.0;<br /> <br /> require {<br /> role system_r;<br /> class security {compute_av compute_create .... };<br /> ....<br /> class capability2 (mac_override mac_admin };<br /> <br /> # If MLS or MCS configured then the:<br /> sensitivity s0;<br /> ....<br /> category c0;<br /> ....<br /> }<br /> &lt;/pre&gt;<br /> <br /> ==== gen_require Macro ====<br /> For use within module files to insert a &lt;tt&gt;require&lt;/tt&gt; block.<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> gen_require(`require_statements`)<br /> &lt;/pre&gt;<br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | gen_require<br /> | The gen_require macro keyword.<br /> <br /> |-<br /> | require_statements<br /> | These statements consist of those allowed in the policy language require Statement.<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the modules/services/ftp.te module:<br /> #<br /> gen_require(`type ftp_script_exec_t;')<br /> &lt;/pre&gt;<br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # This is the expanded macro from the tmp/ftp.tmp file:<br /> #<br /> require {<br /> type ftp_script_exec_t; <br /> }<br /> &lt;/pre&gt;<br /> <br /> ==== optional_policy Macro ====<br /> For use within module files to insert an &lt;tt&gt;optional&lt;/tt&gt; block that will be expanded by the build process only if the modules containing the access or template interface calls that follow are present. If one module is present and the other is not, then the optional statements are not included (need to check).<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> optional_policy(`optional_statements`)<br /> &lt;/pre&gt;<br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | optional_policy<br /> | The optional_policy macro keyword.<br /> <br /> |-<br /> | optional_statements<br /> | These statements consist of those allowed in the policy language optional Statement. However they can also be [[NB_RefPolicy#interface_Macro | interface]], [[NB_RefPolicy#template_Macro | template]] or support macro calls.<br /> <br /> |}<br /> '''The macro is valid in:'''<br /> <br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the modules/services/ftp.te module and <br /> # shows the optional_policy macro with two levels.<br /> #<br /> optional_policy(`<br /> corecmd_exec_shell(ftpd_t)<br /> files_read_usr_files(ftpd_t)<br /> cron_system_entry(ftpd_t, ftpd_exec_t)<br /> <br /> optional_policy(`<br /> logrotate_exec(ftpd_t)<br /> ')<br /> ')<br /> &lt;/pre&gt;<br /> <br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # This is the expanded macro from the tmp/ftp.tmp file showing<br /> # the policy language statements with both optional levels<br /> # expanded.<br /> #<br /> ##### Start optional_policy - Level 1 ###########<br /> optional {<br /> ##### begin corecmd_exec_shell(ftpd_t)<br /> require {<br /> type bin_t, shell_exec_t;<br /> } # end require<br /> allow ftpd_t bin_t:dir { getattr search };<br /> allow ftpd_t bin_t:dir { getattr search read lock ioctl };<br /> allow ftpd_t bin_t:dir { getattr search };<br /> allow ftpd_t bin_t:lnk_file { getattr read };<br /> allow ftpd_t shell_exec_t:file { { getattr read execute ioctl } ioctl lock execute_no_trans };<br /> ##### end corecmd_exec_shell(ftpd_t)<br /> <br /> ##### begin files_read_usr_files(ftpd_t)<br /> require {<br /> type usr_t;<br /> } # end require<br /> allow ftpd_t usr_t:dir { getattr search read lock ioctl };<br /> allow ftpd_t usr_t:dir { getattr search };<br /> allow ftpd_t usr_t:file { getattr read lock ioctl };<br /> allow ftpd_t usr_t:dir { getattr search };<br /> allow ftpd_t usr_t:lnk_file { getattr read };<br /> ##### end files_read_usr_files(ftpd_t)<br /> <br /> ##### begin cron_system_entry(ftpd_t,ftpd_exec_t)<br /> require {<br /> type crond_t, system_crond_t;<br /> } # end require<br /> allow system_crond_t ftpd_exec_t:file { getattr read execute };<br /> allow system_crond_t ftpd_t:process transition;<br /> dontaudit system_crond_t ftpd_t:process { noatsecure siginh rlimitinh };<br /> type_transition system_crond_t ftpd_exec_t:process ftpd_t;<br /> # cjp: perhaps these four rules from the old<br /> # domain_auto_trans are not needed?<br /> allow ftpd_t system_crond_t:fd use;<br /> allow ftpd_t system_crond_t:fifo_file { getattr read write append ioctl lock };<br /> allow ftpd_t system_crond_t:process sigchld;<br /> allow ftpd_t crond_t:fifo_file { getattr read write append ioctl lock };<br /> allow ftpd_t crond_t:fd use;<br /> allow ftpd_t crond_t:process sigchld;<br /> role system_r types ftpd_t;<br /> ##### end cron_system_entry(ftpd_t,ftpd_exec_t)<br /> <br /> ##### Start optional_policy - Level 2 ##########<br /> optional {<br /> ##### begin logrotate_exec(ftpd_t)<br /> require {<br /> type logrotate_exec_t;<br /> } # end require<br /> allow ftpd_t logrotate_exec_t:file { { getattr read execute ioctl } ioctl lock execute_no_trans };<br /> ##### end logrotate_exec(ftpd_t)<br /> } # end optional 2nd level<br /> } # end optional 1st level<br /> &lt;/pre&gt;<br /> <br /> ==== gen_tunable Macro ====<br /> This macro defines booleans that are global in scope. The corresponding [[NB_RefPolicy#tunable_policy_Macro | tunable_policy]] macro contains the supporting statements allowed or not depending on the value of the boolean. These entries are extracted as a part of the build process (by the &lt;tt&gt;make conf&lt;/tt&gt; target) and added to the &lt;tt&gt;global_tunables&lt;/tt&gt; file where they can then be used to alter the default values for the &lt;tt&gt;make load&lt;/tt&gt; or &lt;tt&gt;make install&lt;/tt&gt; targets.<br /> <br /> Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[NB_RefPolicy#Reference_Policy_Documentation | documentation]].<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> gen_tunable(boolean_name,boolean_value)<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | gen_tunable<br /> | The gen_tunable macro keyword.<br /> <br /> |-<br /> | boolean_name<br /> | The &lt;tt&gt;boolean&lt;/tt&gt; identifier.<br /> <br /> |-<br /> | boolean_value<br /> | The &lt;tt&gt;boolean&lt;/tt&gt; value that can be either &lt;tt&gt;true&lt;/tt&gt; or &lt;tt&gt;false&lt;/tt&gt;.<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the modules/services/ftp.te module:<br /> #<br /> <br /> ## &lt;desc&gt;<br /> ## &lt;p&gt;<br /> ## Allow ftp servers to use nfs<br /> ## for public file transfer services.<br /> ## &lt;/p&gt;<br /> ## &lt;/desc&gt;<br /> gen_tunable(allow_ftpd_use_nfs, false)<br /> &lt;/pre&gt;<br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # This is the expanded macro from the tmp/ftp.tmp file:<br /> #<br /> bool allow_ftpd_use_nfs false;<br /> &lt;/pre&gt;<br /> <br /> ==== tunable_policy Macro ====<br /> This macro contains the statements allowed or not depending on the value of the boolean defined by the [[NB_RefPolicy#gen_tunable_Macro | gen_tunable]] macro. <br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> tunable_policy(`gen_tunable_id`,`tunable_policy_rules`)<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | tunable_policy<br /> | The tunable_policy macro keyword.<br /> <br /> |-<br /> | gen_tunable_id<br /> | This is the boolean identifier defined by the &lt;tt&gt;gen_tunable&lt;/tt&gt; macro. It is possible to have multiple entries separated by &lt;tt&gt;&amp;&amp;&lt;/tt&gt; or &lt;tt&gt;||&lt;/tt&gt; as shown in the example.<br /> <br /> |-<br /> | tunable_policy_rules<br /> | These are the policy rules and statements as defined in the if Statement policy language section.<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> <br /> |}<br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the modules/services/ftp.te module<br /> # showing the use of the boolean with the &amp;&amp; operator.<br /> #<br /> tunable_policy(`allow_ftpd_use_nfs &amp;&amp; allow_ftpd_anon_write',`<br /> fs_manage_nfs_files(ftpd_t)<br /> ')<br /> &lt;/pre&gt;<br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # This is the expanded macro from the tmp/ftp.tmp file.<br /> #<br /> if (allow_ftpd_use_nfs &amp;&amp; allow_ftpd_anon_write) {<br /> <br /> ##### begin fs_manage_nfs_files(ftpd_t)<br /> require {<br /> type nfs_t;<br /> } # end require<br /> allow ftpd_t nfs_t:dir { read getattr lock search ioctl add_name remove_name write };<br /> allow ftpd_t nfs_t:file { create open getattr setattr read write append rename link unlink ioctl lock };<br /> ##### end fs_manage_nfs_files(ftpd_t)<br /> } # end if<br /> &lt;/pre&gt;<br /> <br /> ==== interface Macro ====<br /> Access interface macros are defined in the interface module file (&lt;tt&gt;.if&lt;/tt&gt;) and form the interface through which other modules can call on the modules services (as shown in [http://taiga.selinuxproject.org/~rhaines/diagrams/5-7-resulting-code.png The Resulting Code] diagram and described in the [[NB_RefPolicy#Module_Expansion | Module Expansion]] section.<br /> <br /> Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[NB_RefPolicy#Reference_Policy_Documentation | documentation]].<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> interface(`name`,`interface_rules`)<br /> &lt;/pre&gt;<br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | interface<br /> | The &lt;tt&gt;interface&lt;/tt&gt; macro keyword.<br /> <br /> |-<br /> | name<br /> | The &lt;tt&gt;interface&lt;/tt&gt; identifier that should be named to reflect the module identifier and its purpose.<br /> <br /> |-<br /> | interface_rules<br /> | This can consist of the support macros, policy language statements or other &lt;tt&gt;interface&lt;/tt&gt; calls as required to provide the service.<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Interface Definition:'''<br /> &lt;pre&gt;<br /> # This example is from the modules/services/ftp.if module<br /> # showing the &quot;ftp_read_config&quot; interface.<br /> #<br /> <br /> ########################################<br /> ## &lt;summary&gt;<br /> ## Read ftpd etc files<br /> ## &lt;/summary&gt;<br /> ## &lt;param name=&quot;domain&quot;&gt;<br /> ##&lt;summary&gt;<br /> ## Domain allowed access.<br /> ##&lt;/summary&gt;<br /> ## &lt;/param&gt;<br /> #<br /> interface(`ftp_read_config',`<br /> gen_require(`<br /> type ftpd_etc_t;<br /> ')<br /> <br /> files_search_etc($1)<br /> allow $1 ftpd_etc_t:file { getattr read };<br /> ')<br /> &lt;/pre&gt;<br /> <br /> '''Expanded Macro:''' (taken from the &lt;tt&gt;base.conf&lt;/tt&gt; file):<br /> &lt;pre&gt;<br /> # Access Interfaces are only expanded at policy compile time <br /> # if they are called by a module that requires their services.<br /> #<br /> # In this example the ftp_read_config interface is called from<br /> # the init.te module via the optional_policy macro as shown<br /> # below with the expanded code shown afterwards.<br /> #<br /> ######## From ./policy/policy/modules/system/init.te ########<br /> #<br /> # optional_policy(`<br /> # ftp_read_config(initrc_t)<br /> # ')<br /> #<br /> #<br /> ############# Expanded policy statements taken ##############<br /> ############# from the base.conf file that ##################<br /> ############# forms the base policy. ########################<br /> #<br /> optional { # Start optional_policy segment for ftp interface<br /> #<br /> # This is the resulting output contained the base.conf file<br /> # where init calls the ftp_read_config ($1) interface from<br /> # init.te with the parameter initrc_t:<br /> #<br /> require {<br /> type ftpd_etc_t;<br /> } <br /> <br /> #<br /> # Call the files_search_etc ($1) interface contained in the <br /> # ftp.if file with the parameter initrc_t:<br /> #<br /> require {<br /> type etc_t;<br /> } <br /> allow initrc_t etc_t:dir { getattr search };<br /> #<br /> # end files_search_etc(initrc_t)<br /> #<br /> # This is the '''allow $1 ftpd_etc_t:file { getattr read };<br /> # statement with the '''initrc_t''' parameter resolved: <br /> #<br /> allow initrc_t ftpd_etc_t:file { getattr read };<br /> #<br /> # end ftp_read_config(initrc_t)<br /> <br /> } # End optional_policy segment for this ftp interface<br /> &lt;/pre&gt;<br /> <br /> ==== template Macro ====<br /> A template interface is used to help create a domain and set up the appropriate rules and statements to run an application / process. The basic idea is to set up an application in a domain that is suitable for the defined SELinux user and role to access but not others. Should a different user / role need to access the same application, another domain would be allocated (these are known as &quot;derived domains&quot; as the domain name is derived from caller information). <br /> <br /> The application template shown in the example below is for &lt;tt&gt;openoffice.org&lt;/tt&gt; where the domain being set up to run the application is based on the SELinux user &lt;tt&gt;xguest&lt;/tt&gt; (parameter &lt;tt&gt;$1&lt;/tt&gt;) therefore a domain type is initialised called &lt;tt&gt;xguest_openoffice_t&lt;/tt&gt;, this is then added to the user domain attribute xguest_usertype (parameter &lt;tt&gt;$2&lt;/tt&gt;). Finally the role &lt;tt&gt;xguest_r&lt;/tt&gt; (parameter &lt;tt&gt;$3&lt;/tt&gt;) is allowed access to the domain type &lt;tt&gt;xguest_openoffice_t&lt;/tt&gt;. If a different user / role required access to openoffice.org, then by passing different parameters (i.e. &lt;tt&gt;user_u&lt;/tt&gt;), a different domain would be set up.<br /> <br /> The main differences between an application interface and a template interface are:<br /> * An access interface is called by other modules to perform a service.<br /> * A template interface allows an application to be run in a domain based on user / role information to isolate different instances.<br /> <br /> Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[NB_RefPolicy#Reference_Policy_Documentation | documentation]].<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> template(`name`,`template_rules`)<br /> &lt;/pre&gt;<br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | template<br /> | The &lt;tt&gt;template&lt;/tt&gt; macro keyword.<br /> <br /> |-<br /> | name<br /> | The &lt;tt&gt;template&lt;/tt&gt; identifier that should be named to reflect the module identifier and its purpose. By convention the last component is &lt;tt&gt;_template&lt;/tt&gt; (e.g. &lt;tt&gt;ftp_per_role_template&lt;/tt&gt;).<br /> <br /> |-<br /> | &lt;tt&gt;template&lt;/tt&gt;_rules<br /> | This can consist of the support macros, policy language statements or &lt;tt&gt;interface&lt;/tt&gt; calls as required to provide the service.<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the modules/apps/openoffice.if module<br /> # showing the &quot;openoffice_per_role_template&quot; template interface.<br /> #<br /> #######################################<br /> ## &lt;summary&gt;<br /> ##The per role template for the openoffice module.<br /> ## &lt;/summary&gt;<br /> ## &lt;desc&gt;<br /> ##&lt;p&gt;<br /> ##This template creates a derived domains which are used<br /> ##for openoffice applications.<br /> ##&lt;/p&gt;<br /> ## &lt;/desc&gt;<br /> ## &lt;param name=&quot;userdomain_prefix&quot;&gt;<br /> ##&lt;summary&gt;<br /> ##The prefix of the user domain (e.g., user<br /> ##is the prefix for user_t).<br /> ##&lt;/summary&gt;<br /> ## &lt;/param&gt;<br /> ## &lt;param name=&quot;user_domain&quot;&gt;<br /> ##&lt;summary&gt;<br /> ##The type of the user domain.<br /> ##&lt;/summary&gt;<br /> ## &lt;/param&gt;<br /> ## &lt;param name=&quot;user_role&quot;&gt;<br /> ##&lt;summary&gt;<br /> ##The role associated with the user domain.<br /> ##&lt;/summary&gt;<br /> ## &lt;/param&gt;<br /> #<br /> template(`openoffice_per_role_template',`<br /> gen_require(`<br /> type openoffice_exec_t;<br /> ')<br /> <br /> type $1_openoffice_t;<br /> domain_type($1_openoffice_t)<br /> domain_entry_file($1_openoffice_t, openoffice_exec_t)<br /> role $3 types $1_openoffice_t;<br /> <br /> domain_interactive_fd($1_openoffice_t)<br /> <br /> userdom_unpriv_usertype($1, $1_openoffice_t)<br /> userdom_exec_user_home_content_files($1, $1_openoffice_t)<br /> <br /> allow $1_openoffice_t self:process { getsched sigkill execheap execmem execstack };<br /> <br /> allow $2 $1_openoffice_t:process { getattr ptrace signal_perms noatsecure siginh rlimitinh };<br /> allow $1_openoffice_t $2:tcp_socket { read write };<br /> <br /> domtrans_pattern($2, openoffice_exec_t, $1_openoffice_t)<br /> <br /> dev_read_urand($1_openoffice_t)<br /> dev_read_rand($1_openoffice_t)<br /> <br /> fs_dontaudit_rw_tmpfs_files($1_openoffice_t)<br /> <br /> allow $2 $1_openoffice_t:process { signal sigkill };<br /> allow $1_openoffice_t $2:unix_stream_socket connectto;<br /> ')<br /> &lt;/pre&gt;<br /> <br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # Template Interfaces are only expanded at policy compile time <br /> # if they are called by a module that requires their services.<br /> # This has been expanded as a part of the roles/xguest.te<br /> # module and extracted from tmp/xguest.tmp.<br /> #<br /> ################# START Expanded code segment ###########<br /> #<br /> optional {<br /> <br /> ##### begin openoffice_per_role_template(xguest,xguest_usertype,xguest_r)<br /> require {<br /> type openoffice_exec_t;<br /> } # end require<br /> type xguest_openoffice_t; # Paremeter $1<br /> <br /> ......<br /> # This is a long set of rules, therefore has been cut down.'''<br /> ......<br /> ....<br /> typeattribute xguest_openoffice_t xguest_usertype; # Paremeter $2<br /> ..<br /> type_transition xguest_usertype openoffice_exec_t:process xguest_openoffice_t; <br /> ..<br /> role xguest_r types xguest_openoffice_t; # Paremeter $3<br /> ....<br /> allow xguest_usertype xguest_openoffice_t:process { signal sigkill };<br /> allow xguest_openoffice_t xguest_usertype:unix_stream_socket connectto;<br /> ##### end openoffice_per_role_template(xguest,xguest_usertype,xguest_r)<br /> <br /> } # end optional<br /> &lt;/pre&gt;<br /> <br /> === Miscellaneous Macros ===<br /> These macros are in the &lt;tt&gt;misc_macros.spt&lt;/tt&gt; file.<br /> <br /> ==== gen_context Macro ====<br /> This macro is used to generate a valid security context and can be used in any of the module files. Its most general use is in the &lt;tt&gt;.fc&lt;/tt&gt; file where it is used to set the files security context.<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> gen_context(context[,mls | mcs]) <br /> &lt;/pre&gt;<br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | gen_context<br /> | The &lt;tt&gt;gen_context&lt;/tt&gt; macro keyword.<br /> <br /> |-<br /> | context<br /> | The security context to be generated. This can include macros that are relevant to a context as shown in the example below.<br /> <br /> |-<br /> | mls | mcs<br /> | MLS or MCS labels if enabled in the policy.<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example shows gen_context being used to generate a<br /> # security context for the security initial sid in the <br /> # selinux.te module:<br /> <br /> sid security gen_context(system_u:object_r:security_t:mls_systemhigh)<br /> &lt;/pre&gt;<br /> <br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # This is the expanded entry built into the base.conf source<br /> # file for an MLS policy:<br /> <br /> sid security system_u:object_r:security_t:s15:c0.c255 <br /> &lt;/pre&gt;<br /> <br /> '''Example File Context &lt;tt&gt;.fc&lt;/tt&gt; file:'''<br /> &lt;pre&gt;<br /> # This is from the modules/apps/gnome.fc file. Note that the<br /> # HOME_DIR and USER parameters will be entered during<br /> # the file_contexts.homedirs file build.<br /> #<br /> <br /> HOME_DIR/.gnome2(/.*)?gen_context(system_u:object_r:gnome_home_t,s0)<br /> HOME_DIR/\.config/gtk-.*gen_context(system_u:object_r:gnome_home_t,s0)<br /> HOME_DIR/\.gconf(d)?(/.*)?gen_context(system_u:object_r:gconf_home_t,s0)<br /> HOME_DIR/\.local.*gen_context(system_u:object_r:gconf_home_t,s0)<br /> <br /> /tmp/gconfd-USER/.*--gen_context(system_u:object_r:gconf_tmp_t,s0)<br /> <br /> HOME_DIR/.pulse(/.*)?gen_context(system_u:object_r:gnome_home_t,s0)<br /> &lt;/pre&gt;<br /> <br /> '''Expanded File Context &lt;tt&gt;.fc&lt;/tt&gt; file:'''<br /> &lt;pre&gt;<br /> # The resulting expanded tmp/gnome.mod.fc file. This will be<br /> # concatenated with the main file_contexts file during the<br /> # policy build process.<br /> #<br /> <br /> HOME_DIR/.gnome2(/.*)?system_u:object_r:gnome_home_t:s0<br /> HOME_DIR/\.config/gtk-.*system_u:object_r:gnome_home_t:s0<br /> HOME_DIR/\.gconf(d)?(/.*)?system_u:object_r:gconf_home_t:s0<br /> HOME_DIR/\.local.*system_u:object_r:gconf_home_t:s0<br /> <br /> /tmp/gconfd-USER/.*--system_u:object_r:gconf_tmp_t:s0<br /> HOME_DIR/.pulse(/.*)?system_u:object_r:gnome_home_t:s0<br /> &lt;/pre&gt;<br /> <br /> ==== gen_user Macro ====<br /> This macro is used to generate a valid [[UserStatements | user statement]] and add an entry in the [[PolicyStoreConfigurationFiles#users_extra.2C_users_extra.local_and_users.local_Files | users_extra]] configuration file if it exists.<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> gen_user(username, prefix, role_set, mls_defaultlevel, mls_range, [mcs_categories]) <br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | gen_user<br /> | The &lt;tt&gt;gen_user&lt;/tt&gt; macro keyword.<br /> <br /> |-<br /> | username<br /> | The SELinux user id.<br /> <br /> |-<br /> | prefix<br /> | SELinux users without the prefix will not be in the &lt;tt&gt;users_extra&lt;/tt&gt; file. This is added to user directories by the &lt;tt&gt;genhomedircon&lt;/tt&gt; as discussed in the [[PolicyStoreConfigurationFiles#file_contexts.template_File | modules/active/file_contexts.template]] File section.<br /> <br /> |-<br /> | role_set<br /> | The user roles.<br /> <br /> |-<br /> | mls_defaultlevel<br /> | The default level if MLS / MCS policy.<br /> <br /> |-<br /> | mls_range<br /> | The range if MLS / MCS policy.<br /> <br /> |-<br /> | mcs_categories<br /> | The categories if MLS / MCS policy.<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example has been taken from the policy/policy/users file:<br /> #<br /> gen_user(root, user, unconfined_r sysadm_r staff_r ifdef(`enable_mls',`secadm_r auditadm_r') system_r, s0, s0 - mls_systemhigh, mcs_allcats) <br /> &lt;/pre&gt;<br /> <br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # The expanded gen_user macro from the base.conf for an MLS<br /> # build. Note that the prefix is not present. This is added to<br /> # the users_extra file as shown below.<br /> #<br /> user root roles { unconfined_r sysadm_r staff_r secadm_r auditadm_r system_r } level s0 range s0 - s15:c0.c1023; <br /> &lt;/pre&gt;<br /> &lt;pre&gt;<br /> # users_extra file entry:<br /> #<br /> user root prefix user; <br /> &lt;/pre&gt;<br /> <br /> ==== gen_bool Macro ====<br /> This macro defines a boolean and requires the following steps:<br /> <br /> # Declare the boolean in the global_booleans file.<br /> # Use the boolean in the module files with an if Statement as shown in the example.<br /> <br /> Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[NB_RefPolicy#Reference Policy Documentation | documentation]].<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> gen_bool(name,default_value) <br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | gen_bool<br /> | The &lt;tt&gt;gen_bool&lt;/tt&gt; macro keyword.<br /> <br /> |-<br /> | name<br /> | The boolean identifier.<br /> <br /> |-<br /> | default_value<br /> | The value &lt;tt&gt;true&lt;/tt&gt; or &lt;tt&gt;false&lt;/tt&gt;.<br /> <br /> |}<br /> <br /> '''The macro is only valid in in the global_booleans file but the boolean declared can be used in the following module types:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''Yes'''&lt;/center&gt;<br /> | &lt;center&gt;'''No'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro (in global_booleans):'''<br /> &lt;pre&gt;<br /> # This example is from the global_booleans file where the bool<br /> # is declared. The comments must be present as it is used to<br /> # generate the documentation.<br /> #<br /> <br /> ## &lt;desc&gt;<br /> ## &lt;p&gt;<br /> ## Disable transitions to insmod.<br /> ## &lt;/p&gt;<br /> ## &lt;/desc&gt;gen_bool(secure_mode_insmod,false)<br /> <br /> # Example usage from the system/modutils.te module:<br /> #<br /> if( ! secure_mode_insmod ) {<br /> kernel_domtrans_to(insmod_t,insmod_exec_t)<br /> }<br /> &lt;/pre&gt;<br /> <br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # This has been taken from the base.conf source file after<br /> # expansion by the build process of the modutils.te module.<br /> #<br /> <br /> if( ! secure_mode_insmod ) {<br /> ##### begin kernel_domtrans_to(insmod_t,insmod_exec_t)<br /> allow kernel_t insmod_exec_t:file { getattr read execute };<br /> allow kernel_t insmod_t:process transition;<br /> dontaudit kernel_t insmod_t:process { noatsecure siginh rlimitinh };<br /> type_transition kernel_t insmod_exec_t:process insmod_t;<br /> allow insmod_t kernel_t:fd use;<br /> allow insmod_t kernel_t:fifo_file { getattr read write append ioctl lock };<br /> allow insmod_t kernel_t:process sigchld;<br /> ##### end kernel_domtrans_to(insmod_t,insmod_exec_t)<br /> }<br /> &lt;/pre&gt;<br /> <br /> === MLS and MCS Macros ===<br /> These macros are in the &lt;tt&gt;mls_mcs_macros.spt&lt;/tt&gt; file.<br /> <br /> ==== gen_cats Macro ====<br /> This macro will generate a category Statement for each category defined. These are then used in the &lt;tt&gt;base.conf&lt;/tt&gt; / &lt;tt&gt;policy.conf&lt;/tt&gt; source file and also inserted into each module by the [[NB_RefPolicy#policy_module_Macro | policy_module Macro]]. The &lt;tt&gt;policy/policy/mcs&lt;/tt&gt; and &lt;tt&gt;mls&lt;/tt&gt; configuration files are the only files that contain this macro in the current reference policy.<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> gen_cats(mcs_num_cats | mls_num_cats)<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | gen_cats<br /> | The &lt;tt&gt;gen_cats&lt;/tt&gt; macro keyword.<br /> <br /> |-<br /> | mcs_num_cats<br /> <br /> mls_num_cats<br /> | These are the maximum number of categories that have been extracted from the &lt;tt&gt;build.conf&lt;/tt&gt; file &lt;tt&gt;MCS_CATS&lt;/tt&gt; or &lt;tt&gt;MLS_CATS&lt;/tt&gt; entries and set as m4 parameters.<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''na'''&lt;/center&gt;<br /> | &lt;center&gt;'''na'''&lt;/center&gt;<br /> | &lt;center&gt;'''na'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the policy/policy/mls configuration file.<br /> #<br /> <br /> gen_cats(mls_num_cats)<br /> &lt;/pre&gt;<br /> <br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # This example has been extracted from the base.conf source<br /> # file.<br /> <br /> category c0;<br /> category c1;<br /> ...<br /> category c1023;<br /> &lt;/pre&gt;<br /> <br /> ==== gen_sens Macro ====<br /> This macro will generate a sensitivity Statement for each sensitivity defined. These are then used in the &lt;tt&gt;base.conf&lt;/tt&gt; / &lt;tt&gt;policy.conf&lt;/tt&gt; source file and also inserted into each module by the [[NB_RefPolicy#policy_module_Macro | policy_module Macro]]. The &lt;tt&gt;policy/policy/mcs&lt;/tt&gt; and &lt;tt&gt;mls&lt;/tt&gt; configuration files are the only files that contain this macro in the current reference policy (note that the &lt;tt&gt;mcs&lt;/tt&gt; file has &lt;tt&gt;gen_sens(1)&lt;/tt&gt; as only one sensitivity is required).<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> gen_sens(mls_num_sens)<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> <br /> {| border=&quot;1&quot;<br /> | gen_sens<br /> | The &lt;tt&gt;gen_sens&lt;/tt&gt; macro keyword.<br /> <br /> |-<br /> | mls_num_sens<br /> | These are the maximum number of sensitivities that have been extracted from the &lt;tt&gt;build.conf&lt;/tt&gt; file &lt;tt&gt;MLS_SENS&lt;/tt&gt; entries and set as an m4 parameter.<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''na'''&lt;/center&gt;<br /> | &lt;center&gt;'''na'''&lt;/center&gt;<br /> | &lt;center&gt;'''na'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the policy/policy/mls configuration file.<br /> #<br /> <br /> gen_cats(mls_num_sens)<br /> &lt;/pre&gt;<br /> <br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # This example has been extracted from the base.conf source<br /> # file.<br /> <br /> sensitivity s0;<br /> sensitivity s1;<br /> ...<br /> sensitivity s15;<br /> &lt;/pre&gt;<br /> <br /> ==== gen_levels Macro ====<br /> This macro will generate a level Statement for each level defined. These are then used in the &lt;tt&gt;base.conf&lt;/tt&gt; / &lt;tt&gt;policy.conf&lt;/tt&gt; source file. The &lt;tt&gt;policy/policy/mcs&lt;/tt&gt; and &lt;tt&gt;mls&lt;/tt&gt; configuration files are the only files that contain this macro in the current reference policy.<br /> <br /> '''The macro definition is:'''<br /> &lt;pre&gt;<br /> gen_levels(mls_num_sens,mls_num_cats)<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> {| border=&quot;1&quot;<br /> | gen_levels<br /> | The &lt;tt&gt;gen_levels&lt;/tt&gt; macro keyword.<br /> <br /> |-<br /> | mls_num_sens<br /> | This is the parameter that defines the number of sensitivities to generate. The MCS policy is set to &quot;&lt;tt&gt;1&lt;/tt&gt;&quot;.<br /> <br /> |-<br /> | mls_num_cats<br /> <br /> mcs_num_cats<br /> | This is the parameter that defines the number of categories to generate.<br /> <br /> |}<br /> <br /> '''The macro is valid in:'''<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;Private Policy File (.te)&lt;/center&gt;<br /> | &lt;center&gt;External Interface File (.if)&lt;/center&gt;<br /> | &lt;center&gt;File Labeling Policy File (.fc)&lt;/center&gt;<br /> <br /> |-<br /> | &lt;center&gt;'''na'''&lt;/center&gt;<br /> | &lt;center&gt;'''na'''&lt;/center&gt;<br /> | &lt;center&gt;'''na'''&lt;/center&gt;<br /> <br /> |}<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the policy/policy/mls configuration file.<br /> #<br /> gen_levels(mls_num_sens,mls_num_cats)<br /> &lt;/pre&gt;<br /> <br /> '''Expanded Macro:'''<br /> &lt;pre&gt;<br /> # This example has been extracted from the base.conf source<br /> # file. Note that the all categories are allocated to each<br /> # sensitivity.<br /> <br /> level s0:c0.c1023; <br /> level s1:c0.c1023; <br /> ...<br /> level s15:c0.c1023; <br /> &lt;/pre&gt;<br /> <br /> ==== System High/Low Parameters ====<br /> These macros define system high etc. as shown.<br /> &lt;pre&gt;<br /> mls_systemlow<br /> # gives:<br /> s0<br /> <br /> mls_systemhigh<br /> # gives:<br /> s15:c0.c1023 <br /> <br /> mcs_systemlow<br /> # gives:<br /> s0<br /> <br /> mcs_systemhigh<br /> # gives:<br /> s0:c0.c1023<br /> <br /> mcs_allcats<br /> # gives:<br /> c0.c1023<br /> &lt;/pre&gt;<br /> <br /> === ifdef / ifndef Parameters ===<br /> This section contains examples of the common &lt;tt&gt;ifdef&lt;/tt&gt; / &lt;tt&gt;ifndef&lt;/tt&gt; parameters that can be used in module source files. <br /> <br /> ==== hide_broken_symptoms ====<br /> This is used within modules as shown in the example. The parameter is set up by the &lt;tt&gt;Makefile&lt;/tt&gt; at the start of the build process.<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the modules/kernel/domain.te module.<br /> #<br /> ifdef(`hide_broken_symptoms',`<br /> cron_dontaudit_rw_tcp_sockets(domain)<br /> allow domain domain:key { link search };<br /> ')<br /> &lt;/pre&gt;<br /> <br /> ==== enable_mls and enable_mcs ====<br /> These are used within modules as shown in the example. The parameters are set up by the &lt;tt&gt;Makefile&lt;/tt&gt; with information taken from the &lt;tt&gt;build.conf&lt;/tt&gt; file at the start of the build process.<br /> <br /> '''Example Macros:'''<br /> &lt;pre&gt;<br /> # This example is from the modules/kernel/kernel.te module.<br /> #<br /> ifdef(`enable_mls',`<br /> role secadm_r;<br /> role auditadm_r;<br /> ')<br /> &lt;/pre&gt;<br /> &lt;pre&gt;<br /> # This example is from the modules/kernel/kernel.if module.<br /> #<br /> ifdef(`enable_mcs',`<br /> range_transition kernel_t $2:process $3;<br /> ')<br /> <br /> ifdef(`enable_mls',`<br /> range_transition kernel_t $2:process $3;<br /> mls_rangetrans_target($1)<br /> ')<br /> &lt;/pre&gt;<br /> <br /> ==== enable_ubac ====<br /> This is used within the &lt;tt&gt;./policy/constraints&lt;/tt&gt; configuration file to set up various attributes to support user based access control (UBAC). These attributes are then used within the various modules that want to support UBAC. This support was added in version 2 of the Referefence Policy. <br /> <br /> The orginal method (role based access control, or RBAC) is the default for F-12 (&lt;tt&gt;ubac = n&lt;/tt&gt;). The parameter is set up by the &lt;tt&gt;Makefile&lt;/tt&gt; with information taken from the &lt;tt&gt;build.conf&lt;/tt&gt; file at the start of the build process (&lt;tt&gt;ubac = y | ubac = n&lt;/tt&gt;).<br /> <br /> '''Example Macro:'''<br /> &lt;pre&gt;<br /> # This example is from the ./policy/constraints file.<br /> # Note that the ubac_constrained_type attribute is defined in<br /> # modules/kernel/ubac.te module.<br /> <br /> define(`basic_ubac_conditions',`<br /> ifdef(`enable_ubac',`<br /> u1 == u2<br /> or u1 == system_u<br /> or u2 == system_u<br /> or t1 != ubac_constrained_type<br /> or t2 != ubac_constrained_type<br /> ')<br /> ')<br /> &lt;/pre&gt;<br /> <br /> ==== direct_sysadm_daemon ====<br /> This is used within modules as shown in the example. The parameter is set up by the &lt;tt&gt;Makefile&lt;/tt&gt; with information taken from the &lt;tt&gt;build.conf&lt;/tt&gt; file at the start of the build process (if &lt;tt&gt;DIRECT_INITRC = y&lt;/tt&gt;).<br /> <br /> '''Example Macros:'''<br /> &lt;pre&gt;<br /> # This example is from the modules/system/selinuxutil.te module.<br /> #<br /> ifndef(`direct_sysadm_daemon',`<br /> ifdef(`distro_gentoo',`<br /> # Gentoo integrated run_init:<br /> init_script_file_entry_type(run_init_t)<br /> ')<br /> ')<br /> &lt;/pre&gt;<br /> &lt;pre&gt;<br /> # This example is from the modules/system/userdomain.te module.<br /> #<br /> ifdef(`direct_sysadm_daemon',`<br /> domain_system_change_exemption($1_t)<br /> ')<br /> &lt;/pre&gt;<br /> <br /> <br /> == Module Expansion Process ==<br /> The objective of this section is to show how the modules are expanded by the reference policy build process to form files that can then be compiled and then loaded into the policy store by using the &lt;tt&gt;make MODULENAME.pp&lt;/tt&gt; target.<br /> <br /> The files shown are those produced by the build process using the ada policy modules from the Reference Policy source tree (&lt;tt&gt;ada.te&lt;/tt&gt;, &lt;tt&gt;ada.if&lt;/tt&gt; and &lt;tt&gt;ada.fc&lt;/tt&gt;) that are shown in the [[NB_RefPolicy#Reference_Policy_Module_Files | Reference Policy Module Files]] section.<br /> <br /> The initial build process will build the source text files in the &lt;tt&gt;policy/tmp&lt;/tt&gt; directory as &lt;tt&gt;ada.tmp&lt;/tt&gt; and &lt;tt&gt;ada.mod.fc&lt;/tt&gt; (that are basically build equivalent &lt;tt&gt;ada.conf&lt;/tt&gt; and &lt;tt&gt;ada.fc&lt;/tt&gt; formatted files). The basic steps are shown in [http://taiga.selinuxproject.org/~rhaines/diagrams/5-6-ada-process.png The &lt;tt&gt;make ada&lt;/tt&gt; sequence of events] diagram, and the resulting expanded code shown in [http://taiga.selinuxproject.org/~rhaines/diagrams/5-7-resulting-code.png The Resulting Code] diagram. The actual module expansion is left to the reader to investigate.<br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_RBAC NB RBAC 2010-09-13T20:49:12Z <p>Jaxelson: </p> <hr /> <div>= Role-Based Access Control (RBAC) =<br /> To further control access to TE domains SELinux makes use of role-based access control (RBAC). This feature allows SELinux users to be associated to one or more roles, where each role is then associated to one or more domain types as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/4-RBAC.png Role Based Access Control] diagram. Note that GNU / Linux users are not a direct part of the RBAC feature, they are associated to SELinux users via SELinux specific commands&lt;ref name=&quot;ftn6&quot;&gt;&lt;sup&gt;There are other SELinux utilities that can manage users etc., however this Notebook will only use the core utilities.&lt;/sup&gt;&lt;/ref&gt; such as:<br /> <br /> * '''semanage login'''- That manages the association of GNU / Linux users (or groups of users) to SELinux users.<br /> <br /> * '''semanage user''' - That manages the association of SELinux users to roles. <br /> <br /> The [http://taiga.selinuxproject.org/~rhaines/diagrams/4-RBAC.png Role Based Access Control] diagram shows how the SELinux user and roles are associated within the basic loadable modules that form the simple message filter exercise described in Volume 2.<br /> <br /> SELinux users can be equated to groups or classes of user, for example in the Reference Policy there is &lt;tt&gt;user_u&lt;/tt&gt; for general users with &lt;tt&gt;staff_u&lt;/tt&gt; and &lt;tt&gt;sysadm_u&lt;/tt&gt; for more specialised users. There is also a &lt;tt&gt;system_u&lt;/tt&gt; defined that must never be associated to a GNU / Linux user as it a special identity for system processes and objects.<br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_Poly NB Poly 2010-09-13T20:49:03Z <p>Jaxelson: </p> <hr /> <div>= Polyinstantiation =<br /> GNU / Linux supports the polyinstantiation of directories that can be utilised by SELinux via the Pluggable Authentication Module (PAM) that is explained in the next section. The &quot;[http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html Polyinstantiation of directories in an SELinux system]&quot; also gives a more detailed overview of the subject.<br /> <br /> Polyinstantiation of objects is also supported for X-windows selections and properties that are discussed in the X-windows section. Note that sockets are not yet supported.<br /> <br /> To clarify polyinstantiation support:<br /> <br /> # The polyinstantiation of directories is a function of GNU / Linux not SELinux (as more correctly, the GNU / Linux services such as PAM have been modified to support polyinstantiation of directories and have also been made SELinux-aware. Therefore their services can be controlled via policy). <br /> # The polyinstantiation of X-windows selections and properties is a function of the XSELinux Object Manager and the supporting XACE service. These two services are effectively X-windows extensions that can be disabled if required.<br /> # SELinux has a &lt;tt&gt;type_member&lt;/tt&gt; rule that supports polyinstantiated objects. An example using X-windows selections is shown in the Experimenting with X-Windows section of volume 2.<br /> <br /> == Polyinstantiated Objects ==<br /> Polyinstantiation is supported by SELinux using the &lt;tt&gt;type_member rule&lt;/tt&gt;. This statement is not limited to specific object classes, however GNU / Linux currently only supports &lt;tt&gt;dir&lt;/tt&gt;, &lt;tt&gt;x_selection&lt;/tt&gt; and &lt;tt&gt;x_property&lt;/tt&gt; objects.<br /> <br /> The following libselinux API functions support polyinstantiation as detailed in the [[LibselinuxAPISummary | API Summary for libselinux]] section:<br /> &lt;pre&gt;<br /> avc_compute_member<br /> security_compute_member<br /> security_compute_member_raw<br /> &lt;/pre&gt;<br /> <br /> == Polyinstantiation support in PAM ==<br /> PAM supports polyinstantiation of directories at login time using the Shared Subtree / Namespace services available within GNU / Linux (the namespace.conf(5) man page is also a good reference). Note that PAM and Namespace services are SELinux-aware.<br /> <br /> The default installation of F-12 does not enable polyinstantiated directories, therefore this section will show the configuration required to enable the feature and some configuration examples.<br /> <br /> To implement polyinstantiated directories PAM requires the following files to be configured:<br /> <br /> * A pam_namespace module entry added to the appropriate /etc/pam.d/ login configuration file (e.g. login, sshd, gdm etc.). F-12 already has these entries configured, with an example /etc/pam.d/gdm file being:<br /> &lt;pre&gt;<br /> #%PAM-1.0<br /> auth [success=done ignore=ignore default=bad] pam_selinux_permit.so<br /> # auth required pam_succeed_if.so user != root quiet<br /> auth required pam_env.so<br /> auth substack system-auth<br /> auth optional pam_gnome_keyring.so<br /> account required pam_nologin.so<br /> account include system-auth<br /> password include system-auth<br /> session required pam_selinux.so close<br /> session required pam_loginuid.so<br /> session optional pam_console.so<br /> session required pam_selinux.so open<br /> session optional pam_keyinit.so force revoke<br /> session required pam_namespace.so<br /> session optional pam_gnome_keyring.so auto_start<br /> session include system-auth<br /> &lt;/pre&gt;<br /> <br /> * Entries added to the &lt;tt&gt;/etc/security/namespace.conf&lt;/tt&gt; file that defines the directories to be polyinstantiated by PAM (and other services that may need to use the namespace service). The entries are explained in the namespace.conf section, with the default entries in F-12 being (note that the entries are commented out in the distribution):<br /> &lt;pre&gt;<br /> #polydir instance-prefix method list_of_uids<br /> /tmp /tmp-inst/ level root,adm<br /> /var/tmp /var/tmp/tmp-inst/ level root,adm<br /> $HOME $HOME/$USER.inst/ level<br /> &lt;/pre&gt;<br /> <br /> Once these files have been configured and a user logs in (although not root or adm in the above example), the PAM pam_namespace module would unshare the current namespace from the parent and mount namespaces according to the rules defined in the namespace.conf file. The F-12 configuration also includes an &lt;tt&gt;/etc/security/namespace.init&lt;/tt&gt; script that is used to initialise the namespace every time a new directory instance is set-up. This script receives four parameters: the polyinstantiated directory path, the instance directory path, a flag to indicate if new instance, and the user name. If a new instance is being set up, the directory permissions are set and the &lt;tt&gt;restorecon(8)&lt;/tt&gt; command is run to set the correct file contexts.<br /> <br /> === namespace.conf Configuration File ===<br /> Each line in the namespace.conf file is formatted as follows:<br /> &lt;pre&gt;<br /> polydir instance_prefix method list_of_uids<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> {| border=&quot;1&quot;<br /> | &lt;tt&gt;polydir&lt;/tt&gt;<br /> | The absolute path name of the directory to polyinstantiate. The optional strings &lt;tt&gt;$USER&lt;/tt&gt; and &lt;tt&gt;$HOME&lt;/tt&gt; will be replaced by the user name and home directory respectively.<br /> <br /> |-<br /> | &lt;tt&gt;instance_prefix&lt;/tt&gt;<br /> | A string prefix used to build the pathname for the polyinstantiated directory. The optional strings $USER and $HOME will be replaced by the user name and home directory respectively.<br /> <br /> |-<br /> | &lt;tt&gt;method&lt;/tt&gt;<br /> | This is used to determine the method of polyinstantiation with valid entries being:<br /> <br /> user - Polyinstantiation is based on user name.<br /> <br /> level - Polyinstantiation is based on the user name and MLS level.<br /> <br /> context - Polyinstantiation is based on the user name and security context.<br /> <br /> Note that level and context are only valid for SELinux enabled systems.<br /> <br /> |-<br /> | &lt;tt&gt;list_of_uids&lt;/tt&gt;<br /> | A comma separated list of user names that will not have polyinstantiated directories. If blank, then all users are polyinstantiated. If the list is preceded with an &quot;~&quot; character, then only the users in the list will have polyinstantiated directories.<br /> <br /> There are a number of optional flags available that are described in the &lt;tt&gt;namespace.conf(5)&lt;/tt&gt; man page.<br /> <br /> |}<br /> <br /> <br /> === Example Configurations ===<br /> This section shows two sample namespace.conf configurations, the first uses the method=user and the second method=context. It should be noted that while polyinstantiation is enabled, the full path names will not be visible, it is only when polyinstantiation is disabled that the directories become visible.<br /> <br /> '''Example 1 - method=user:'''<br /> * Set the /etc/security/namespace.conf entries as follows:<br /> &lt;pre&gt;<br /> #polydir instance-prefix method list_of_uids<br /> /tmp /tmp-inst/ user root,adm<br /> /var/tmp /var/tmp/tmp-inst/ user root,adm<br /> $HOME $HOME/$USER.inst/ user<br /> &lt;/pre&gt;<br /> <br /> * Login as a normal user (rch in this example) and the PAM / Namespace process will build the following polyinstantiated directories:<br /> &lt;pre&gt;<br /> # The directories will contain the user name as a part of <br /> # the polyinstantiated directory name as follows:<br /> <br /> # /tmp<br /> /tmp/tmp-inst/rch<br /> <br /> # /var/tmp:<br /> /var/tmp/tmp-inst/rch<br /> <br /> # $HOME<br /> /home/rch/rch.inst/rch<br /> &lt;/pre&gt;<br /> <br /> '''Example 2 - method=context:'''<br /> * Set the /etc/security/namespace.conf entries as follows:<br /> &lt;pre&gt;<br /> #polydir instance-prefix method list_of_uids<br /> /tmp /tmp-inst/ context root,adm<br /> /var /tmp /var/tmp/tmp-inst/ context root,adm<br /> $HOME $HOME/$USER.inst/ context<br /> &lt;/pre&gt;<br /> <br /> * Login as a normal user (rch in this example) and the PAM / Namespace process will build the following polyinstantiated directories:<br /> &lt;pre&gt;<br /> # The directories will contain the security context and <br /> # user name as a part of the polyinstantiated directory <br /> # name as follows:<br /> <br /> # /tmp<br /> /tmp/tmp-inst/user_u:unconfined_r:unconfined_t_rch<br /> <br /> # /var/tmp:<br /> /var/tmp/tmp-inst/user_u:unconfined_r:unconfined_t_rch<br /> <br /> # $HOME<br /> /home/rch/rch.inst/user_u:unconfined_r:unconfined_t_rch<br /> &lt;/pre&gt;<br /> <br /> <br /> == Polyinstantiation support in X-Windows ==<br /> The X-windows SELinux object manager and XACE (X Access Control Extension) supports &lt;tt&gt;x_selection&lt;/tt&gt; and &lt;tt&gt;x_property&lt;/tt&gt; polyinstantiated objects as discussed in the [[NB_XWIN | SELinux X-Windows Support]] section.<br /> <br /> == Polyinstantiation support in the Reference Policy ==<br /> The reference policy &lt;tt&gt;files.te&lt;/tt&gt; and &lt;tt&gt;files.if&lt;/tt&gt; modules (in the kernel layer) support polyinstantiated directories. There is also a global tunable (a boolean called &lt;tt&gt;allow_polyinstantiation&lt;/tt&gt;) that can be used to set this functionality on or off during login. By default this boolean is set &lt;tt&gt;false&lt;/tt&gt; (off).<br /> <br /> The polyinstantiation of X-windows objects (&lt;tt&gt;x_selection&lt;/tt&gt; and &lt;tt&gt;x_property&lt;/tt&gt;) are not currently supported by the reference policy, however the Experimenting with X-Windows section in volume 2 shows an &lt;tt&gt;x_selection&lt;/tt&gt; example.<br /> <br /> <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_PolicyType NB PolicyType 2010-09-13T20:48:53Z <p>Jaxelson: </p> <hr /> <div>= Types of SELinux Policy =<br /> This section describes the different type of policy descriptions and versions that can be found within SELinux.<br /> <br /> The types of SELinux policy can described in a number of ways:<br /> <br /> # Source code - These can be described as: Example, Reference Policy or Custom.<br /> # The source code descriptions or builds can also be sub-classified as: Monolithic, Base Module or Loadable Module.<br /> # Policies can also be described by the type of policy functionality they provide such as: targeted, mls, mcs, standard, strict or minimum.<br /> # Classified using language statements - These can be described as Modular, Optional or Conditional.<br /> # Binary policy (or kernel policy) - These can be described as Monolithic, Kernel Policy or Binary file.<br /> # Classification can also be on the &quot;policy version&quot; used (examples are version 22, 23 and 24).<br /> <br /> As can be seen the description of a policy can vary depending on the context.<br /> <br /> == Example Policy ==<br /> The Example policy is the name used to describe the original SELinux policy source used to build a monolithic&lt;ref name=&quot;ftn14&quot;&gt;&lt;sup&gt;The term &quot;monolithic&quot; generally means a single policy source is used to create the binary policy file that is then loaded as the &quot;policy&quot; using the &lt;tt&gt;checkpolicy(8)&lt;/tt&gt; command. However the term is sometimes used to refer to the binary policy file (as it is one file that describes the policy).&lt;/sup&gt;&lt;/ref&gt; policy produced by the NSA and is now superseded by the Reference Policy.<br /> <br /> == Reference Policy ==<br /> Note that this section only gives an introduction to the reference policy, the installation, configuration and building of a policy using the source code is contained in the Reference Policy.<br /> <br /> The Reference Policy is now the standard policy source used to build SELinux policies, and its main aim is to provide a single source tree with supporting documentation that can be used to build policies for different purposes such as: confining important daemons, supporting MLS / MCS and locking down systems so that all processes are under SELinux control. <br /> <br /> The Reference Policy is now used by all major distributions of SELinux, however each distribution makes its own specific changes to support their &quot;version of the Reference Policy&quot;. For example, the F-12 distribution is based on a specific build of the standard Reference Policy that is then modified and distributed by Red Hat as an RPM. The release numbers will vary however this Notebook uses:<br /> <br /> &lt;tt&gt;'''selinux-policy-3.6.32-103.fc12.src.rpm'''&lt;/tt&gt;<br /> <br /> For information, the policy RPMs installed on the authors test machine for F-12 are as follows:<br /> &lt;pre&gt;<br /> selinux-policy-3.6.32-103.fc12.noarch<br /> selinux-policy-doc-3.6.32-103.fc12.noarch<br /> selinux-policy-minimum-3.6.32-103.fc12.noarch<br /> selinux-policy-mls-3.6.32-103.fc12.noarch<br /> selinux-policy-targeted-3.6.32-103.fc12.noarch<br /> &lt;/pre&gt;<br /> <br /> === Policy Functionality Based on Name or Type ===<br /> Generally a policy is installed with a given name such as targeted, mls, refpolicy or minimum that attempts to describes its functionality. This name then normally becomes the entry in: <br /> <br /> # The directory pointing to the policy location (e.g. if the name is &lt;tt&gt;targeted&lt;/tt&gt;, then the policy will be installed in &lt;tt&gt;/etc/selinux/targeted&lt;/tt&gt;).<br /> # The &lt;tt&gt;SELINUXTYPE&lt;/tt&gt; entry in the &lt;tt&gt;/etc/selinux/config&lt;/tt&gt; file when it is the active policy (e.g. if the name is &lt;tt&gt;targeted&lt;/tt&gt;, then a &lt;tt&gt;SELINUXTYPE=targeted&lt;/tt&gt; entry would be in the &lt;tt&gt;/etc/selinux/config&lt;/tt&gt; file).<br /> <br /> This is how the reference policies distributed with F-12 are named, where:<br /> <br /> : &lt;tt&gt;minimum&lt;/tt&gt; - supports a minimal set of confined daemons within their own domains. The remainder run in the unconfined_t space. Red Hat pre-configure MCS support within this policy.<br /> <br /> : &lt;tt&gt;targeted&lt;/tt&gt; - supports a greater number of confined daemons and can also confine other areas and users (this targeted version also supports the older &quot;strict&quot; version). Red Hat pre-configure MCS support within this policy.<br /> <br /> : &lt;tt&gt;mls&lt;/tt&gt; - supports server based MLS systems.<br /> <br /> The Reference Policy also has a &lt;tt&gt;TYPE&lt;/tt&gt; description that describes the type of policy being built by the build process, these are:<br /> <br /> : &lt;tt&gt;standard&lt;/tt&gt; - supports confined daemons and can also confine other areas and users (this is an amalgamated version of the older &quot;targeted&quot; and &quot;strict&quot; versions).<br /> <br /> : &lt;tt&gt;mcs&lt;/tt&gt; - As standard but supports MCS labels.<br /> <br /> : &lt;tt&gt;mls&lt;/tt&gt; - supports MLS labels as discussed in the [[NB_MLS | Multi-Level Security and Multi-Category Security]] section.<br /> <br /> The &lt;tt&gt;NAME&lt;/tt&gt; and &lt;tt&gt;TYPE&lt;/tt&gt; entries are defined in the reference policy &lt;tt&gt;build.conf&lt;/tt&gt; file that is described in the [[NB_RefPolicy | Reference Policy Support]] section. <br /> <br /> == Custom Policy ==<br /> This generally refers to a policy source that is either:<br /> <br /> # A customised version of the Example policy.<br /> # A customised version of the Reference Policy (i.e. not the standard distribution version).<br /> # A policy that has been built using the language statements to build a specific policy such as those shown in the Building a Basic Policy section of volume 2.<br /> <br /> == Monolithic Policy ==<br /> A Monolithic policy is an SELinux policy that is compiled from one source file called &lt;tt&gt;policy.conf&lt;/tt&gt; (i.e. it does not use the Loadable Module Policy statements and infrastructure which therefore makes it suitable for embedded systems as there is no policy store overhead). <br /> <br /> An example monolithic policy is the NSAs original Example Policy. A simple monolithic policy is shown in Volume 2.<br /> <br /> Monolithic policies are compiled using the &lt;tt&gt;checkpolicy(8)&lt;/tt&gt; SELinux command. <br /> <br /> The Reference Policy supports the building of monolithic policies.<br /> <br /> In some cases the policy binary file is also called a monolithic policy.<br /> <br /> == Loadable Module Policy ==<br /> The loadable module infrastructure allows policy to be managed on a modular basis, in that there is a base policy module that contains all the core components of the policy (i.e. the policy that should always be present), and zero or more modules that can be loaded and unloaded as required (for example if there is a module to enforce policy for ftp, but ftp is not used, then that module could be unloaded).<br /> <br /> There are number of components that form the infrastructure:<br /> <br /> # Policy source code that is constructed for a modular policy with a base module and optional loadable modules.<br /> # Utilities to compile and link modules and place them into a &quot;policy store&quot;.<br /> # Utilities to manage the modules and associated configuration files within the &quot;policy store&quot;.<br /> <br /> The [http://taiga.selinuxproject.org/~rhaines/diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram shows these components along the top of the diagram. The files contained in the policy store are detailed in the [[PolicyStoreConfigurationFiles | Policy Store Configuration Files]] section.<br /> <br /> The policy language was extended to handle loadable modules as detailed in the [[PolicyStatements | Policy Support Statements]] section. For a detailed overview on how the modular policy is built into the final binary policy for loading into the kernel, see the &quot;[http://securityblog.org/brindle/2006/07/05/selinux-policy-module-primer/ SELinux Policy Module Primer]&quot;.<br /> <br /> === Optional Policy ===<br /> The loadable module policy infrastructure supports an &lt;tt&gt;optional&lt;/tt&gt; policy statement that allows policy rules to be defined but only enabled in the binary policy once the conditions have been satisfied. The example loadable modules shown in the Building a Basic Policy section of volume 2 use this feature.<br /> <br /> == Conditional Policy ==<br /> Conditional policies can be implemented in monolithic or loadable module policies and allow policy to be enabled or not depending on the state of a boolean flag. This is often used to enable or disable features within the policy (i.e. change the policy enforcement rules).<br /> <br /> The boolean flag status is held in kernel and can be changed using the &lt;tt&gt;setsebool(8)&lt;/tt&gt; command either persistently across system re-boots or temporarily (i.e. only valid until a re-boot). The following example shows a persistent conditional policy change:<br /> &lt;pre&gt;<br /> setsebool -P ext_gateway_audit=false<br /> &lt;/pre&gt;<br /> <br /> The conditional policy language statements are the [[ConditionalStatements | bool]] Statement that defines the boolean flag identifier and its initial status, and the [[ConditionalStatements | if]] that allows certain rules to be executed depending on the state of the boolean value or values.<br /> <br /> == Binary Policy ==<br /> The binary policy is the policy file that is loaded into the kernel and is always located at /etc/selinux/&lt;policy_name&gt;/policy and is called policy.&lt;version&gt;. Where &lt;policy_name&gt; is the policy name specified in the SELinux configuration file &lt;tt&gt;/etc/selinux/config&lt;/tt&gt; and &lt;version&gt; is the SELinux policy version supported by the kernel and SELinux tools.<br /> <br /> The binary policy can be built from source files supplied by the Example Policy, the Reference Policy or custom built source files as described in the Building a Basic Policy section of volume 2.<br /> <br /> An example /etc/selinux/config file is shown below where the &lt;tt&gt;'''SELINUXTYPE=targeted'''&lt;/tt&gt; entry identifies the &lt;tt&gt;&lt;nowiki&gt;&lt;policy_name&gt;&lt;/nowiki&gt;&lt;/tt&gt; that will be used to locate and load the active policy:<br /> &lt;pre&gt;<br /> SELINUX=permissive<br /> SELINUXTYPE=targeted<br /> &lt;/pre&gt;<br /> <br /> From the above example, the actual binary policy file would be located at &lt;tt&gt;/etc/selinux/targeted/policy&lt;/tt&gt; and be called policy.24 (as version 24 is supported by F-12):<br /> &lt;pre&gt;<br /> /etc/selinux/targeted/policy/policy.24<br /> &lt;/pre&gt;<br /> <br /> == Policy Versions ==<br /> SELinux has a policy database (built by the &lt;tt&gt;libsepol&lt;/tt&gt; library) that describes the format of data held within a binary policy, however, if any new features are added to SELinux (generally language extensions) this can result in a change to the policy database. Whenever the policy database is updated, the policy version is incremented. <br /> <br /> The &lt;tt&gt;sestatus(8)&lt;/tt&gt; command will show the current policy version number in its output as follows:<br /> &lt;pre&gt;<br /> SELinux status: enabled<br /> SELinuxfs mount: /selinux<br /> Current mode: enforcing<br /> Mode from config file: permissive<br /> Policy version: 24<br /> Policy from config file: modular-test<br /> &lt;/pre&gt;<br /> <br /> The F-12 policy version is &quot;24&quot; with Table 3 describing the different versions. There is also another version that applies to the modular policy, however the main policy database version is the one that is generally quoted (some SELinux utilities (e.g. apol) give both version numbers).<br /> <br /> {| border=&quot;1&quot;<br /> | '''''policy db Version'''''<br /> | '''''modular db Version'''''<br /> | '''''Description'''''<br /> <br /> |-<br /> | &lt;center&gt;15&lt;/center&gt;<br /> | &lt;center&gt;4&lt;/center&gt;<br /> | The base version when SELinux was merged into the kernel.<br /> <br /> |-<br /> | &lt;center&gt;16&lt;/center&gt;<br /> | &lt;center&gt;-&lt;/center&gt;<br /> | Added Conditional Policy support (the bool feature).<br /> <br /> |-<br /> | &lt;center&gt;17&lt;/center&gt;<br /> | &lt;center&gt;-&lt;/center&gt;<br /> | Added support for IPv6.<br /> <br /> |-<br /> | &lt;center&gt;18&lt;/center&gt;<br /> | &lt;center&gt;-&lt;/center&gt;<br /> | Added Netlink support.<br /> <br /> |-<br /> | &lt;center&gt;19&lt;/center&gt;<br /> | &lt;center&gt;5&lt;/center&gt;<br /> | Added MLS support, plus the validatetrans Statement.<br /> <br /> |-<br /> | &lt;center&gt;20&lt;/center&gt;<br /> | &lt;center&gt;-&lt;/center&gt;<br /> | Reduced the size of the access vector table.<br /> <br /> |-<br /> | &lt;center&gt;21&lt;/center&gt;<br /> | &lt;center&gt;6&lt;/center&gt;<br /> | Added support for the MLS range_transition Statement.<br /> <br /> |-<br /> | &lt;center&gt;22&lt;/center&gt;<br /> | &lt;center&gt;7&lt;/center&gt;<br /> | Added policy capabilities. Allows various kernel options to be enabled as described in the [[NB_LSM | SELinux Filesystem]] section.<br /> <br /> |-<br /> | &lt;center&gt;23&lt;/center&gt;<br /> | &lt;center&gt;8&lt;/center&gt;<br /> | Added support for the permissive Statement. This allows a module to run in permissive mode while the others are still confined (instead of the all or nothing set by the &lt;tt&gt;SELINUX&lt;/tt&gt; entry in the /etc/selinux/config file).<br /> <br /> |-<br /> | &lt;center&gt;24&lt;/center&gt;<br /> | &lt;center&gt;9 / 10&lt;/center&gt;<br /> | Add support for the &lt;tt&gt;typebounds&lt;/tt&gt; Statement. This was added to support a hierarchical relationship between two domains in multi-threaded web servers as described in &quot;[http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf A secure web application platform powered by SELinux]&quot;.<br /> <br /> |}<br /> ''Table 1: Policy version descriptions ''<br /> <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_PandE NB PandE 2010-09-13T20:48:42Z <p>Jaxelson: </p> <hr /> <div>= SELinux Permissive and Enforcing Modes =<br /> SELinux has three major modes of operation:<br /> <br /> : '''Enforcing''' - SELinux is enforcing the loaded policy. <br /> <br /> : '''Permissive''' - SELinux has loaded the policy, however it is not enforcing the policy. This is generally used for testing as the audit log will contain the AVC denied messages as defined in the [[NB_AL | Audit Logs]] section. The SELinux utilities such as &lt;tt&gt;audit2allow(1)&lt;/tt&gt; and &lt;tt&gt;audit2why(8)&lt;/tt&gt; can then be used to determine the cause and possible resolution by generating the appropriate allow rules.<br /> <br /> : '''Disabled''' - The SELinux infrastructure (in the kernel) is not loaded.<br /> <br /> These flags are set in the &lt;tt&gt;/etc/selinux/config&lt;/tt&gt; file as described in the [[GlobalConfigurationFiles | Global Configuration Files]] section.<br /> <br /> There is another method for running specific domains in permissive mode using the &lt;tt&gt;permissive&lt;/tt&gt; statement. This can be used directly in a user written loadable module or &lt;tt&gt;semanage(8)&lt;/tt&gt; will generate the appropriate module and load it using the following example command:<br /> &lt;pre&gt;<br /> # This example will add a new module in <br /> # /etc/selinux/&lt;policy_name&gt; # /modules/active/modules/permissive_unconfined_t.pp<br /> # and then reload the policy: <br /> <br /> semanage permissive -a unconfined_t<br /> &lt;/pre&gt;<br /> <br /> The &lt;tt&gt;sestatus(8)&lt;/tt&gt; command will show the current policy mode in its output as follows:<br /> &lt;pre&gt;<br /> SELinux status: enabled<br /> SELinuxfs mount: /selinux<br /> Current mode: permissive<br /> Mode from config file: enforcing<br /> Policy version: 24<br /> Policy from config file: modular-test<br /> &lt;/pre&gt;<br /> <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_PAM NB PAM 2010-09-13T20:48:33Z <p>Jaxelson: </p> <hr /> <div>= PAM Login Process =<br /> Applications used to provide login services (such as &lt;tt&gt;gdm&lt;/tt&gt; and &lt;tt&gt;ssh&lt;/tt&gt;) in F-12 use the PAM (Pluggable Authentication Modules) infrastructure to provide the following services:<br /> <br /> : '''Account Management''' - This manages services such as password expiry, service entitlement (i.e. what services the login process is allowed to access).<br /> <br /> : '''Authentication Management''' - Authenticate the user or subject and set up the credentials. PAM can handle a variety of devices including smart-cards and biometric devices.<br /> <br /> : '''Password Management''' - Manages password updates as needed by the specific authentication mechanism being used and the password policy.<br /> <br /> : '''Session Management''' - Manages any services that must be invoked before the login process completes and / or when the login process terminates. For SELinux this is where hooks are used to manage the domains the subject may enter. <br /> <br /> The &lt;tt&gt;pam&lt;/tt&gt; and &lt;tt&gt;pam.conf&lt;/tt&gt; &lt;tt&gt;man&lt;/tt&gt; pages describe the services and configuration in detail and only a summary is provided here covering the SELinux services.<br /> <br /> The PAM configuration for F-12 is managed by a number of files located in the &lt;tt&gt;/etc/pam.d&lt;/tt&gt; directory which has configuration files for login services such as: &lt;tt&gt;gdm&lt;/tt&gt;, &lt;tt&gt;gdm-autologin&lt;/tt&gt;, &lt;tt&gt;login&lt;/tt&gt;, &lt;tt&gt;remote&lt;/tt&gt; and &lt;tt&gt;sshd&lt;/tt&gt;, and at various points in this Notebook the &lt;tt&gt;gdm&lt;/tt&gt; configuration file has been modified to allow root login and the &lt;tt&gt;pam_namespace.so&lt;/tt&gt; module used to manage polyinstantiated directories for users.<br /> <br /> There are also a number of PAM related configuration files in &lt;tt&gt;/etc/security&lt;/tt&gt;, although only one is directly related to SELinux that is described in the &lt;tt&gt;/etc/security/sepermit.conf File&lt;/tt&gt; section of the [[GlobalConfigurationFiles | Global Configuration Files]].<br /> <br /> The main login service related PAM configuration files (e.g. &lt;tt&gt;gdm&lt;/tt&gt;) consist of multiple lines of information that are formatted as follows:<br /> &lt;pre&gt;<br /> service type control module-path arguments<br /> &lt;/pre&gt;<br /> <br /> Where:<br /> {| border=&quot;1&quot;<br /> | &lt;tt&gt;service&lt;/tt&gt;<br /> | The service name such as &lt;tt&gt;gdm&lt;/tt&gt; and &lt;tt&gt;login&lt;/tt&gt; reflecting the login application. If there is a &lt;tt&gt;/etc/pam.d&lt;/tt&gt; directory, then this is the name of a configuration file name under this directory. Alternatively, a configuration file called &lt;tt&gt;/etc/pam.conf&lt;/tt&gt; can be used. F-12 uses the &lt;tt&gt;/etc/pam.d&lt;/tt&gt; configuration.<br /> <br /> |-<br /> | &lt;tt&gt;type&lt;/tt&gt;<br /> | These are the management groups used by PAM with valid entries being: &lt;tt&gt;account&lt;/tt&gt;, &lt;tt&gt;auth&lt;/tt&gt;, &lt;tt&gt;password&lt;/tt&gt; and &lt;tt&gt;session&lt;/tt&gt; that correspond to the descriptions given above. Where there are multiple entries of the same &quot;&lt;tt&gt;type&lt;/tt&gt;&quot;, the order they appear could be significant.<br /> <br /> |-<br /> | &lt;tt&gt;control&lt;/tt&gt;<br /> | This entry states how the module should behave when the requested task fails. There can be two formats: a single keyword such as r&lt;tt&gt;equired&lt;/tt&gt;, &lt;tt&gt;optional&lt;/tt&gt;, and &lt;tt&gt;include&lt;/tt&gt;; or multiple space separated entries enclosed in square brackets consisting of :<br /> &lt;pre&gt;<br /> [value1=action1 value2=action2 ..]<br /> &lt;/pre&gt;<br /> <br /> Both formats are shown in the example file below, however see the &lt;tt&gt;pam.conf&lt;/tt&gt; &lt;tt&gt;man&lt;/tt&gt; pages for the gory details. <br /> <br /> |-<br /> | &lt;tt&gt;module-path&lt;/tt&gt;<br /> | Either the full path name of the module or its location relative to &lt;tt&gt;/lib/security&lt;/tt&gt; (but does depend on the system architecture).<br /> <br /> |-<br /> | &lt;tt&gt;arguments&lt;/tt&gt;<br /> | A space separated list of the arguments that are defined for the module.<br /> <br /> |}<br /> <br /> <br /> An example PAM configuration file is as follows, although note that the &quot;&lt;tt&gt;service&lt;/tt&gt;&quot; parameter is actually the file name because F-12 uses the &lt;tt&gt;/etc/pam.d&lt;/tt&gt; directory configuration (in this case &lt;tt&gt;gdm&lt;/tt&gt; for the Gnome login service).<br /> &lt;pre&gt;<br /> # /etc/pam.d/gdm configuration rule entry. <br /> # SERVICE = file name (gdm) <br /> <br /> # TYPE CONTROL PATH ARGUMENTS<br /> #%PAM-1.0<br /> auth [success=done ignore=ignore default=bad] pam_selinux_permit.so<br /> # auth required pam_succeed_if.so user != root quiet<br /> auth required pam_env.so<br /> auth substack system-auth<br /> auth optional pam_gnome_keyring.so<br /> account required pam_nologin.so<br /> account include system-auth<br /> password include system-auth<br /> session required pam_selinux.so close<br /> session required pam_loginuid.so<br /> session optional pam_console.so<br /> session required pam_selinux.so open<br /> session optional pam_keyinit.so force revoke<br /> session required pam_namespace.so<br /> session optional pam_gnome_keyring.so auto_start<br /> session include system-auth<br /> &lt;/pre&gt;<br /> <br /> The core services are provided by PAM, however other library modules can be written to manage specific services such as support for SELinux. The SELinux PAM modules use the &lt;tt&gt;libselinux&lt;/tt&gt; API to obtain its configuration information and the three SELinux PAM entries highlighted in the above configuration file perform the following functions:<br /> <br /> : &lt;tt&gt;'''pam_selinux_permit.so'''&lt;/tt&gt; - Allows pre-defined users the ability to logon without a password provided that SELinux is in enforcing mode (see the &lt;tt&gt;/etc/security/sepermit.conf File&lt;/tt&gt; section of the [[GlobalConfigurationFiles | Global Configuration Files]]). <br /> <br /> : &lt;tt&gt;'''pam_selinux.so open'''&lt;/tt&gt; - Allows a security context to be set up for the user at initial logon (as all programs exec'ed from here will use this context). How the context is retrieved is described in the &lt;tt&gt;seusers file&lt;/tt&gt; section of the [[PolicyConfigurationFiles | Policy Configuration Files]].<br /> <br /> : &lt;tt&gt;'''pam_selinux.so close'''&lt;/tt&gt; - This will reset the login programs context to the context defined in the policy.<br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_Overview NB Overview 2010-09-13T20:48:20Z <p>Jaxelson: </p> <hr /> <div>= SELinux Overview =<br /> == Introduction ==<br /> SELinux is the primary Mandatory Access Control (MAC) mechanism built into a number of GNU / Linux distributions. SELinux originally started as the Flux Advanced Security Kernel (FLASK) development by the Utah university Flux team and the US Department of Defence. The development was enhanced by the NSA and released as open source software. The history of SELinux can be found at the [http://www.cs.utah.edu/flux/ Flux] and [http://www.nsa.gov/selinux/ NSA] websites. <br /> <br /> == Core SELinux Components ==<br /> The [http://taiga.selinuxproject.org/~rhaines/diagrams/1-core.png High Level Core SELinux Components] diagram shows a high level view of the SELinux core components that manage enforcement of the policy and comprise of the following:<br /> <br /> # A [[NB_Subjects | subject]] that must be present to cause an action to be taken by an [[NB_Objects | object]] (such as read a file as information only flows when a subject is involved).<br /> # An Object Manager that knows the actions required of the particular resource (such as a file) and can enforce those actions (i.e. allow it to write to a file if permitted by the policy).<br /> # A Security Server that makes decisions regarding the subjects rights to perform the requested action on the object, based on the security policy rules.<br /> # A Security Policy that describes the rules using the SELinux policy language.<br /> # An Access Vector Cache (AVC) that improves system performance by caching security server decisions.<br /> <br /> The [http://taiga.selinuxproject.org/~rhaines/diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram shows a more complex view of kernel and userspace with a number of supporting services which are used to manage the SELinux environment. This diagram will be referenced a number of times to explain areas of SELinux, therefore using the diagram as the reference and starting from the bottom:<br /> <br /> * In the current implementation of SELinux, the security server is embedded in the kernel&lt;ref name=&quot;ftn2&quot;&gt;&lt;sup&gt;There is a project developing a Policy Management Server (PMS) that will utilise a user-space security server, however it is beyond the scope of this Notebook.&lt;/sup&gt;&lt;/ref&gt; with the policy being loaded from userspace via a series of functions contained in a library (&lt;tt&gt;libselinux&lt;/tt&gt;).<br /> <br /> : However the object managers (OM) and access vector cache (AVC) can reside in:<br /> <br /> :: '''kernel space''' - These object manages are for the kernel services such as files, directory, socket, IPC etc. and are provided by hooks into the SELinux sub-system via the Linux Security Module (LSM) framework (shown as LSM Hooks in the diagram) that is discussed in the [[NB_LSM | Linux Security Module(LSM)]] section. The SELinux kernel AVC service is used to cache their requests and the security servers response.<br /> <br /> :: '''userspace''' - These object managers are provided with the application / service that requires support for MAC and are known as &quot;SELinux-aware&lt;ref name=&quot;ftn3&quot;&gt;&lt;sup&gt;Generally this means that they use the services provided by the libselinux library as a minimum.&lt;/sup&gt;&lt;/ref&gt;&quot; applications or services. Examples of these are: X-Windows, D-bus messaging (used by the Gnome desktop), PostgreSQL database, Name Service Cache Daemon (nscd), and the GNU / Linux passwd command. Generally, these OMs use the AVC services built into the SELinux library (&lt;tt&gt;libselinux&lt;/tt&gt;), however they could if required supply their own AVC or not use an AVC at all. <br /> <br /> * The loadable policy (right hand side of the diagram) and its supporting configuration files are contained in the &lt;tt&gt;/etc/selinux&lt;/tt&gt; directory. This directory contains the main SELinux configuration file (&lt;tt&gt;/etc/selinux/config&lt;/tt&gt;) that names the policy to be loaded and the initial status of SELinux at boot time (enforcing&lt;ref name=&quot;ftn4&quot;&gt;&lt;sup&gt;When SELinux is enabled the policy can be running in &quot;permissive mode&quot;, where all accesses are allowed and logged in the audit log, even if they are not permitted by the policy (useful for debugging policy). The policy can also be run in &quot;enforcing mode&quot;, where any access that is not defined in the policy is deigned and an entry placed in the audit log.&lt;/sup&gt;&lt;/ref&gt; the policy or not). The area also holds all policies that can be activated in their respective directories &lt;tt&gt;/etc/selinux/&lt;policy_name&gt;&lt;/tt&gt; (e.g. /etc/selinux/targeted would hold the &quot;targeted&quot; F-12 policy and all its configuration files). All know configuration files for F-12 SELinux are shown in the [[ConfigurationFiles | SELinux Configuration Files]] section. <br /> <br /> * SELinux supports a &quot;modular policy&quot;, this means that a policy does not have to be one large policy, but can be built from modules. A modular policy consists of a base policy that contains the mandatory information (such as object classes, permissions etc.), and zero or more policy modules that generally support a particular application or service. These modules are compiled, linked, and held in a &quot;policy store&quot; where they can be built into a binary format that is then loaded into the security server. The types of policy and their construction are covered in the [[NB_PolicyType | Types of SELinux Policy]] section.<br /> <br /> * To be able to build the policy in the first place, policy source is required (top left hand side of the disgram). This can be supplied in two basic ways: <br /> <br /> ** as source code written using the [[PolicyLanguage | SELinux Policy Language]]. This is how the simple policies have been written to support the examples in this Notebook, however it is not recommended for real-world policy development. <br /> <br /> ** using the Reference Policy that uses high level macros to define policy rules as well as the policy language. This is the standard way policies are now built for SELinux distributions such as F-12.<br /> <br /> * To be able to compile and link the source code and load it into the security server requires a number of tools (top of the diagram).<br /> <br /> * To enable system administrators to manage the policy, the SELinux environment and label file systems also requires tools and modified GNU / Linux commands. <br /> <br /> * To ensure security events are logged, GNU / Linux has an audit service that captures policy violations. The [[NB_AL | Audit Logs]] section describes the format of these AVC security events.<br /> <br /> * SELinux supports network services that are described in the [[NB_Networking | SELinux Networking Support]] section.<br /> <br /> The [[NB_LSM | Linux Security Module and SELinux]] section goes into greater detail of the LSM / SELinux modules with a walk-through of a fork and exec process.<br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_Objects NB Objects 2010-09-13T20:47:38Z <p>Jaxelson: </p> <hr /> <div>= Objects =<br /> Within SELinux an object is a resource such as files, sockets, pipes or network interfaces that are accessed via processes (also known as subjects). These objects are classified according to the resource they provide with access permissions relevant to their purpose (e.g. read, receive and write), and assigned a [[NB_SC | security context]] as described in the following sections.<br /> <br /> == Object Classes and Permissions ==<br /> Each object consists of a class identifier that defines its purpose (e.g. file, socket) along with a set of permissions&lt;ref name=&quot;ftn9&quot;&gt;&lt;sup&gt;Also known in SELinux as Access Vectors (AV).&lt;/sup&gt;&lt;/ref&gt; that describe what services the object can handle (read, write, send etc.). When an object is instantiated it will be allocated a name (e.g. a file could be called config or a socket &lt;tt&gt;my_connection&lt;/tt&gt;) and a security context (e.g. &lt;tt&gt;system_u:object_r:selinux_config_t&lt;/tt&gt;) as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/5-object-class.png Object Class] diagram.<br /> <br /> The objective of the policy is to enable the user of the object (the subject) access to the minimum permissions needed to complete the task (i.e. do not allow write permission if only reading information).<br /> <br /> These object classes and their associated permissions are built into the GNU / Linux kernel and user space object managers by developers and are therefore not generally updated by policy writers. <br /> <br /> The object classes consist of kernel object classes (for handling files, sockets etc.) plus user space object classes used by user space object managers (for services such as the name service cache daemon (nscd), X-Windows and debus). The number of object classes and their permissions can vary depending on the features configured in the GNU / Linux release. The F-12 object classes and permissions are described in [[ObjectClassesPerms | Object Classes and Permissions]].<br /> <br /> == Allowing a Process Access to Resources ==<br /> This is a simple example that attempts to explain two points:<br /> <br /> # How a process is given permission to use an objects resource.<br /> # By using the &quot;process&quot; object class, show that a process can be described as a process or object.<br /> <br /> An SELinux policy contains many rules and statements, the majority of which are &lt;tt&gt;allow&lt;/tt&gt; rules that (simply) allows processes to be given access permissions to an objects resources.<br /> <br /> The following allow rule and [http://taiga.selinuxproject.org/~rhaines/diagrams/6-allow-rule.png the allow rule diagram] illustrates &quot;a process can also be an object&quot; as it allows processes running in the &lt;tt&gt;unconfined_t&lt;/tt&gt; domain, permission to &quot;transition&quot; the external gateway application to the &lt;tt&gt;ext_gateway_t&lt;/tt&gt; domain once it has been executed:<br /> &lt;pre&gt;<br /> allow Rule | source_domain | target_type : class | permission<br /> -----------x----------------x------------------------x--------------<br /> allow unconfined_t ext_gateway_t : process transition;<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> {| border=&quot;1&quot;<br /> | &lt;tt&gt;allow&lt;/tt&gt;<br /> | The SELinux language allow rule.<br /> <br /> |-<br /> | &lt;tt&gt;unconfined_t&lt;/tt&gt;<br /> | The source domain (or subject) identifier - in this case the shell that wants to exec the gateway application.<br /> <br /> |-<br /> | &lt;tt&gt;ext_gateway_t&lt;/tt&gt;<br /> | The target object identifier - the object instance of the gateway application process. <br /> <br /> |-<br /> | &lt;tt&gt;process&lt;/tt&gt;<br /> | The target object class - the &quot;process&quot; object class.<br /> <br /> |-<br /> | &lt;tt&gt;transition&lt;/tt&gt;<br /> | The permission granted to the source domain on the targets object - in this case the &lt;tt&gt;unconfined_t&lt;/tt&gt; domain has transition permission on the &lt;tt&gt;ext_gateway_t&lt;/tt&gt; &quot;process&quot; object.<br /> <br /> |}<br /> <br /> <br /> It should be noted that there is more to a domain transition than described above, for a more detailed explanation, see the [[NB_Objects#Domain_Transition | Domain Transition]] section.<br /> <br /> == Labeling Objects ==<br /> Within a running SELinux enabled GNU / Linux system the labeling of objects is managed by the system and generally unseen by the users (until labeling goes wrong !!). As processes and objects are created and destroyed, they either:<br /> <br /> # Inherit their labels from the parent process.<br /> # The policy type_transition statements allow a different label to be assigned as discussed in the [[NB_Objects#Domain_Transition | Domain and Object Transitions]] section.<br /> # SELinux-aware applications can enforce a new label (with the policies approval of course) using the [[LibselinuxAPISummary | libselinux API]] functions.<br /> # The object manager (OM) can enforce a default label that can either be built into the OM or obtained via a configuration file (such as the X-Windows &lt;tt&gt;x_contexts&lt;/tt&gt; file).<br /> # Use an &quot;initial security identifier&quot; (or initial SID). These are defined in all base and monolithic policies and are used to either set an initial context during the boot process, or if an object requires a default (i.e. the object does not already have a valid context).<br /> <br /> While the majority of objects are managed via the system automatically using either the inherited label or an initial SID as required, there are objects that need to have labels defined for them either by their OM (bullet 4 above) using configuration files&lt;ref name=&quot;ftn10&quot;&gt;&lt;sup&gt;The advantage of defining labels in an OM configuration file and not in the policy language is that the OM can then be used by other security mechanisms (for example NetLabel can be used by the [http://www.schaufler-ca.com/ Simplified Mandatory Access Control Kernel] (SMACK) as this MAC system also hooks into the LSM).&lt;/sup&gt;&lt;/ref&gt; or by using policy language statements. <br /> <br /> The SELinux policy language supports object labeling statements for file and network services that are defined in the [[FileStatements | File System Labeling Statements]] and [[NetworkStatements | Network Labeling Statements]] sections.<br /> <br /> An overview of the process required for labeling files systems that use extended attributes (such as &lt;tt&gt;ext3&lt;/tt&gt; and &lt;tt&gt;ext4&lt;/tt&gt;) is discussed in the next section. <br /> <br /> === Labeling Extended Attribute Filesystems ===<br /> The labeling of file systems that implement extended attributes&lt;ref name=&quot;ftn11&quot;&gt;&lt;sup&gt;These file systems store the security context in an attribute associated with the file.&lt;/sup&gt;&lt;/ref&gt; is supported by SELinux using:<br /> <br /> # The &lt;tt&gt;fs_use_xattr&lt;/tt&gt; statement within the policy to identify what file systems use extended attributes. This statement is used to inform the security server how the file system is labeled.<br /> # A &quot;file contexts&quot; file that defines what the initial contexts should be for each file and directory within the file system. The format of this file is described in the [[PolicyConfigurationFiles | Policy Configuration Files]] &lt;ref name=&quot;ftn12&quot;&gt;&lt;sup&gt;Note that this file contains the contexts of all files in all extended attribute filesystems for the policy. However within a modular policy each module describes its own file context information, that is then used to build this file.&lt;/sup&gt;&lt;/ref&gt; section.<br /> # A method to initialise the filesystem with these extended attributes. This is achieved by SELinux utilities such as &lt;tt&gt;fixfiles(8)&lt;/tt&gt; and &lt;tt&gt;setfiles(8)&lt;/tt&gt;. There are also commands such as &lt;tt&gt;chcon(1)&lt;/tt&gt;, &lt;tt&gt;restorecon(8)&lt;/tt&gt; and &lt;tt&gt;restorecond(8)&lt;/tt&gt; that can be used to relabel files.<br /> <br /> Extended attributes containing the SELinux context of a file can be viewed by the &lt;tt&gt;ls -Z&lt;/tt&gt; or &lt;tt&gt;getfattr(1)&lt;/tt&gt; commands as follows:<br /> &lt;pre&gt;<br /> ls -Z myfile<br /> -rw-r--r-- root root unconfined_u:object_r:admin_home_t:s0 myfile<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> getfattr -n security.selinux &lt;file_name&gt;<br /> <br /> #file_name: rpmbuild<br /> security.selinux=&quot;unconfined_u:object_r:admin_home_t:s0\000&quot;<br /> <br /> # Where -n security.selinux is the name of the attribute and<br /> # rpmbuild is the file name.<br /> # The security context (or label) for the file is:<br /> # system_u:object_r:admin_home_t:s0<br /> &lt;/pre&gt;<br /> <br /> ==== Copying and Moving Files ====<br /> Assuming that the correct permissions have been granted by the policy, the effects on the security context of a file when copied or moved differ as follows:<br /> <br /> * copy a file - takes on label of new directory unless the &lt;tt&gt;-Z&lt;/tt&gt; option is used.<br /> * move a file - retains the label of the file.<br /> <br /> However, if the &lt;tt&gt;restorecond&lt;/tt&gt; daemon is running and the &lt;tt&gt;restorecond.conf&lt;/tt&gt; file is correctly configured, then other security contexts can be associated to the file as it is moved or copied (provided it is a valid context and specified in the &lt;tt&gt;/etc/selinux/&lt;policy_name&gt;/contexts/files/file_contexts&lt;/tt&gt; file.<br /> <br /> The examples below show the effects of copying and moving files:<br /> &lt;pre&gt;<br /> # These are the test files in the /root directory and their current security<br /> # context:<br /> #<br /> -rw-r--r-- root root user_u:object_r:unconfined_t copied-file<br /> -rw-r--r-- root root user_u:object_r:unconfined_t moved-file<br /> <br /> # These are the commands used to copy / move the files:<br /> #<br /> # Standard copy file:<br /> cp copied-file /usr/message_queue/in_queue<br /> <br /> # Copy using -Z to set the files context:<br /> cp -Z user_u:object_r:unconfined_t copied-file /usr/message_queue/in_queue/copied-file-with-Z<br /> <br /> # Standard move file:<br /> mv moved-file /usr/message_queue/in_queue<br /> <br /> # The target directory (/usr/message_queue/in_queue) is label &quot;in_queue_t&quot;.<br /> # The results of &quot;ls -Z&quot; on target the directory are:<br /> #<br /> -rw-r--r-- root root user_u:object_r:in_queue_t copied-file<br /> -rw-r--r-- root root user_u:object_r:unconfined_t copied-file-with-Z<br /> -rw-r--r-- root root user_u:object_r:unconfined_t moved-file<br /> &lt;/pre&gt;<br /> <br /> However, if the restorecond daemon is running:<br /> &lt;pre&gt;<br /> # If the restorecond daemon is running with a restorecond.conf file entry of:<br /> #<br /> /usr/message_queue/in_queue/*<br /> <br /> # AND the file_context file has an entry of:<br /> #<br /> /usr/message_queue/in_queue(/.*)? -- system_u:object_r:in_file_t<br /> <br /> # Then all the entries would be set as follows when the daemon detects the files<br /> # creation:<br /> #<br /> -rw-r--r-- root root user_u:object_r:in_file_t copied-file<br /> -rw-r--r-- root root user_u:object_r:in_file_t copied-file-with-Z<br /> -rw-r--r-- root root user_u:object_r:in_file_t moved-file<br /> <br /> # This is because the restorecond process will set the contexts defined in <br /> # the file_contexts file to the context specified as it is created in the <br /> # new directory.<br /> &lt;/pre&gt;<br /> <br /> This is because the &lt;tt&gt;restorecond&lt;/tt&gt; process will set the contexts defined in the &lt;tt&gt;file_contexts&lt;/tt&gt; file to the context specified as it is created in the new directory.<br /> <br /> == Labeling Subjects ==<br /> On a running GNU / Linux system, processes inherit the security context of the parent process. If the new process being spawned has permission to change its context, then a &quot;type transition&quot; is allowed that is discussed in the [[NB_Objects#Domain_Transition | Domain Transition]] section.<br /> <br /> The [[NB_LSM#Initial Boot - Loading the Policy | Initial Boot - Loading the Policy]] section discusses how GNU / Linux is initialised and the processes labeled for the login process.<br /> <br /> The policy language supports a number of statements to either assign labels to processes such as:<br /> <br /> * &lt;tt&gt;user&lt;/tt&gt;, &lt;tt&gt;role&lt;/tt&gt; and &lt;tt&gt;type&lt;/tt&gt; statements.<br /> <br /> and manage their scope:<br /> <br /> * &lt;tt&gt;role allow&lt;/tt&gt; and &lt;tt&gt;constrain&lt;/tt&gt;<br /> <br /> and manage their transition:<br /> <br /> * &lt;tt&gt;type_transition&lt;/tt&gt;, &lt;tt&gt;role_transition&lt;/tt&gt; and &lt;tt&gt;range_transition&lt;/tt&gt;<br /> <br /> One point to note is that the current Reference Policy does not support role transitions / changes as these are &quot;constrained&quot; by the policy. To change to a different role, the &lt;tt&gt;newrole(1)&lt;/tt&gt; command needs to be used.<br /> <br /> == Object Reuse ==<br /> As GNU / Linux runs, it creates instances of objects and manages the information they contain (read, write, modify etc.) under the control of processes, and at some stage these objects may be deleted or released allowing the resource (such as memory blocks and disk space) to be available for reuse.<br /> <br /> GNU / Linux handles object reuse by ensuring that when a resource is re-allocated, it is cleared. This means that when a process releases an object instance (e.g. release allocated memory back to the pool, delete a directory entry or file), there may be information left behind that could prove useful if harvested. If this should be an issue, then the process itself should clear or shred the information before releasing the object (which can be difficult in some cases unless the source code is available).<br /> <br /> == Domain and Object Transitions ==<br /> This section discusses the &lt;tt&gt;type_transition Statement&lt;/tt&gt; that is used for:<br /> <br /> # Transition a process from one domain to another (a domain transition).<br /> # Transition an object from one type to another (an object transition or relabel).<br /> <br /> These transitions can also be achieved using the [LibselinuxAPISummary | libselinux API] functions, however they are beyond the scope of this Notebook as is dynamically changing a processes security context using the dyntransition permission.<br /> <br /> == Domain Transition ==<br /> A domain transition is where a process in one domain, transitions to another domain (i.e. runs under a different security context). There are two ways a process can request a domain transition in a policy:<br /> <br /> * Using a &lt;tt&gt;type_transition&lt;/tt&gt; statement to perform a domain transition for programs that are not themselves SELinux-aware. This is the most common method and would be in the form of the following statement:<br /> &lt;pre&gt;<br /> type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;<br /> &lt;/pre&gt;<br /> <br /> * SELinux-aware applications can specify the domain of the new process using the [LibselinuxAPISummary | libselinux API] call &lt;tt&gt;setexeccon&lt;/tt&gt;. To achieve this the SELinux-aware application must also have the &lt;tt&gt;setexec&lt;/tt&gt; permission by:<br /> &lt;pre&gt;<br /> allow crond_t self : process setexec;<br /> &lt;/pre&gt;<br /> <br /> However, before any domain transition can take place the policy must specify that:<br /> * The source ''domain ''has permission to ''transition'' into the target domain.<br /> * The application binary file needs to be ''executable'' in the source domain.<br /> * The application binary file needs an ''entry point'' into the target domain.<br /> <br /> The following is a &lt;tt&gt;type_transition&lt;/tt&gt; statement taken from the example loadable module message filter &lt;tt&gt;ext_gateway.conf&lt;/tt&gt; (described in volume 2) that will be used to explain the transition process&lt;ref name=&quot;ftn13&quot;&gt;&lt;sup&gt;For reference, the external gateway uses a server application called &lt;tt&gt;secure_server&lt;/tt&gt; that is transitioned to the &lt;tt&gt;ext_gateway_t&lt;/tt&gt; domain from the &lt;tt&gt;unconfined_t&lt;/tt&gt; domain. The &lt;tt&gt;secure_server&lt;/tt&gt; executable is labeled &lt;tt&gt;secure_services_exec_t&lt;/tt&gt;.&lt;/sup&gt;&lt;/ref&gt;:<br /> &lt;pre&gt;<br /> type_transition | source_domain | target_type : class | target_domain;<br /> ----------------x---------------x-----------------------x----------------------<br /> type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;<br /> &lt;/pre&gt;<br /> <br /> This type_transition statement states that when a ''&lt;tt&gt;process&lt;/tt&gt;'' running in the ''&lt;tt&gt;unconfined_t&lt;/tt&gt;'' domain (the source domain) executes a file labeled ''&lt;tt&gt;secure_services_exec_t&lt;/tt&gt;'', the ''&lt;tt&gt;process&lt;/tt&gt;'' should be changed to ''&lt;tt&gt;ext_gateway_t&lt;/tt&gt;'' (the target domain) if allowed by the policy (i.e. transition from the ''&lt;tt&gt;unconfined_t&lt;/tt&gt;'' domain to the ''&lt;tt&gt;ext_gateway_t&lt;/tt&gt;'' domain).<br /> <br /> However, as stated above to be able to ''&lt;tt&gt;transition&lt;/tt&gt;'' to the ''&lt;tt&gt;ext_gateway_t&lt;/tt&gt;'' domain, the following minimum permissions must be granted in the policy using &lt;tt&gt;allow&lt;/tt&gt; rules], where (note that the bullet numbers correspond to the numbers shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/7-domain-transition.png Domain Transition] diagram):<br /> <br /> 1) The ''&lt;tt&gt;domain&lt;/tt&gt;'' needs permission to ''&lt;tt&gt;transition&lt;/tt&gt;'' into the ''&lt;tt&gt;ext_gateway_t&lt;/tt&gt;'' (target) domain:<br /> &lt;pre&gt;<br /> allow unconfined_t ext_gateway_t : process transition;<br /> &lt;/pre&gt;<br /> <br /> 2) The executable file needs to be ''executable'' in the ''&lt;tt&gt;unconfined_t&lt;/tt&gt;'' (source) domain, and therefore also requires that the file is readable:<br /> &lt;pre&gt;<br /> allow unconfined_t secure_services_exec_t : file { execute read getattr };<br /> &lt;/pre&gt;<br /> <br /> 3) The executable file needs an ''entry point'' into the ''&lt;tt&gt;ext_gateway_t&lt;/tt&gt;'' (target) domain:<br /> &lt;pre&gt;<br /> allow ext_gateway_t secure_services_exec_t : file entrypoint;<br /> &lt;/pre&gt;<br /> <br /> These are shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/7-domain-transition.png Domain Transition] diagram where &lt;tt&gt;unconfined_t&lt;/tt&gt; forks a child process, that then exec's the new program into a new domain called &lt;tt&gt;ext_gateway_t&lt;/tt&gt;. Note that because the &lt;tt&gt;type_transition&lt;/tt&gt; statement is being used, the transition is automatically carried out by the SELinux enabled kernel.<br /> <br /> <br /> === Type Enforcement Rules ===<br /> When building the &lt;tt&gt;ext_gateway.conf&lt;/tt&gt; and &lt;tt&gt;int_gateway.conf&lt;/tt&gt; modules (described in Volume 2) the intention was to have both of these transition to their respective domains via &lt;tt&gt;type_transition&lt;/tt&gt; statements. The &lt;tt&gt;ext_gateway_t&lt;/tt&gt; statement would be:<br /> &lt;pre&gt;<br /> type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;<br /> &lt;/pre&gt;<br /> <br /> and the &lt;tt&gt;int_gateway_t&lt;/tt&gt; statement would be:<br /> &lt;pre&gt;<br /> type_transition unconfined_t secure_services_exec_t : process int_gateway_t;<br /> &lt;/pre&gt;<br /> <br /> However, when linking these two loadable modules into the policy, the following error was given:<br /> &lt;pre&gt;<br /> semodule -v -s modular-test -i int_gateway.pp -i ext_gateway.pp<br /> Attempting to install module 'int_gateway.pp':<br /> Ok: return value of 0.<br /> Attempting to install module 'ext_gateway.pp':<br /> Ok: return value of 0.<br /> Committing changes:<br /> libsepol.expand_terule_helper: conflicting TE rule for (unconfined_t, secure_services_exec_t:process): old was ext_gateway_t, new is int_gateway_t<br /> libsepol.expand_module: Error during expand<br /> libsemanage.semanage_expand_sandbox: Expand module failed<br /> semodule: Failed!<br /> &lt;/pre&gt;<br /> <br /> This happened because the type enforcement rules will only handle a single &quot;default&quot; type for a given source and target. In the above case there were two &lt;tt&gt;type_transition&lt;/tt&gt; statements with the same source and target, but different target domains. The &lt;tt&gt;ext_gateway.conf&lt;/tt&gt; module had the following statements:<br /> &lt;pre&gt;<br /> # Allow the client/server to transition for the gateways:<br /> allow unconfined_t ext_gateway_t : process { transition };<br /> allow unconfined_t secure_services_exec_t : file { read execute getattr };<br /> allow ext_gateway_t secure_services_exec_t : file { entrypoint };<br /> type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;<br /> &lt;/pre&gt;<br /> And the int_gateway.conf module had the following statements:<br /> &lt;pre&gt;<br /> # Allow the client/server to transition for the gateways:<br /> allow unconfined_t int_gateway_t : process { transition };<br /> allow unconfined_t secure_services_exec_t : file { read execute getattr };<br /> allow int_gateway_t secure_services_exec_t : file { entrypoint };<br /> type_transition unconfined_t secure_services_exec_t : process int_gateway_t;<br /> &lt;/pre&gt;<br /> <br /> While the allow rules are valid to enable the transitions to proceed, the two &lt;tt&gt;type_transition&lt;/tt&gt; statements had different &quot;default&quot; types, that break the type enforcement rule.<br /> <br /> It was decided to resolve this by:<br /> <br /> # Keeping the &lt;tt&gt;type_transition&lt;/tt&gt; rule for the &quot;default&quot; type of &lt;tt&gt;ext_gateway_t&lt;/tt&gt; and allow the secure server process to be execed from &lt;tt&gt;unconfined_t&lt;tt&gt; as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/7-domain-transition.png Domain Transition] diagram, by simply running the command from the prompt as follows:<br /> &lt;pre&gt;<br /> # Run the external gateway &quot;secure server&quot; application on port 9999 and <br /> # let the policy transition the process to the ext_gateway_t domain:<br /> <br /> secure_server 99999<br /> &lt;/pre&gt;<br /> # Use the SELinux &lt;tt&gt;runcon(1)&lt;/tt&gt; command to ensure that the internal gateway runs in the correct domain by running runcon from the prompt as follows:<br /> &lt;pre&gt;<br /> # Run the internal gateway &quot;secure server&quot; application on port 1111 and <br /> # use runcon to transition the process to the int_gateway_t domain:<br /> <br /> runcon -t int_gateway_t -r message_filter_r secure_server 1111<br /> <br /> # Note - The role is required as a role transition is also defined in the<br /> # policy.<br /> &lt;/pre&gt;<br /> <br /> The &lt;tt&gt;runcon&lt;/tt&gt; command makes use of a number of [LibselinuxAPISummary | libselinux API] functions to check the current context and set up the new context (for example &lt;tt&gt;getfilecon&lt;/tt&gt; is used to check the executable files context and &lt;tt&gt;setexeccon&lt;/tt&gt; is used to ensure the &lt;tt&gt;setexec&lt;/tt&gt; permission is allowed). If the all contexts are correct, then the &lt;tt&gt;execvp(2)&lt;/tt&gt; system call is executed that exec's the &lt;tt&gt;secure_server&lt;/tt&gt; application with the argument of &quot;&lt;tt&gt;1111&lt;/tt&gt;&quot; in the &lt;tt&gt;int_gateway_t&lt;tt&gt; domain with the &lt;tt&gt;message_filter_r&lt;/tt&gt; role. The &lt;tt&gt;runcon&lt;/tt&gt; source can be found in the &lt;tt&gt;coreutils&lt;/tt&gt; package.<br /> <br /> Other ways to resolve this issue are:<br /> <br /> # Use the runcon command for both gateways to transition to their respective domains. The &lt;tt&gt;type_transition&lt;/tt&gt; statements are therefore not required.<br /> # Use different names for the secure server executable files and ensure they have a different type (i.e. instead of &lt;tt&gt;secure_service_exec_t&lt;/tt&gt; label the external gateway &lt;tt&gt;ext_gateway_exec_t&lt;/tt&gt; and the internal gateway &lt;tt&gt;int_gateway_exec_t&lt;/tt&gt;. This would involve making a copy of the application binary (which has already been done as part of the module testing (see volume 2) by calling the server “&lt;tt&gt;server&lt;/tt&gt;” and labeling it &lt;tt&gt;unconfined_t&lt;/tt&gt; and then making a copy called &lt;tt&gt;secure_server&lt;/tt&gt; and labeling it &lt;tt&gt;secure_services_exec_t&lt;/tt&gt;).<br /> # Implement the policy using the Reference Policy template interface.<br /> <br /> It was decided to use &lt;tt&gt;runcon&lt;/tt&gt; as it demonstrates the command usage better than reading the man page.<br /> <br /> == Object Transition ==<br /> An object transition is where an object needs to be relabeled, for example changing a files label from one type to another. There are two ways this can be achieved within policy:<br /> <br /> 1) Using a &lt;tt&gt;type_transition&lt;/tt&gt; Statement to perform an object transition (relabel) for programs that are not SELinux-aware. This is the most common method and would be in the form of the following statement: <br /> &lt;pre&gt;<br /> type_transition ext_gateway_t in_queue_t:file in_file_t;<br /> &lt;/pre&gt;<br /> <br /> 2) Using a &lt;tt&gt;type_change&lt;/tt&gt; Statement to perform an object transition for programs that are SELinux-aware. <br /> &lt;pre&gt;<br /> type_change sysadm_t server_ptynode : chr_file sysadm_devpts_t;<br /> &lt;/pre&gt;<br /> <br /> The [[LibselinuxAPISummary | libselinux API]] call &lt;tt&gt;security_compute_relabel&lt;/tt&gt; would be used to compute the new context.<br /> <br /> The following details an object transition used in the &lt;tt&gt;ext_gateway.conf&lt;/tt&gt; loadable module (shown in volume 2) where by default, files would be labeled &lt;tt&gt;in_queue_t&lt;/tt&gt; when created by the gateway application as this is the label attached to the parent directory as shown:<br /> &lt;pre&gt;<br /> ls -Za /usr/message_queue/in_queue<br /> drwxr-xr-x root root user_u:object_r:in_queue_t .<br /> drwxr-xr-x root root system_u:object_r:unconfined_t ..<br /> &lt;/pre&gt;<br /> <br /> However the requirement is that files in the &lt;tt&gt;in_queue&lt;/tt&gt; directory must be labeled &lt;tt&gt;in_file_t&lt;/tt&gt;. To achieve this the files created must be relabeled to &lt;tt&gt;in_file_t&lt;/tt&gt; by using a &lt;tt&gt;type_transition&lt;/tt&gt; rule as follows:<br /> &lt;pre&gt;<br /> # type_transition | source_domain | target_type : object | default_type;<br /> ------------------x---------------x----------------------x---------------<br /> type_transition ext_gateway_t in_queue_t : file in_file_t;<br /> &lt;/pre&gt;<br /> <br /> This &lt;tt&gt;type_transition&lt;/tt&gt; statement states that when a ''process'' running in the ''&lt;tt&gt;ext_gateway_t&lt;/tt&gt;'' domain (the source domain) wants to create a ''&lt;tt&gt;file&lt;/tt&gt;'' object in the directory that is labeled ''&lt;tt&gt;in_queue_t&lt;/tt&gt;'', the file should be relabeled ''&lt;tt&gt;in_file_t&lt;/tt&gt;'' if allowed by the policy (i.e. label the file ''&lt;tt&gt;in_file_t&lt;/tt&gt;'').<br /> <br /> However, as stated above to be able to relabel the file, the following minimum permissions need to be granted in the policy using &lt;tt&gt;allow&lt;/tt&gt; rules, where:<br /> <br /> * The source domain needs permission to ''add file entries into the directory'':<br /> &lt;pre&gt;<br /> allow ext_gateway_t in_queue_t : dir { write search add_name };<br /> &lt;/pre&gt;<br /> * The source domain needs permission to ''create file entries'':<br /> &lt;pre&gt;<br /> allow ext_gateway_t in_file_t : file { write create getattr };<br /> &lt;/pre&gt;<br /> * The policy can then ensure (via the SELinux kernel services) that files created in the &lt;tt&gt;in_queue&lt;/tt&gt; are relabeled:<br /> &lt;pre&gt;<br /> type_transition ext_gateway_t in_queue_t:file in_file_t;<br /> &lt;/pre&gt;<br /> <br /> An example output from a directory listing shows the resulting file labels:<br /> &lt;pre&gt;<br /> ls -Za /usr/message_queue/in_queue<br /> drwxr-xr-x root root user_u:object_r:in_queue_t .<br /> drwxr-xr-x root root system_u:object_r:unconfined_t ..<br /> -rw-r--r-- root root user_u:object_r:in_file_t Message-1<br /> -rw-r--r-- root root user_u:object_r:in_file_t Message-2<br /> &lt;/pre&gt;<br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_Networking NB Networking 2010-09-13T20:47:25Z <p>Jaxelson: </p> <hr /> <div>= SELinux Networking Support =<br /> SELinux supports the following types of network labeling:<br /> <br /> '''Internal labeling''' - This is where network objects are labeled and managed internally within a single machine (i.e. their labels are not transmitted as part of the session with remote systems). There are three types supported: those known as &quot;compat_net&quot; controls that label nodes, interfaces and ports; SECMARK that labels packets; and fallback peer labeling.<br /> <br /> '''Labeled Networking''' - This is where labels are passed to/from remote systems where they can be interpreted and a MAC policy enforced on each system. This is also known as &quot;peer labeling&quot;. There are two types supported: Labeled IPSec and CIPSO (commercial IP security option).<br /> <br /> Note that F-12 does not have NetLabel or IPSec tools installed as standard, therefore yum can be used to install them as shown below:<br /> &lt;pre&gt;<br /> yum install netlabel_tools<br /> <br /> yum install ipsec-tools<br /> &lt;/pre&gt;<br /> <br /> == compat_net Controls ==<br /> These labeling services make use of the [[NetworkStatements | Network Labeling Statements]] to label network object nodes, interfaces and ports with a security context that are then used to enforce controls. The [[NetworkStatements | Network Labeling Statements]] section defines each of the statements with examples of their usage.<br /> <br /> The [http://taiga.selinuxproject.org/~rhaines/diagrams/14-compat_net.png compat_net Controls] diagram shows how these network statements are used and the type of allow rules that would be required.<br /> <br /> In a future release of the Linux kernel these controls will be removed and replaced by the SECMARK services with the Reference Policy also being updated.<br /> <br /> == SECMARK ==<br /> SECMARK makes use of standard the kernel NetFilter framework that underpins the GNU / Linux IP networking sub-system. NetFilter automatically inspects all incoming and outgoing packets and can place controls on interfaces, IP addresses (nodes) and ports with the added advantage of connection tracking. The SECMARK and CONNSECMARK are security extensions to the Netfilter iptables that allow security contexts to be added to packets (SECMARK) or sessions (CONNSECMARK) such as those used by ftp (as some applications within a single session can use a number of different ports, some fixed and others dynamically allocated).<br /> <br /> The NetFilter framework is used to inspect and tag packets with labels as defined within the iptables and then use the security framework (e.g. SELinux) to enforce the policy rules. Therefore SECMARK services are not SELinux specific as other security modules that use the LSM infrastructure could also implement the same services (e.g. SMACK).<br /> <br /> While the implementation of iptables / NetFilter is beyond the scope of this Notebook, there are tutorials available&lt;ref name=&quot;ftn19&quot;&gt;There is a very good tutorial at [http://iptables-tutorial.frozentux.net/iptables-tutorial.html http://iptables-tutorial.frozentux.net/iptables-tutorial.html].&lt;/ref&gt;. The [http://taiga.selinuxproject.org/~rhaines/diagrams/15-secmark.png SECMARK Processing] diagram shows the basic structure and the process works as follows:<br /> <br /> * A table called the &quot;mangle table&quot; is used to define the parameters that identify and &quot;mark&quot; packets that can then tracked as the packet travels through the networking sub-system. These &quot;marks&quot; are called SECMARK and CONNSECMARK.<br /> * A SECMARK is placed against a packet if it matches an entry in the mangle table. This marker is used to apply a security context (a label) that can then enforce policy on the packet.<br /> * The CONNSECMARK &quot;marks&quot; all packets within a session&lt;ref name=&quot;ftn20&quot;&gt;For example, an ftp session where the server is listening on a specific port (the destination port) but the client will be assigned a random source port. The CONNSECMARK will ensure that all packets for the ftp session are marked with the same label.&lt;/ref&gt; with the appropriate label that can then be used to enforce policy.<br /> <br /> An example iptables&lt;ref name=&quot;ftn21&quot;&gt;Note that the iptables will not load correctly if the policy does not allow the iptables domain to relabel the SECMARK labels (unless permissive mode is enabled).&lt;/ref&gt; entry is as follows:<br /> &lt;pre&gt;<br /> # Flush the mangle table first:<br /> iptables -t mangle -F<br /> <br /> #----------------------------------- INPUT IP Stream ---------------------------------------------#<br /> # This INPUT rule sets all packets to default_secmark_packet_t<br /> iptables -t mangle -A INPUT -i lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system_u:object_r:default_secmark_packet_t<br /> <br /> #------------------------------------ OUTPUT IP Stream -------------------------------------------#<br /> # This OUTPUT rule sets all packets to default_secmark_packet_t<br /> iptables -t mangle -A OUTPUT -o lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system_u:object_r:default_secmark_packet_t<br /> &lt;/pre&gt;<br /> <br /> An example loadable module that makes use of SECMARK services is described in the Building the SECMARK Test Loadable Module section of volume 2, there is also an article &quot;[http://james-morris.livejournal.com/11010.html New secmark-based network controls for SELinux]&quot; that explains the services.<br /> <br /> As stated in the compat_net Controls section above, SECMARK will be replacing these and there is an article &quot;[http://paulmoore.livejournal.com/4281.html Transitioning to Secmark]&quot; that explains the transition.<br /> <br /> == NetLabel - Fallback Peer Labeling ==<br /> Fallback labeling can optionally be implemented on a system if the Labeled IPSec or CIPSO is not being used (hence &quot;fallback labeling&quot;). If either Labeled IPSec or CIPSO are being used, then these take priority. There is an article &quot;[http://paulmoore.livejournal.com/1758.html Fallback Label Configuration Example]&quot; that explains the usage.<br /> <br /> The example message filter has an optional module that makes use of fallback labels as explained in the Overview of modules section of volume 2. <br /> <br /> The network peer controls has been extended to support an additional object class of &quot;peer&quot;, although by default this is not enabled in F-12. To enabled this functionality the policy capability needs to be set as explained in the NetLabel Module Support for network_peer_controls section of the Sample Policy Source volume 2 where an example loadable module is given. The [http://taiga.selinuxproject.org/~rhaines/diagrams/16-fallback.png Fallback Labeling] diagram shows the differences between the policy capability &lt;tt&gt;network_peer_controls&lt;/tt&gt; set to 0 and 1.<br /> <br /> <br /> == Labeled IPSec ==<br /> Labeled IPSec has been built into the standard GNU / Linux IPSec services as described in the &quot;[http://nsrc.cse.psu.edu/tech_report/NAS-TR-0037-2006.pdf Leveraging IPSec for Distributed Authorization]&quot; document. The [http://taiga.selinuxproject.org/~rhaines/diagrams/17-ipsec.png IPSec communications] diagram shows the basic components that form the IPSec service where it is generally used to set up either an encrypted tunnel between two machines&lt;ref name=&quot;ftn22&quot;&gt;Also known as a virtual private network (VPN).&lt;/ref&gt; or an encrypted transport session. The extensions defined in the &quot;[http://nsrc.cse.psu.edu/tech_report/NAS-TR-0037-2006.pdf Leveraging IPSec for Distributed Authorization]&quot; document describe how the security context is used and negotiated between the two systems (called security associations (SAs) in IPSec terminology).<br /> <br /> Basically what happens is as follows&lt;ref name=&quot;ftn23&quot;&gt;There is an &quot;IPSec HOWTO&quot; at [http://www.ipsec-howto.org/ http://www.ipsec-howto.org] that gives the gory details, however it does not cover Labeled IPSec.&lt;/ref&gt;:<br /> <br /> # The security policy database (SPD) defines the security communications characteristics to be used between the two systems. This is populated using the setkey(8) utility and an example is shown below.<br /> # The SAs have their configuration parameters such as protocols used for securing packets, encryption algorithms and how long the keys are valid held in the Security Association database (SAD). For Labeled IPSec the security context (or labels) is also defined within the SAD. SAs can be negotiated between the two systems using either racoon(8)&lt;ref name=&quot;ftn24&quot;&gt;This is the Internet Key Exchange (IKE) daemon that exchanges encryption keys securely and also supports Labeled IPSec parameter exchanges.&lt;/ref&gt; that will automatically populate the SAD or manually by the setkey utility (see the example below).<br /> # Once the SAs have been negotiated and agreed, the link should be active.<br /> <br /> A point to note is that SAs are one way only, therefore if two systems are communicating then (using the above example), one system will have an SA, SAout for processing outbound packets and another SA, SAin, for processing the inbound packets. The other system will also create two SAs for processing its packets. <br /> <br /> Each SA will share the same cryptographic parameters such as keys and protocol&lt;ref name=&quot;ftn25&quot;&gt;The GNU / Linux version supports a number of secure protocols, see the setkey man page for details.&lt;/ref&gt; such as AH (authentication header) and ESP (encapsulated security payload). <br /> <br /> The object class used for the association of an SA is association and the permissions available are as follows:<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;tt&gt;polmatch&lt;/tt&gt;<br /> | Match the SPD context (-ctx) entry to an SELinux domain (that is contained in the SAD -ctx entry)<br /> <br /> |-<br /> | &lt;tt&gt;recvfrom&lt;/tt&gt;<br /> | Receive from an IPSec association.<br /> <br /> |-<br /> | &lt;tt&gt;sendto&lt;/tt&gt;<br /> | Send to an IPSec association.<br /> <br /> |-<br /> | setcontext<br /> | Set the context of an IPSec association on creation (e.g. when running setkey the process will require this permission to set the context in the SAD and SPD, also racoon will need this permission to build the SAD).<br /> <br /> |}<br /> <br /> <br /> A worked example of a Labeled IPSec session showing manual and racoon&lt;ref name=&quot;ftn26&quot;&gt;Unfortunately racoon core dumps using the example base module decribed in volume 2 but does work using the standard Red Hat targeted policy.&lt;/ref&gt; to configure the SAD is described in the Labeled IPSec Module Example section of the Sample Policy Source volume.<br /> <br /> There is a further example in the &quot;[http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/ Secure Networking with SELinux]&quot; article.<br /> &lt;pre&gt;<br /> # setkey -f configuration file entries<br /> #<br /> # Flush the SAD and SPD<br /> flush;<br /> spdflush;<br /> <br /> # Security Association Database entries. <br /> # 1) There would be another SAD entry on the other system (the client), where the IP addresses would be reversed.<br /> # 2) The security context must be that of the running application.<br /> <br /> add 172.16.96.30 172.16.96.31 esp 0x201<br /> -ctx 1 1 &quot;user_u:message_filter_r:ext_gateway_t&quot; <br /> -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;<br /> <br /> # Security Policy Database entries. <br /> # 1) there would be another SPD entry on the other system (the client), where the IP addresses would be reversed.<br /> # 2) The security context must be valid (i.e. defined in the active policy as it will be used by the polmatch permission <br /> # process to find a matching domain. (note only the &quot;type&quot; field is used unlike the SAD, where the context is the active process).<br /> <br /> # SAin<br /> spdadd 172.16.96.30 172.16.96.31 any<br /> -ctx 1 1 &quot;system_u:object_r:ext_gateway_t&quot;<br /> -P in ipsec esp/transport//require;<br /> # SAout<br /> spdadd 172.16.96.31 172.16.96.30 any<br /> -ctx 1 1 &quot;system_u:object_r:ext_gateway_t&quot;<br /> -P out ipsec esp/transport//require;<br /> &lt;/pre&gt;<br /> <br /> To manually load the above configuration file to populate the SPD and SAD&lt;ref name=&quot;ftn27&quot;&gt;If using racoon, the SAs would be negotiated using information from the SPD on each machine, with the SAD then being populated by racoon calling the setkey services.&lt;/ref&gt; the following command would be used:<br /> &lt;pre&gt;<br /> setkey -f &lt;SPD_configuration_file&gt;<br /> &lt;/pre&gt;<br /> <br /> == NetLabel - CIPSO ==<br /> To allow security levels to be passed over a network between MLS systems&lt;ref name=&quot;ftn28&quot;&gt;Note only the security levels are passed over as the SELinux security context is not part of a standard MLS system (as SELinux supports two MAC services (Type Enforcement and MLS)).&lt;/ref&gt;, the CIPSO protocol is used that is defined in the [http://tools.ietf.org/html/draft-ietf-cipso-ipsecurity-01 CIPSO Internet Draft] document (this is an obsolete document, however the protocol is still in use). The protocol defines how security levels are encoded in the IP packet header.<br /> <br /> The protocol is implemented by the NetLabel service and can be used by other security modules that use the LSM infrastructure. The NetLabel implementation supports:<br /> <br /> # Tag Type 1 bit mapped format that allows a maximum of 256 sensitivity levels and 240 categories to be mapped.<br /> # A non-translation option where labels are passed to / from systems unchanged (for host to host communications as show in the [http://taiga.selinuxproject.org/~rhaines/diagrams/18-mls1.png MLS Systems on the same network] diagram).<br /> # A translation option where both the sensitivity and category components can be mapped for systems that have either different definitions for labels or information can be exchanged over different networks (for example using an SELinux enabled gateway as a guard as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/19-mls2.png MLS Systems on different networks communicating via a gateway] diagram).<br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_MLS NB MLS 2010-09-13T20:47:12Z <p>Jaxelson: </p> <hr /> <div>= Multi-Level Security and Multi-Category Security =<br /> As stated in the [[NB_MAC | Mandatory Access Control (MAC)]] section as well as supporting Type Enforcement (TE), SELinux also supports MLS and MCS by adding an optional &lt;tt&gt;level&lt;/tt&gt; or &lt;tt&gt;range&lt;/tt&gt; entry to the security context. This section gives a brief introduction to MLS and MCS.<br /> <br /> The [http://taiga.selinuxproject.org/~rhaines/diagrams/8-security-levels.png Security Levels and Data Flows] diagram shows a simple view where security levels represent the classification of files within a file server. The security levels are strictly hierarchical and conform to the [http://en.wikipedia.org/wiki/Bell-LaPadula_model Bell-La Padula model] (BLP) in that (in the case of SELinux) a process (running at the &quot;Confidential&quot; level) can read / write at their current level but only read down levels or write up levels (the assumption here is that the process is authorised).<br /> <br /> This ensures confidentiality as the process can copy a file up to the secret level, but can never re-read that content unless the process &quot;steps up to that level&quot;, also the process cannot write files to the lower levels as confidential information would then drift downwards.<br /> <br /> To achieve this level of control, the MLS extensions to SELinux make use of constraints similar to those described in the type enforcement [[NB_TE#Constraints | Constraints]] section, except that the statement is called [[MLSStatements | mlsconstrain]]. <br /> <br /> However, as always life is not so simple as:<br /> <br /> # Processes and objects can be given a range that represents the low and high security levels.<br /> # The security level can be more complex, in that it is a hierarchical sensitivity and zero or more non-hierarchical categories.<br /> # Allowing a process access to an object is managed by &quot;dominance&quot; rules applied to the security levels. <br /> # Trusted processes can be given privileges that will allow them to bypass the BLP rules and basically do anything (that the security policy allowed of course).<br /> # Some objects do not support separate read / write functions as they need to read / respond in cases such as networks.<br /> <br /> The sections that follow discuss the format of a security level and range, and how these are managed by the constraints mechanism within SELinux using the &quot;dominance&quot; rules.<br /> <br /> == Security Levels ==<br /> Table 1 shows the components that make up a security level and how two security levels form a range for the fourth and optional &lt;tt&gt;&lt;nowiki&gt;[:level]&lt;/nowiki&gt;&lt;/tt&gt; of the [[NB_SC | security context]] within an MLS / MCS environment.<br /> <br /> The table also adds terminology in general use as other terms can be used that have the same meanings. <br /> <br /> <br /> {|border=&quot;1&quot;<br /> |&lt;center&gt;'''Security Level (or Level)'''&lt;/center&gt;<br /> <br /> &lt;center&gt;Consisting of a sensitivity and zero or more category entries:&lt;/center&gt;<br /> <br /> !colspan=&quot;2&quot; rowspan=&quot;2&quot;| Note that SELinux uses level, sensitivity and category in the language statements, however when discussing these the following terms can also be used: labels, classifications, and compartments.<br /> <br /> |-<br /> | &lt;tt&gt;&lt;center&gt;sensitivity [: category, ... ]&lt;/center&gt;&lt;/tt&gt;<br /> <br /> |-<br /> !colspan=&quot;3&quot;|&lt;center&gt;Range&lt;/center&gt;<br /> <br /> |-<br /> |&lt;center&gt;Low&lt;/center&gt;<br /> | <br /> |&lt;center&gt;High&lt;/center&gt;<br /> <br /> |-<br /> | &lt;tt&gt;&lt;center&gt;sensitivity [: category, ... ]&lt;/center&gt;&lt;/tt&gt;<br /> | &lt;center&gt;-&lt;/center&gt;<br /> | &lt;tt&gt;&lt;center&gt;sensitivity [: category, ... ]&lt;/center&gt;&lt;/tt&gt;<br /> <br /> |-<br /> |&lt;center&gt;For a process or subject this is the current level or sensitivity&lt;/center&gt;<br /> | <br /> |&lt;center&gt;For a process or subject this is the Clearance&lt;/center&gt;<br /> <br /> |-<br /> |&lt;center&gt;For an object this is the current level or sensitivity&lt;/center&gt;<br /> | <br /> |&lt;center&gt;For an object this is the maximum range &lt;/center&gt;<br /> <br /> &lt;center&gt;(for SELinux polyinstantiated directories)&lt;/center&gt;<br /> <br /> |-<br /> |&lt;tt&gt;&lt;center&gt;SystemLow&lt;/center&gt;&lt;/tt&gt;<br /> | <br /> |&lt;tt&gt;&lt;center&gt;SystemHigh&lt;/center&gt;&lt;/tt&gt;<br /> <br /> |-<br /> |&lt;center&gt;This is the lowest level or classification for the system (for SELinux this is generally '&lt;tt&gt;s0&lt;/tt&gt;', note that there are no categories).&lt;/center&gt;<br /> | <br /> |&lt;center&gt;This is the highest level or classification for the system (for SELinux this is generally '&lt;tt&gt;s15:c0,c255&lt;/tt&gt;', although note that they will be the highest set by the policy).&lt;/center&gt;<br /> <br /> |}<br /> ''Table 1: Level, Label, Category or Compartment - this table shows the meanings depending on the context being discussed.''<br /> <br /> <br /> The format used in the policy language statements is fully described in the [[MLSStatements | MLS Statements]] section, however a brief overview follows.<br /> <br /> <br /> === MLS / MCS Range Format ===<br /> The following components are used to define the MLS / MCS security levels within the security context:<br /> &lt;pre&gt;<br /> user:role:type:sensitivity[:category,...] - sensitivity [:category,...]<br /> ---------------x------------------------x-----x-------------------------x<br /> | level | - | level |<br /> | |<br /> |range|<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> {| border=&quot;1&quot;<br /> | &lt;tt&gt;sensitivity&lt;/tt&gt;<br /> | Sensitivity levels are hierarchical with (traditionally) &lt;tt&gt;s0&lt;/tt&gt; being the lowest. These values are defined using the &lt;tt&gt;sensitivity&lt;/tt&gt; language statement. To define their hierarchy, the &lt;tt&gt;dominance&lt;/tt&gt; statement is used.<br /> <br /> For MLS systems the highest sensitivity is the last one defined in the dominance statement (low to high). Traditionally the maximum for MLS systems is &lt;tt&gt;s15&lt;/tt&gt; (although the maximum value for the Reference Policy is a compile time option). <br /> <br /> For MCS systems there is only one sensitivity defined, and that is &lt;tt&gt;s0&lt;/tt&gt;.<br /> <br /> |-<br /> | &lt;tt&gt;category&lt;/tt&gt;<br /> | Categories are optional (i.e. there can be zero or more categories) and they form unordered and unrelated lists of &quot;compartments&quot;. These values are defined using the &lt;tt&gt;category&lt;/tt&gt; statement, where for example &lt;tt&gt;c0.c3&lt;/tt&gt; represents a range (&lt;tt&gt;c0 c1 c3&lt;/tt&gt;) and &lt;tt&gt;c0, c3, c7&lt;/tt&gt; represent an unordered list. Traditionally the values are between &lt;tt&gt;c0&lt;/tt&gt; and &lt;tt&gt;c255&lt;/tt&gt; (although the maximum value for the Reference Policy is a compile time option).<br /> <br /> |-<br /> | &lt;tt&gt;level&lt;/tt&gt;<br /> | The level is a combination of the sensitivity and category values that form the actual security level. These values are defined using the &lt;tt&gt;level&lt;/tt&gt; statement.<br /> <br /> |}<br /> <br /> <br /> === Translating Levels ===<br /> When writing policy for MLS / MCS security level components it is usual to use an abbreviated form such as &lt;tt&gt;s0, s1&lt;/tt&gt; etc. to represent sensitivities and &lt;tt&gt;c0, c1&lt;/tt&gt; etc. to represent categories. This is done simply to conserve space as they are held on files as extended attributes and also in memory. So that these labels can be represented in human readable form a translation service is provided via the &lt;tt&gt;setrans.conf&lt;/tt&gt; configuration file that uses the &lt;tt&gt;mcstransd&lt;/tt&gt; daemon. For example &lt;tt&gt;s0 = Unclassified&lt;/tt&gt;, &lt;tt&gt;s15 = TopSecret&lt;/tt&gt; and &lt;tt&gt;c0 = Finance&lt;/tt&gt;, &lt;tt&gt;c100 = SpyStories&lt;/tt&gt; (unfortunately the translation does not support spaces in words). The &lt;tt&gt;semanage(8)&lt;/tt&gt; command can be used to set up this translation and is shown in the [[GlobalConfigurationFiles | Global Configuration Files]] section.<br /> <br /> == Managing Security Levels via Dominance Rules ==<br /> As stated earlier, allowing a process access to an object is managed by &quot;dominance&quot; rules applied to the security levels. These rules are as follows:<br /> <br /> : '''Security Level 1 dominates Security Level 2''' - If the sensitivity of Security Level 1 is equal to or higher than the sensitivity of Security Level 2 and the categories of Security Level 1 are the same or a superset of the categories of Security Level 2.<br /> <br /> : '''Security Level 1 is dominated by Security Level 2''' - If the sensitivity of Security Level 1 is equal to or lower than the sensitivity of Security Level 2 and the categories of Security Level 1 are a subset of the categories of Security Level 2.<br /> <br /> : '''Security Level 1 equals Security Level 2''' - If the sensitivity of Security Level 1 is equal to Security Level 2 and the categories of Security Level 1 and Security Level 2 are the same set (sometimes expressed as: both Security Levels dominate each other).<br /> <br /> : '''Security Level 1 is incomparable to Security Level 2''' - If the categories of Security Level 1 and Security Level 2 cannot be compared (i.e. neither Security Level dominates the other).<br /> <br /> To illustrate the usage of these rules, the [http://taiga.selinuxproject.org/~rhaines/diagrams/t2-MLS-Security-Levels.png MLS Security Levels example] table lists the security level attributes in a table to show example files (or documents) that have been allocated labels such as &lt;tt&gt;s3:c0&lt;/tt&gt;. The process that accesses these files (e.g. an editor) is running with a range of &lt;tt&gt;s0 - s3:c1.c5&lt;/tt&gt; and has access to the files highlighted within the grey box area.<br /> <br /> As the MLS &lt;tt&gt;dominance&lt;/tt&gt; Statement is used to enforce the sensitivity hierarchy, the security levels now follow that sequence (lowest = &lt;tt&gt;s0&lt;/tt&gt; to highest = &lt;tt&gt;s3&lt;/tt&gt;) with the categories being unordered lists of &quot;compartments&quot;. To allow the process access to files within its scope and within the dominance rules, the process will be constrained by using the &lt;tt&gt;mlsconstrain&lt;/tt&gt; statement as illustrated in the [http://taiga.selinuxproject.org/~rhaines/diagrams/9-mls-constrain.png MLS constrain] diagram. <br /> <br /> So using the [http://taiga.selinuxproject.org/~rhaines/diagrams/9-mls-constrain.png MLS constrain] diagram:<br /> <br /> # To allow write-up, the source level (&lt;tt&gt;l1&lt;/tt&gt;) must be '''dominated by''' the target level (&lt;tt&gt;l2&lt;/tt&gt;):<br /> : Source level = &lt;tt&gt;s0:c3&lt;/tt&gt; or &lt;tt&gt;s1:c1&lt;/tt&gt;<br /> : Target level = &lt;tt&gt;s2:c1.c4&lt;/tt&gt;<br /> <br /> As can be seen, either of the source levels are '''dominated by''' the target level.<br /> <br /> # To allow read-down, the source level (&lt;tt&gt;l1&lt;/tt&gt;) must '''dominate''' the target level (&lt;tt&gt;l2&lt;/tt&gt;):<br /> : Source level = &lt;tt&gt;s2:c1.c4&lt;/tt&gt;<br /> : Target level = &lt;tt&gt;s0:c3&lt;/tt&gt;<br /> <br /> As can be seen, the source level does '''dominate''' the target level.<br /> <br /> However in the real world the SELinux MLS Reference Policy does not allow the write-up unless the process has a special privilege (by having the domain type added to an attribute), although it does allow the read-down. The default is to use &lt;tt&gt;l1 eq l2&lt;/tt&gt; (i.e. the levels are equal). The reference policy MLS source file (policy/mls) shows these mlsconstrain statements.<br /> <br /> == MLS Labeled Network and Database Support ==<br /> Networking for MLS is supported via the NetLabel CIPSO (commercial IP security option) service as discussed in the [[NB_Networking | SELinux Networking Support]] section.<br /> <br /> PostgreSQL supports labeling for MLS database services as discussed in the &quot;[http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Security-Enhanced PostgreSQL Security Wiki]&quot;.<br /> <br /> == Common Criteria Certification ==<br /> While the [http://www.commoncriteriaportal.org/ Common Criteria] certification process is beyond the scope of this Notebook, it is worth highlighting that specific Red Hat GNU / Linux versions of software, running on specific hardware platforms with SELinux / MLS policy enabled, have passed the Common Criteria evaluation process. Note, for the evaluation (and deployment) the software and hardware are tied together, therefore whenever an update is carried out, an updated certificate should be obtained.<br /> <br /> The Red Hat evaluation process cover the:<br /> * Labeled Security Protection Profile ([http://www.commoncriteriaportal.org/files/ppfiles/lspp.pdf LSPP] ) - This describes how systems that implement security labels (i.e. MLS) should function.<br /> * Controlled Access Protection Profile ([http://www.commoncriteriaportal.org/files/ppfiles/capp.pdf CAPP]) - This describes how systems that implement DAC should function.<br /> <br /> An interesting point:<br /> * Both Red Hat Linux 5.1 and Microsoft Server 2003 (with XP) have both been certified to EAL4+ , however while the evaluation levels may be the same the Protection Profiles that they were evaluated under were: Microsoft CAPP only, Red Hat CAPP and LSPP. Therefore always look at the protection profiles as they define what was actually evaluated.<br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_MAC NB MAC 2010-09-13T20:46:54Z <p>Jaxelson: </p> <hr /> <div>= Mandatory Access Control (MAC) =<br /> Mandatory Access Control (MAC) is a type of access control in which the operating system is used to constrain a user or process (the subject) from accessing or performing an operation on an object (such as a file, disk, memory etc.). <br /> <br /> Each of the subjects and objects have a set of security attributes that can be interrogated by the operating system to check if the requested operation can be performed or not. For SELinux the:<br /> <br /> * [[NB_Subjects | Subjects]] are processes.<br /> * [[NB_Objects | Objects]] are system resources such as files, sockets, etc.<br /> * security attributes are the [[NB_SC | security context]].<br /> * Security Server within the Linux kernel authorizes access (or not) using the:<br /> * security policy (or policy) that describes rules that must be obeyed.<br /> <br /> Note that the subject (and therefore the user) cannot decide to bypass the policy rules being enforced by the MAC policy with SELinux enabled. Contrast this to standard Linux Discretionary Access Control (DAC), which also governs the ability of subjects to access objects, however it allows users to make policy decisions (see [http://taiga.selinuxproject.org/~rhaines/diagrams/3-processing-call.png Processing a System Call]).<br /> <br /> SELinux supports two forms of MAC:<br /> <br /> # '''Type Enforcement''' - Where processes run in domains and the actions on objects are controlled by the policy. This is the implementation used for general purpose MAC within SELinux. The [[NB_TE | Type Enforcement]] section covers this in more detail. <br /> # '''Multi-Level Security''' - This is an implementation based on the Bell-La Padula (BLP) model, and used by organizations where different levels of access are required so that (for example in some defence / Government systems) restricted information is separated from classified information (i.e. maintaining confidentiality). This allows enforcement rules such as &quot;no write down&quot; and &quot;no read up&quot; to be implemented in a policy by extending the security context to include security levels. The [[NB_MLS | Multilevel Security ]] section covers this in more detail along with a variant of MLS called Multi-Category Security (MCS). <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_LSM NB LSM 2010-09-13T20:46:41Z <p>Jaxelson: </p> <hr /> <div>= Linux Security Module and SELinux =<br /> This section gives a high level overview of the LSM and SELinux internal structure and workings. A more detailed view can be found in the &quot;[http://www.nsa.gov/selinux/papers/module/t1.html Implementing SELinux as a Linux Security Module]&quot; that was used extensively to develop this section (with the SELinux kernel source code). The major areas covered are:<br /> <br /> * How the LSM and SELinux modules work together.<br /> * The major SELinux internal services.<br /> * The fork system call and exec are followed through as an example to tie in with the transition process covered in the [[NB_Objects#Domain_Transition | Domain and Object Transitions]] section.<br /> * The SELinux filesystem &lt;tt&gt;/selinux&lt;/tt&gt;.<br /> * The boot sequences that are relevant to SELinux.<br /> <br /> == The LSM Module ==<br /> The LSM is the Linux security framework that allows 3&lt;sup&gt;rd&lt;/sup&gt; party access control mechanisms to be linked into the GNU / Linux kernel. Currently there are two 3&lt;sup&gt;rd&lt;/sup&gt; party services that utilise the LSM: SELinux and SMACK (Simplified Mandatory Access Control Kernel) that both provide mandatory access control services. Details regarding SMACK can be found at: [http://www.schaufler-ca.com/ http://www.schaufler-ca.com/].<br /> <br /> The basic idea behind the LSM is to:<br /> # Insert security function calls (or hooks) and security data structures in the various kernel services to allow access control to be applied over and above that already implemented via DAC. The type of service that have hooks inserted are shown in Table 1 with an example task and program execution shown in the Fork Walk-thorough and Process Transition Walk-thorough sections below.<br /> # Allow registration and initialisation services for the 3&lt;sup&gt;rd&lt;/sup&gt; party security modules.<br /> # Allow process security attributes to be available to userspace services by extending the &lt;tt&gt;/proc&lt;/tt&gt; filesystem with a security namespace.<br /> # Support filesystems that use extended attributes (SELinux uses &lt;tt&gt;security.selinux&lt;/tt&gt;.<br /> # Consolidate the Linux capabilities into an optional module.<br /> <br /> It should be noted that the LSM does not provide any security services itself, only the hooks and structures for supporting 3&lt;sup&gt;rd&lt;/sup&gt; party modules. If no 3&lt;sup&gt;rd&lt;/sup&gt; party module is loaded, the capabilities module becomes the default module thus allowing standard DAC access control.<br /> <br /> {| border=&quot;1&quot;<br /> | Program execution<br /> | Filesystem operations<br /> | Inode operations<br /> <br /> |-<br /> | File operations<br /> | Task operations<br /> | Netlink messaging<br /> <br /> |-<br /> | Unix domain networking<br /> | Socket operations<br /> | XFRM operations<br /> <br /> |-<br /> | Key Management operations<br /> | IPC operations<br /> | Memory Segments<br /> <br /> |-<br /> | Semaphores<br /> | Capability<br /> | Sysctl<br /> <br /> |-<br /> | Syslog<br /> | Audit<br /> | <br /> <br /> |}<br /> ''Table 1: LSM Hooks - These are the kernel services that LSM has inserted security hooks and structures to allow access control to be managed by 3&lt;sup&gt;rd&lt;/sup&gt; party modules (see &lt;tt&gt;./kernel-2.6.27/include/linux/security.h&lt;/tt&gt;).''<br /> <br /> The major kernel source files (relative to &lt;tt&gt;./kernel-2.6.27/security&lt;/tt&gt;) that form the LSM are shown in Table 2. However there is one major header file (&lt;tt&gt;include/linux/security.h&lt;/tt&gt;) that describes all the security hooks and structures defined by the LSM.<br /> <br /> {| border=&quot;1&quot;<br /> ! Name<br /> ! Function<br /> <br /> |-<br /> | capability.c<br /> | Some capability functions were in various kernel modules have been consolidated into these source files. These are now (from Kernel 2.6.27) always linked into the kernel. This means the dummy.c security module (mentioned in the &quot;[http://www.nsa.gov/selinux/papers/module/t1.html Implementing SELinux as a Linux Security Module]&quot; document) is no longer required.<br /> <br /> |-<br /> | commoncap.c<br /> <br /> |-<br /> | device_cgroup.c<br /> <br /> |-<br /> | inode.c<br /> | This allows the 3&lt;sup&gt;rd&lt;/sup&gt; party security module to initialise a security filesystem. In the case of SELinux this would be &lt;tt&gt;/selinux&lt;/tt&gt; that is defined in the &lt;tt&gt;selinux/selinuxfs.c&lt;/tt&gt; source file. <br /> <br /> |-<br /> | root_plug.c<br /> | This is a sample 3&lt;sup&gt;rd&lt;/sup&gt; party module and therefore not used.<br /> <br /> |-<br /> | security.c<br /> | Contains the LSM framework initialisation services that will set up the hooks described in &lt;tt&gt;security.h&lt;/tt&gt; and those in the capability source files. It also provides functions to initialise 3&lt;sup&gt;rd&lt;/sup&gt; party modules. <br /> <br /> |}<br /> ''Table 2: The core LSM source modules.''<br /> <br /> <br /> == The SELinux Module ==<br /> This section does not go into detail of all the SELinux module functionality as the &quot;[http://www.nsa.gov/selinux/papers/module/t1.html Implementing SELinux as a Linux Security Module]&quot; document does this, however it attempts to highlight the way some areas work by using the Fork and Domain Transition Walk-thorough and transition process examples and also by describing the SELinux Boot Process.<br /> <br /> The major kernel SELinux source files (relative to &lt;tt&gt;./kernel-2.6.27/security/selinux&lt;/tt&gt;) that form the SELinux security module are shown in Table 3. The diagrams [http://taiga.selinuxproject.org/~rhaines/diagrams/2-high-level-arch.png High Level SELinux Architecture] and [http://taiga.selinuxproject.org/~rhaines/diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] can be used to see how some of these kernel source modules fit together. <br /> <br /> {| border=&quot;1&quot;<br /> ! Name<br /> ! Function<br /> <br /> |-<br /> | avc.c<br /> | Access Vector Cache functions and structures. The function calls are for the kernel services, however they have been ported to form the &lt;tt&gt;libselinux&lt;/tt&gt; userspace library detailed in the [[LibselinuxAPISummary | API Summary for libselinux]] section.<br /> <br /> |-<br /> | exports.c<br /> | Exported SELinux services for SECMARK (as there is SELinux specific code in the netfilter source tree).<br /> <br /> |-<br /> | hooks.c<br /> | Contains all the SELinux functions that are called by the kernel resources via the &lt;tt&gt;security_ops&lt;/tt&gt; function table (they form the kernel resource object managers). There are also support functions for managing process exec's, managing SID allocation and removal, interfacing into the AVC and Security Server.<br /> <br /> |-<br /> | netif.c<br /> | These manage the mapping between labels and SIDs for the net* language statements when they are declared in the active policy.<br /> <br /> |-<br /> | netnode.c<br /> <br /> |-<br /> | netport.c<br /> <br /> |-<br /> | netlabel.c<br /> | The interface between NetLabel services and SELinux.<br /> <br /> |-<br /> | netlink.c<br /> | Manages the notification of policy updates to resources including userspace applications via &lt;tt&gt;libselinux&lt;/tt&gt;.<br /> <br /> |-<br /> | nlmsgtab.c<br /> <br /> |-<br /> | selinuxfs.c<br /> | The &lt;tt&gt;selinuxfs&lt;/tt&gt; pseudo filesystem (&lt;tt&gt;/selinux&lt;/tt&gt;) that exports the security policy to userspace services via &lt;tt&gt;libselinux&lt;/tt&gt;. The services exported are shown in the SELinux Filesystem section below.<br /> <br /> |-<br /> | xfrm.c<br /> | Contains the IPSec XFRM hooks for SELinux.<br /> <br /> |-<br /> | include/flask.h<br /> | This contains all the kernel security classes and initial SIDs. Note that the Reference Policy source (&lt;tt&gt;policy/flask&lt;/tt&gt; directory) contains a list of all the kernel and userspace security classes and permissions. <br /> <br /> |-<br /> | ss/avtab.c<br /> | AVC table functions for inserting / deleting entries.<br /> <br /> |-<br /> | ss/conditional.c<br /> | Support boolean statement functions and implements a conditional AV table to hold entries.<br /> <br /> |-<br /> | ss/avtab.c<br /> | AVC table functions for inserting / deleting entries.<br /> <br /> |-<br /> | ss/ebitmap.c<br /> | Bitmaps to represent sets of values, such as types, roles, categories, and classes.<br /> <br /> |-<br /> | ss/hashtab.c<br /> | Hash table.<br /> <br /> |-<br /> | ss/mls.c<br /> | Functions to support MLS.<br /> <br /> |-<br /> | ss/policydb.c<br /> | Defines the structure of the policy database. See the &quot;[http://securityblog.org/brindle/2006/07/05/selinux-policy-module-primer/ SELinux Policy Module Primer]&quot; article for details on the structure.<br /> <br /> |-<br /> | ss/services.c<br /> | This contains the supporting services for kernel hooks defined in hooks.c, the AVC and the Security Server. <br /> <br /> For example the &lt;tt&gt;security_transition_sid&lt;/tt&gt; that computes the SID for a new subject / object shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram.<br /> <br /> |-<br /> | ss/sidtab.c<br /> | The SID table contains the security context indexed by its SID value.<br /> <br /> |-<br /> | ss/symtab.c<br /> | Maintains associations between symbol strings and their values.<br /> <br /> |}<br /> '''Table 3: The core SELinux source modules - '''''The &lt;tt&gt;.h&lt;/tt&gt; files and those in the &lt;tt&gt;include&lt;/tt&gt; directory have a number of useful comments.''<br /> <br /> <br /> === Fork System Call Walk-thorough ===<br /> This section walks through the the &lt;tt&gt;fork&lt;/tt&gt; system call shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/7-domain-transition.png Domain Transition] diagram starting at the kernel hooks that link to the SELinux services. The way the SELinux hooks are initialised into the LSM &lt;tt&gt;security_ops&lt;/tt&gt; and &lt;tt&gt;secondary_ops&lt;/tt&gt; function tables are also described.<br /> <br /> Using the [http://taiga.selinuxproject.org/~rhaines/diagrams/10-Fork.png Hooks for the fork system call] diagram, the major steps to check whether the &lt;tt&gt;unconfined_t&lt;/tt&gt; process has permission to use the fork permission are:<br /> <br /> # The &lt;tt&gt;kernel/fork.c&lt;/tt&gt; has a hook that links it to the LSM function &lt;tt&gt;security_task_create()&lt;/tt&gt; that is called to check access permissions. <br /> # Because the SELinux module has been initialised as the security module, the &lt;tt&gt;security_ops&lt;/tt&gt; table has been set to point to the SELinux &lt;tt&gt;selinux_task_create()&lt;/tt&gt; function in &lt;tt&gt;hooks.c&lt;/tt&gt;.<br /> # The &lt;tt&gt;selinux_task_create()&lt;/tt&gt; function will first call the capabilities code in &lt;tt&gt;capability.c&lt;/tt&gt; via the &lt;tt&gt;secondary_ops&lt;/tt&gt; function table to check the DAC permission. <br /> # This is simply a &lt;tt&gt;return 0;&lt;/tt&gt;, therefore no error would be generated.<br /> # The &lt;tt&gt;selinux_task_create()&lt;/tt&gt; function will then check whether the task has permission via the &lt;tt&gt;task_has_perm(current_process, current_process, PROCESS__FORK)&lt;/tt&gt; function. <br /> # This will result in a call to the AVC via the &lt;tt&gt;avc_has_perm()&lt;/tt&gt; function in &lt;tt&gt;avc.c&lt;/tt&gt; that checks whether the permission has been granted or not. First (via &lt;tt&gt;avc_has_perm_noaudit()&lt;/tt&gt;) the cache is checked to for an entry. Assuming that there is no entry in the AVC, then the &lt;tt&gt;security_compute_av()&lt;/tt&gt; function in &lt;tt&gt;services.c&lt;/tt&gt; is called.<br /> # The &lt;tt&gt;security_compute_av()&lt;/tt&gt; function will search the SID table for source and target entries, and if found will then call the &lt;tt&gt;context_struct_compute_av()&lt;/tt&gt; function.<br /> : The &lt;tt&gt;context_struct_compute_av()&lt;/tt&gt; function carries out many check to validate whether access is allowed. The steps are (assuming the access is valid):<br /> :: a) Initialise the AV structure so that it is clear.<br /> :: b) Check the object class and permissions are correct. It also checks the status of the &lt;tt&gt;allow_unknown&lt;/tt&gt; flag (see the SELinux Filesystem section below, [[GlobalConfigurationFiles | /etc/selinux/semanage.conf file]] and [[NB_RefPolicy | Reference Policy Build Options - build.conf]] sections).<br /> :: c) Checks if there are any type enforcement rules (&lt;tt&gt;ALLOW&lt;/tt&gt;, &lt;tt&gt;AUDIT_ALLOW&lt;/tt&gt;, &lt;tt&gt;AUDIT_DENY&lt;/tt&gt;).<br /> :: d) Check whether any conditional statements are involved via the &lt;tt&gt;cond_compute_av()&lt;/tt&gt; function in &lt;tt&gt;conditional.c&lt;/tt&gt;.<br /> :: e) Remove permissions that are defined in any constraint via the &lt;tt&gt;constraint_expr_eval()&lt;/tt&gt; function call (in &lt;tt&gt;services.c&lt;/tt&gt;). This function will also check any MLS constraints.<br /> :: f) Finally &lt;tt&gt;context_struct_compute_av()&lt;/tt&gt; checks if a process transition is being requested (it is not). If it were, then the &lt;tt&gt;TRANSITION&lt;/tt&gt; and &lt;tt&gt;DYNTRANSITION&lt;/tt&gt; permissions are checked and whether the role is changing.<br /> : 8. Once the result has been computed it is returned to the &lt;tt&gt;kernel/fork.c&lt;/tt&gt; system call via the initial &lt;tt&gt;selinux_task_create()&lt;/tt&gt; function. In this case the fork call is allowed. <br /> : 9. The End.<br /> <br /> === Process Transition Walk-thorough ===<br /> This section walks through the &lt;tt&gt;execve()&lt;/tt&gt; and checking whether a process transition to the &lt;tt&gt;ext_gateway_t&lt;/tt&gt; domain is allowed, and if so obtain a new SID for the context (&lt;tt&gt;user_u:message_filter_r:ext_gateway_t&lt;/tt&gt;) as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/7-domain-transition.png Domain Transition] diagram.<br /> <br /> The process starts with the Linux operating system issuing a &lt;tt&gt;do_execve()&lt;/tt&gt;&lt;ref name=&quot;ftn16&quot;&gt;This function call will pass over the file name to be run and its environment + arguments. Note that for loading shared libraries the exec_mmap function is used.&lt;/ref&gt; call from the CPU specific architecture code to execute a new program (for example, from &lt;tt&gt;arch/ia64/kernel/process.c&lt;/tt&gt;). The &lt;tt&gt;do_execve()&lt;/tt&gt; function is located in the &lt;tt&gt;fs/exec.c&lt;/tt&gt; source code module and does the loading and final exec as described below.<br /> <br /> &lt;tt&gt;do_execve()&lt;/tt&gt; has a number of calls to &lt;tt&gt;security_bprm_*&lt;/tt&gt; functions that are a part of the LSM (see &lt;tt&gt;security.h&lt;/tt&gt;), and are hooked by SELinux during the initialisation process (in &lt;tt&gt;hooks.c&lt;/tt&gt;). Table 4 briefly describes these &lt;tt&gt;security_bprm&lt;/tt&gt; functions that are hooks for validating program loading and execution (although see &lt;tt&gt;security.h&lt;/tt&gt; for greater detail).<br /> <br /> {| border=&quot;1&quot;<br /> | '''LSM / SElinux Function Name'''<br /> | '''Description'''<br /> <br /> |-<br /> | &lt;nowiki&gt;security_bprm_alloc-&gt;<br /> <br /> selinux_bprm_alloc_security&lt;/nowiki&gt;<br /> | Allocates memory for the &lt;tt&gt;bprm&lt;/tt&gt; structure.<br /> <br /> |-<br /> | &lt;nowiki&gt;security_bprm_free-&gt;<br /> <br /> selinux_bprm_free_security&lt;/nowiki&gt;<br /> | Frees memory from the &lt;tt&gt;bprm&lt;/tt&gt; structure.<br /> <br /> |-<br /> | &lt;nowiki&gt;security_bprm_apply_creds-&gt;<br /> <br /> selinux_bprm_apply_creds&lt;/nowiki&gt;<br /> | Sets task lock and new security attributes for a transformed process on execve. Seems to be used for libraries, scripts etc. Called from various Linux OS areas via &lt;tt&gt;compute_creds()&lt;/tt&gt; located in &lt;tt&gt;fs/exec.c&lt;/tt&gt;.<br /> <br /> |-<br /> | &lt;nowiki&gt;security_bprm_post_apply_creds-&gt;<br /> <br /> selinux_bprm_post_apply_creds&lt;/nowiki&gt;<br /> | Supports the &lt;tt&gt;security_bprm_apply_creds&lt;/tt&gt; function for areas that must not be locked.<br /> <br /> |-<br /> | &lt;nowiki&gt;security_bprm_secureexec-&gt;<br /> <br /> selinux_bprm_secureexec&lt;/nowiki&gt;<br /> | Called after the &lt;tt&gt;selinux_bprm_post_apply_creds&lt;/tt&gt; function to check &lt;tt&gt;AT_SECURE&lt;/tt&gt; flag for glibc secure mode support.<br /> <br /> |-<br /> | &lt;nowiki&gt;security_bprm_set-&gt;<br /> <br /> selinux_bprm_set_security&lt;/nowiki&gt;<br /> | Carries out the major checks to validate whether the process can transition to the target context, and obtain a new SID if required.<br /> <br /> |-<br /> | &lt;nowiki&gt;security_bprm_check-&gt;<br /> <br /> selinux_bprm_check_security&lt;/nowiki&gt;<br /> | This hook is not used by SELinux.<br /> <br /> |}<br /> ''Table 4: The LSM / SELinux Program Loading Hooks''<br /> <br /> <br /> Therefore starting at the &lt;tt&gt;do_execve()&lt;/tt&gt; function and using the [http://taiga.selinuxproject.org/~rhaines/diagrams/11-Transition.png Process Transition] diagram, the following major steps will be carried out to check whether the &lt;tt&gt;unconfined_t&lt;/tt&gt; process has permission to transition the &lt;tt&gt;secure_server&lt;/tt&gt; executable to the &lt;tt&gt;ext_gateway_t&lt;/tt&gt; domain:<br /> <br /> : 1. The executable file is opened, a call issued to the &lt;tt&gt;sched_exec()&lt;/tt&gt; function and the &lt;tt&gt;bprm&lt;/tt&gt; structure is initialised with the file parameters (name, environment and arguments). <br /> : The &lt;tt&gt;security_bprm_alloc()-&gt;selinux_bprm_alloc_security()&lt;/tt&gt; function is then called (in &lt;tt&gt;hooks.c&lt;/tt&gt;) where SELinux will allocate memory for the &lt;tt&gt;bprm&lt;/tt&gt; security structure and set the &lt;tt&gt;bsec-&gt;set&lt;/tt&gt; flag to &lt;tt&gt;0&lt;/tt&gt; indicating this is the first time through this process for this exec request.<br /> : 2. Via the &lt;tt&gt;prepare_binprm()&lt;/tt&gt; function call the UID and GIDs are checked and a call issued to &lt;tt&gt;security_bprm_set()&lt;/tt&gt; that will carry out the following:<br /> :: a) The &lt;tt&gt;selinux_bprm_set_security()&lt;/tt&gt; function will call the &lt;tt&gt;secondary_ops-&gt;bprm_set_security&lt;/tt&gt; function in &lt;tt&gt;capability.c&lt;/tt&gt;, that is effectively a no-op.<br /> :: b) The &lt;tt&gt;bsec-&gt;set&lt;/tt&gt; flag will be checked and if &lt;tt&gt;1&lt;/tt&gt; will return as this function can be called multiple times during the exec process.<br /> :: c) The target SID is checked to see whether a transition is required (in this case it is), therefore a call will be made to the &lt;tt&gt;security_transition_sid()&lt;/tt&gt; function in &lt;tt&gt;services.c&lt;/tt&gt;. This function will compute the SID for a new subject or object (subject in this case) via the &lt;tt&gt;security_compute_sid()&lt;/tt&gt; function that will (assuming there are no errors):<br /> ::: .i. Search the SID table for the source and target SIDs.<br /> ::: .ii. Sets the SELinux user identity.<br /> ::: .iii. Set the source role and type.<br /> ::: .iv. Checks that a &lt;tt&gt;type_transition&lt;/tt&gt; rule exists in the AV table and / or the conditional AV table (see the [http://taiga.selinuxproject.org/~rhaines/diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram).<br /> ::: .v. If a &lt;tt&gt;type_transition&lt;/tt&gt;, then also check for a &lt;tt&gt;role_transition&lt;/tt&gt; (there is a role change in the &lt;tt&gt;ext_gateway.conf&lt;/tt&gt; policy module), set the role.<br /> ::: .vi. Check if any MLS attributes by calling &lt;tt&gt;mls_compute_sid()&lt;/tt&gt; in &lt;tt&gt;mls.c&lt;/tt&gt;. It also checks whether MLS is enabled or not, if so sets up MLS contexts.<br /> ::: .vii. Check whether the contexts are valid by calling &lt;tt&gt;compute_sid_handle_invalid_context()&lt;/tt&gt; that will also log an audit message if the context is invalid.<br /> ::: .viii. Finally obtains a SID for the new context by calling &lt;tt&gt;sidtab_context_to_sid()&lt;/tt&gt; in &lt;tt&gt;sidtab.c&lt;/tt&gt; that will search the SID table (see the [http://taiga.selinuxproject.org/~rhaines/diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram) and insert a new entry if okay or log a kernel event if invalid.<br /> :: d) The &lt;tt&gt;selinux_bprm_set_security()&lt;/tt&gt; function will then continue by checking via the &lt;tt&gt;avc_has_perm()&lt;/tt&gt; function (in &lt;tt&gt;avc.c&lt;/tt&gt;) whether the &lt;tt&gt;file_execute_no_trans&lt;/tt&gt; is set (in this case it is not), therefore the &lt;tt&gt;process_transition&lt;/tt&gt; and &lt;tt&gt;file_entrypoint&lt;/tt&gt; permissions are checked (in this case they are), therefore the new SID is set, the &lt;tt&gt;bsec-&gt;set&lt;/tt&gt; flag is set to &lt;tt&gt;1&lt;/tt&gt; so that this part of the function is not executed again for this &lt;tt&gt;exec&lt;/tt&gt;, finally control is passed back to the &lt;tt&gt;do_execve&lt;/tt&gt; function:<br /> : 3. Various strings are copied (args etc.) and a check is made to see if the exec succeeded or not (in this case it did), therefore the &lt;tt&gt;security_bprm_free()&lt;/tt&gt; function is called to free the &lt;tt&gt;bprm&lt;/tt&gt; security structure. <br /> : 4. The End.<br /> <br /> === SELinux Filesystem ===<br /> Table 5 shows the information contained in the pseudo file system /selinux where the SELinux kernel exports relevant information regarding its configuration and active policy for use by the [[LibselinuxAPISummary | libselinux API]] library (that is used by user-space object managers and SELinux-aware applications).<br /> <br /> {| border=&quot;1&quot;<br /> ! &lt;center&gt;Directory / File Name&lt;/center&gt;<br /> ! &lt;center&gt;Permissions&lt;/center&gt;<br /> ! &lt;center&gt;Comments&lt;/center&gt;<br /> <br /> |-<br /> | '''/selinux'''<br /> | &lt;center&gt;'''Directory'''&lt;/center&gt;<br /> | This is the root directory where the SELinux kernel exports relevant information regarding its configuration and active policy for use by the libselinux library (that is used by user space object managers and SELinux-aware applications).<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;access&lt;/div&gt;<br /> | &lt;center&gt;-rw-rw-rw-&lt;/center&gt;<br /> | Compute access decision interface.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;checkreqprot&lt;/div&gt;<br /> | &lt;center&gt;-rw-r--r--&lt;/center&gt;<br /> | Check requested protection, not kernel-applied one.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;commit_pending_bools&lt;/div&gt;<br /> | &lt;center&gt;--w-------&lt;/center&gt;<br /> | Commit new boolean values to the kernel policy.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;compat_net&lt;/div&gt;<br /> | &lt;center&gt;-rw-r--r--&lt;/center&gt;<br /> | Whether SECMARK is enabled or not:<br /> <br /> 0 = SECMARK enabled (F-12 default).<br /> <br /> 1 = SECMARK disabled<br /> <br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;context&lt;/div&gt;<br /> | &lt;center&gt;-rw-rw-rw-&lt;/center&gt;<br /> | Validate context interface.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;create&lt;/div&gt;<br /> | &lt;center&gt;-rw-rw-rw-&lt;/center&gt;<br /> | Compute create labeling decision interface.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;deny_unknown&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> | These two files export unknown deny and reject handling status to user space. This is taken from the &lt;tt&gt;handle-unknown&lt;/tt&gt; parameter set&lt;ref name=&quot;ftn17&quot;&gt;That is taken from the UNK_PERMS entry in the Reference Policy build.conf file.&lt;/ref&gt; in the /etc/selinux/semanage.conf file and are set as follows:<br /> <br /> 0:0 = allow, 1:0 = deny and 1:1 = reject.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;reject_unknown&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;disable&lt;/div&gt;<br /> | &lt;center&gt;--w-------&lt;/center&gt;<br /> | Disable SELinux until next reboot.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;enforce&lt;/div&gt;<br /> | &lt;center&gt;-rw-r--r--&lt;/center&gt;<br /> | Get or set enforcing status. Used by the setenforce(8) command.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;load&lt;/div&gt;<br /> | &lt;center&gt;-rw-------&lt;/center&gt;<br /> | Load policy interface.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;member&lt;/div&gt;<br /> | &lt;center&gt;-rw-rw-rw-&lt;/center&gt;<br /> | Compute polyinstantiation membership decision interface.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;mls&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> | Returns 1 if MLS policy is enabled or 0 if not.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;null&lt;/div&gt;<br /> | &lt;center&gt;crw-rw-rw-&lt;/center&gt;<br /> | <br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;policyvers&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> | Returns policy version for this kernel (F-12 = 24).<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;relabel&lt;/div&gt;<br /> | &lt;center&gt;-rw-rw-rw-&lt;/center&gt;<br /> | Compute relabeling decision interface.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;user&lt;/div&gt;<br /> | &lt;center&gt;-rw-rw-rw-&lt;/center&gt;<br /> | Compute reachable user contexts interface.<br /> <br /> |-<br /> | '''/selinux/avc'''<br /> | &lt;center&gt;'''Directory'''&lt;/center&gt;<br /> | This directory contains information regarding the kernel AVC that can be displayed by the avcstat command.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;cache_stats&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> | Shows the AVC lookups, hits, misses etc.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;cache_threshold&lt;/div&gt;<br /> | &lt;center&gt;-rw-r--r--&lt;/center&gt;<br /> | The default value is 512, however caching can be turned off (but performance suffers) by:<br /> <br /> echo 0 &gt; /selinux/avc/cache_threshold<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;hash_stats&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> | Shows the number of AVC entries, longest chain etc.<br /> <br /> |-<br /> | '''/selinux/booleans'''<br /> | &lt;center&gt;'''Directory'''&lt;/center&gt;<br /> | This directory contains one file for each boolean defined in the active policy.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;secmark_audit&lt;/div&gt;<br /> <br /> &lt;div align=&quot;right&quot;&gt;......&lt;/div&gt;<br /> <br /> &lt;div align=&quot;right&quot;&gt;......&lt;/div&gt;<br /> | &lt;center&gt;-rw-r--r--&lt;/center&gt;<br /> | Each file contains the current status of the boolean (0 = false or 1 = true). The getsebool(8), setsebool(8) and sestatus -b commands use this information.<br /> <br /> |-<br /> | '''/selinux/initial_contexts'''<br /> | &lt;center&gt;'''Directory'''&lt;/center&gt;<br /> | This directory contains one file for each initial SID defined in the active policy.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;any_socket&lt;/div&gt;<br /> <br /> &lt;div align=&quot;right&quot;&gt;devnull&lt;/div&gt;<br /> <br /> &lt;div align=&quot;right&quot;&gt;.....&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> | Each file contains the initial context of the initial SID as defined in the active policy (e.g. any_socket was assigned system_u:object_r:unconfined_t).<br /> <br /> |-<br /> | '''/selinux/policy_capabilities'''<br /> | &lt;center&gt;'''Directory'''&lt;/center&gt;<br /> | This directory contains the policy capabilities that have been configured by default in the kernel. They are generally new features that can be enabled for testing by using the policycap statement in a monolithic or base policy.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;network_peer_controls&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> | For the F-12 kernel, this file contains &quot;0&quot; (false) which means that the following network_peer_controls are not enabled by default:<br /> <br /> node: sendto recvfrom<br /> <br /> netif: ingress egress<br /> <br /> peer: recv<br /> <br /> <br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;open_perms&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> | For the F-12 kernel, this file contains &quot;0&quot; (false) which means that open permissions are not enabled by default on the following objects: dir, file, fifo_file, chr_file, blk_file.<br /> <br /> |-<br /> | '''/selinux/class'''<br /> | &lt;center&gt;'''Directory'''&lt;/center&gt;<br /> | This directory contains a list of classes and their permissions as defined within the policy.<br /> <br /> |-<br /> | '''/selinux/class/appletalk_socket'''<br /> | &lt;center&gt;'''Directory'''&lt;/center&gt;<br /> | Each class has its own directory that contains the following: <br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;index&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> | This file contains the allocated class number (e.g. appletalk_socket is &quot;56&quot; in flask.h (linux-2.6.27/security/selinux/include/flask.h)).<br /> <br /> |-<br /> | '''/selinux/class/appletalk_socket/'''<br /> <br /> '''perms'''<br /> | &lt;center&gt;'''Directory'''&lt;/center&gt;<br /> | This directory contains one file for each permission defined in the policy.<br /> <br /> |-<br /> | &lt;div align=&quot;right&quot;&gt;accept&lt;/div&gt;<br /> <br /> &lt;div align=&quot;right&quot;&gt;append&lt;/div&gt;<br /> <br /> &lt;div align=&quot;right&quot;&gt;bind&lt;/div&gt;<br /> <br /> &lt;div align=&quot;right&quot;&gt;....&lt;/div&gt;<br /> | &lt;center&gt;-r--r--r--&lt;/center&gt;<br /> | Each file contains a number but not sure what it represents.<br /> <br /> |}<br /> ''Table 5: /selinux File and Directory Information''<br /> <br /> Notes:<br /> <br /> # SIDs are not passed to userspace, only the security context string. The context can be read via the [[LibselinuxAPISummary | libselinux API]] where a userspace object manager normally manages the relationship (see &quot;SELinux Support for Userspace Object Managers&quot; [Ref. 17]).<br /> # The &lt;tt&gt;/proc&lt;/tt&gt; filesystem exports the process security context string to userspace via &lt;tt&gt;/proc/&lt;pid&gt;/attr&lt;/tt&gt; interface (where &lt;tt&gt;&lt;pid&gt;&lt;/tt&gt; is the process ID). These can also be managed via the the [[LibselinuxAPISummary | libselinux API]].<br /> <br /> === SELinux Boot Process ===<br /> Figure 1 shows the boot process that has been limited to what is considered relevant for initialising SELinux&lt;ref name=&quot;ftn18&quot;&gt;There is a Linux overview at: [http://en.wikipedia.org/wiki/Linux_startup_process http://en.wikipedia.org/wiki/Linux_startup_process].&lt;/ref&gt;, loading the policy and checking whether re-labeling is required. The SELinux kernel initialisation areas are in red. The &lt;tt&gt;kernel&lt;/tt&gt;, &lt;tt&gt;mkinitrd&lt;/tt&gt; and &lt;tt&gt;upstart&lt;/tt&gt; source code rpms were used to find the sequence of events (all corrections welcome).<br /> <br /> <br /> &lt;center&gt;'''Start Kernel Boot Process'''&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;./init/main.c start_kernel()&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;Load the initial RAM Disk (this is a temporary root filesystem). The source &lt;/center&gt;<br /> <br /> &lt;center&gt;code for this and &lt;tt&gt;nash(8)&lt;/tt&gt; is in the &lt;tt&gt;mkinitrd&lt;/tt&gt; source code.&lt;/center&gt;<br /> <br /> &lt;center&gt;| &lt;/center&gt;<br /> <br /> &lt;center&gt;Kernel calls &lt;tt&gt;security_init()&lt;/tt&gt; to initialise the LSM security framework. &lt;/center&gt;<br /> <br /> &lt;center&gt;For SELinux this results in a call to &lt;tt&gt;selinux_init()&lt;/tt&gt; that is in &lt;tt&gt;hooks.c&lt;/tt&gt;&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;Set the kernel context to the initial SID value &quot;&lt;tt&gt;1&lt;/tt&gt;&quot; taken from&lt;/center&gt;<br /> <br /> &lt;center&gt;&lt;tt&gt;include/flask.h&lt;/tt&gt; (&lt;tt&gt;SECINITSID_KERNEL&lt;/tt&gt;) &lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;The AVC is initialised by a call to &lt;tt&gt;avc_init()&lt;/tt&gt;&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;Other areas of SELinux get initialised such as the &lt;/center&gt;<br /> <br /> &lt;center&gt;&lt;tt&gt;selinuxfs&lt;/tt&gt; (&lt;tt&gt;/selinux&lt;/tt&gt;) pseudo filesystem and netlink with their &lt;/center&gt;<br /> <br /> &lt;center&gt;objects set with the initial SIDs from &lt;tt&gt;flask.h&lt;/tt&gt;&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;&lt;tt&gt;'''/sbin/nash is run by the kernel&lt;/tt&gt;.'''&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;&lt;tt&gt;/sbin/nash&lt;/tt&gt; initialises services such as drivers, loads the root filesystem&lt;/center&gt;<br /> <br /> &lt;center&gt;read-only and loads the SELinux policy using the &lt;tt&gt;loadPolicyCommand&lt;/tt&gt;. &lt;/center&gt;<br /> <br /> &lt;center&gt;This function will check various directories, then call the SELinux API&lt;/center&gt;<br /> <br /> &lt;center&gt;the selinux_init_load_policy function to load the policy.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;Loading the policy will now complete the SELinux initialisation &lt;/center&gt;<br /> <br /> &lt;center&gt;with a call to &lt;tt&gt;selinux_complete_init()&lt;/tt&gt; in &lt;tt&gt;hooks.c&lt;/tt&gt;. &lt;/center&gt;<br /> <br /> &lt;center&gt;SELinux will now start enforcing policy or allow permissive access &lt;/center&gt;<br /> <br /> &lt;center&gt;depending on the value set in &lt;tt&gt;/etc/selinux/config SELINUX=&lt;/tt&gt;&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;The kernel is now loaded, the RAM disk removed, SELinux is &lt;/center&gt;<br /> <br /> &lt;center&gt;initialised, the policy loaded and &lt;tt&gt;/sbin/init&lt;/tt&gt; is running &lt;/center&gt;<br /> <br /> &lt;center&gt;with the root filesystem in read only mode.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;'''End Kernel Load and Initialisation'''&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;&lt;tt&gt;'''/etc/rc.d/sysinit&lt;/tt&gt; is run by &lt;tt&gt;init &lt;/tt&gt;that will:'''&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;mount &lt;tt&gt;/proc&lt;/tt&gt; and &lt;tt&gt;sysfs&lt;/tt&gt; filesystems&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;Check that the &lt;tt&gt;selinuxfs&lt;/tt&gt; (&lt;tt&gt;/selinux&lt;/tt&gt;) pseudo filesystem&lt;/center&gt;<br /> <br /> &lt;center&gt;is present and whether the current process is labeled &lt;tt&gt;kernel_t&lt;/tt&gt;&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;If the current SELinux state can be read (&lt;tt&gt;/selinux/enforce&lt;/tt&gt;), &lt;/center&gt;<br /> <br /> &lt;center&gt;then set to value. If cannot read, set to &quot;1&quot;.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;Run r&lt;tt&gt;estorecon -R&lt;/tt&gt; on /&lt;tt&gt;dev&lt;/tt&gt; if needed.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;Kill off &lt;tt&gt;/sbin/nash&lt;/tt&gt; if it is still running.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;Run &lt;tt&gt;restorecon&lt;/tt&gt; on &lt;tt&gt;/dev/pts&lt;/tt&gt; if needed.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;Set contexts on the files in &lt;tt&gt;/etc/rwtab&lt;/tt&gt; and /&lt;tt&gt;etc/statetab&lt;/tt&gt; &lt;/center&gt;<br /> <br /> &lt;center&gt;by running &lt;tt&gt;restorecon -R path&lt;/tt&gt;.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;Check if relabeling required:&lt;/center&gt;<br /> <br /> &lt;center&gt;if &lt;tt&gt;./autorelabel&lt;/tt&gt; file + &lt;tt&gt;AUTORELABEL=0&lt;/tt&gt; (in &lt;tt&gt;/etc/selinux/config&lt;/tt&gt;):&lt;/center&gt;<br /> <br /> &lt;center&gt;then drop to shell for manual relabel, or &lt;/center&gt;<br /> <br /> &lt;center&gt;if only &lt;tt&gt;./autorelabel&lt;/tt&gt; file, then run &lt;tt&gt;fixfiles -F restore&lt;/tt&gt;.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;remove &lt;tt&gt;./autorelabel&lt;/tt&gt; file.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;If &lt;tt&gt;/sbin/init&lt;/tt&gt; has changed context after the relabel, &lt;/center&gt;<br /> <br /> &lt;center&gt;then ensure a reboot. ELSE carry on.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;&lt;tt&gt;/etc/rc.d/sysinit&lt;/tt&gt; will do other initialisation tasks, then exit.&lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;'''Note:''' Some SELinux notes state that &lt;tt&gt;/sbin/init&lt;/tt&gt; is re-exec&quot;ed &lt;/center&gt;<br /> <br /> &lt;center&gt;to allow it to run in the correct context. Could not find where this&lt;/center&gt;<br /> <br /> &lt;center&gt;happened as policy seems to be active before &lt;tt&gt;init&lt;/tt&gt; daemon is run ?? &lt;/center&gt;<br /> <br /> &lt;center&gt;|&lt;/center&gt;<br /> <br /> &lt;center&gt;'''Initialisation Complete'''&lt;/center&gt;<br /> <br /> ''Figure 1: The Boot Sequence - This shows how SELinux is initialised and the policy loaded during the boot process.''<br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> <br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_Apache NB Apache 2010-09-13T20:46:25Z <p>Jaxelson: </p> <hr /> <div>= Apache SELinux Support =<br /> Apache web servers are generally managed under SELinux by using the Apache policy modules from the Reference Policy, however an SELinux-aware shared library is available that will allow finer grained access control as described in this section. The additional Apache module is called &lt;tt&gt;mod_selinux.so&lt;/tt&gt; and has a supporting policy module called &lt;tt&gt;mod_selinux.pp&lt;/tt&gt;.<br /> <br /> The &lt;tt&gt;mod_selinux.pp&lt;/tt&gt; policy module also makes use of the [[TypeRules#typebounds_Statement | typebounds statement]] that was introduced into version 24 of the policy (that requires a minimum kernel of 2.6.28). This was introduced to allow threads in a multi-threaded application (such as Apache) to be bound within a defined set of permissions (i.e. the child domain cannot have greater permissions than the parent domain).<br /> <br /> These components are known as 'Apache / SELinux Plus' and are described in the sections that follow, however a full description including configuration details is available from the following web site:<br /> : [http://code.google.com/p/sepgsql/wiki/Apache_SELinux-plus http://code.google.com/p/sepgsql/wiki/Apache_SELinux-plus]<br /> <br /> The objective of these Apache add-on services is to achieve a fully SELinux-aware web stack (although not there yet). For example currently the LAPP&lt;ref name=&quot;ftn35&quot;&gt;This is similar to the LAMP (Linux, Apache, MySQL, PHP/Perl/Python) stack, however MySQL is not SELinux-aware.&lt;/ref&gt; (Linux, Apache, PostgreSQL, PHP / Perl / Python) stack has the following support:<br /> <br /> {| border=&quot;1&quot;<br /> | &lt;center&gt;'''L'''&lt;/center&gt;<br /> | Linux has SELinux support.<br /> <br /> |-<br /> | &lt;center&gt;'''A'''&lt;/center&gt;<br /> | Apache has partial SELinux support using the 'Apache SELinux Plus' module.<br /> <br /> |-<br /> | &lt;center&gt;'''P'''&lt;/center&gt;<br /> | PostgreSQL has SELinux support using SE-PostgreSQL.<br /> <br /> |-<br /> | &lt;center&gt;'''P'''&lt;/center&gt;<br /> | PHP / Perl / Python is not currently SELinux-aware.<br /> <br /> |}<br /> <br /> <br /> The &quot;[http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf A secure web application platform powered by SELinux]&quot; document gives a good overview of the LAPP architecture.<br /> <br /> == mod_selinux Overview ==<br /> What the &lt;tt&gt;mod_selinux&lt;/tt&gt; module achieves is to allow a web application (or a 'request handler') to be launched by Apache with a security context based on policy rather than that of the web server process itself, for example:<br /> <br /> * A user sends an HTTP request to Apache that requires the services of a web application (Apache may or may not apply HTTP authentication).<br /> * Apache receives the request and launches the web application instance to perform the task:<br /> ** Without &lt;tt&gt;mod_selinux&lt;/tt&gt; enabled the web applications security context is identical to the Apache web server process, it is therefore not possible to restrict it privileges.<br /> ** With &lt;tt&gt;mod_selinux&lt;/tt&gt; enabled the web application is launched with the security context defined in the &lt;tt&gt;mod_selinux.conf&lt;/tt&gt; file (&lt;tt&gt;selinuxDomainVal &lt;security_context&gt;&lt;/tt&gt; entry). It is therefore possible to restrict its privileges as described in the Bounds Overview section below.<br /> <br /> * The web application exits, handing control back to the web server that replies with the HTTP response.<br /> <br /> === Bounds Overview ===<br /> Because multiple threads share the same memory segment, SELinux is unable to check the information flows between these different threads. This means that if a thread (the parent) should launch another thread (a child) with a different security context, SELinux cannot enforce the different permissions (this is why pre 2.6.28 kernels did not allow a different security context to be set on a thread).<br /> <br /> To resolve this issue the &lt;tt&gt;typebound&lt;/tt&gt; statement was introduced that stops a child thread (the 'bounded domain') having greater privileges than the parent thread (the 'bounding domain') i.e. the child thread must have equal or less permissions than the parent. <br /> <br /> For example the following &lt;tt&gt;typebounds&lt;/tt&gt; statement and &lt;tt&gt;allow&lt;/tt&gt; rules:<br /> &lt;pre&gt;<br /> # parent | child<br /> # domain | domain<br /> typebounds httpd_t httpd_child_t;<br /> <br /> allow httpd_t etc_t : file { getattr read };<br /> allow httpd_child_t etc_t : file { read write };<br /> &lt;/pre&gt;<br /> <br /> States that the parent domain (&lt;tt&gt;httpd_t&lt;/tt&gt;) has &lt;tt&gt;file:{getattr read}&lt;/tt&gt; permissions. However the child domain (&lt;tt&gt;httpd_child_t&lt;/tt&gt;) has been given &lt;tt&gt;file:{read write}&lt;/tt&gt;. This would not be allowed by the compiler because the parent does not have &lt;tt&gt;write&lt;/tt&gt; permission, thus ensuring the child domain will always have equal or less privileges than the parent.<br /> <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;<br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/NB_SC NB SC 2010-09-13T20:45:26Z <p>Jaxelson: added category</p> <hr /> <div>= Security Context =<br /> SELinux requires a security context to be associated with every process (or subject) and object that are used by the security server to decide whether access is allowed or not as defined by the policy.<br /> <br /> The security context is also known as a &quot;security label&quot; or just label that can cause confusion as there are many types of label depending on the context (another context!!).<br /> <br /> Within SELinux, a security context is represented as variable-length strings that define the SELinux user&lt;ref name=&quot;ftn7&quot;&gt;&lt;sup&gt;An SELinux user id is not the same as the GNU / Linux user id. The GNU / Linux user id is mapped to the SELinux user id by configuration files (via the &lt;tt&gt;semanage(8)&lt;/tt&gt; command).&lt;/sup&gt;&lt;/ref&gt;, their role, a type identifier and an optional MCS / MLS security level as follows:<br /> &lt;pre&gt;<br /> user:role:type[:level]<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> {| border=&quot;1&quot;<br /> | &lt;tt&gt;user&lt;/tt&gt;<br /> | The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.<br /> <br /> |-<br /> | &lt;tt&gt;role&lt;/tt&gt;<br /> | The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.<br /> <br /> |-<br /> | &lt;tt&gt;type&lt;/tt&gt;<br /> | When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access.<br /> <br /> When a type is associated with an object, it defines what access permissions the SELinux user has to that object.<br /> <br /> |-<br /> | &lt;tt&gt;level&lt;/tt&gt;<br /> | This field can also be know as a &lt;tt&gt;range&lt;/tt&gt; and is only present if the policy supports MCS or MLS. The entry can consist of:<br /> <br /> * A single security &lt;tt&gt;level&lt;/tt&gt; that contains a sensitivity level and zero or more categories (e.g. &lt;tt&gt;s0&lt;/tt&gt;, &lt;tt&gt;s1:c0&lt;/tt&gt;, &lt;tt&gt;s7:c10.c15&lt;/tt&gt;).<br /> * A &lt;tt&gt;range&lt;/tt&gt; that consists of two security levels (a low and high) separated by a hyphen (e.g. &lt;tt&gt;s0 - s15:c0.c1023&lt;/tt&gt;).<br /> <br /> These components are discussed in the [[NB_MLS#Security Levels | Security Levels]] section. <br /> <br /> |}<br /> <br /> <br /> However note that:<br /> # Access decisions regarding a subject make use of all the components of the [[NB_SC | security context]].<br /> # Access decisions regarding an object make use of all the components of the security context, however: <br /> :: a) the user is either set to a special user called &lt;tt&gt;system_u&lt;/tt&gt; or it is set to the SELinux user id of the creating process (as it serves no real purpose other than it can be used for audit purposes within logs). <br /> :: b) the role is not relevant to security decisions and is always set to a special SELinux internal role of &lt;tt&gt;object_r&lt;/tt&gt;.<br /> <br /> Therefore for an object, the type (and level for MLS) are the only relevant security fields that are used in access decisions. <br /> <br /> Examples of using &lt;tt&gt;system_u&lt;/tt&gt; and &lt;tt&gt;object_r&lt;/tt&gt; can be seen in the file system after relabeling and running the &lt;tt&gt;ls -Z&lt;/tt&gt; command on various directories.<br /> <br /> The examples below show security contexts for processes, directories and files (note that the policy did not support MCS or MLS, therefore no &lt;tt&gt;level&lt;/tt&gt; field):<br /> <br /> '''Example Process Security Context:'''<br /> &lt;pre&gt;<br /> # These are process security contexts taken from a ps -Z command <br /> # (edited for clarity) that show four processes:<br /> <br /> LABEL PID TTY CMD<br /> user_u:unconfined_r:unconfined_t 2539 pts/0 bash<br /> user_u:message_filter_r:ext_gateway_t 3134 pts/0 secure_server<br /> user_u:message_filter_r:int_gateway_t 3138 pts/0 secure_server<br /> user_u:unconfined_r:unconfined_t 3146 pts/0 ps<br /> <br /> # Note the bash and ps processes are running under the <br /> # unconfined_t domain, however the secure_server has two instances<br /> # running under two different domains (ext_gateway_t and <br /> # int_gateway_t). Also note that they are using the <br /> # message_filter_r role whereas bash and ps use unconfined_r.<br /> #<br /> # These results were obtained by running the system in permissive<br /> # mode (as in enforcing mode the gateway processes would not be shown).<br /> &lt;/pre&gt;<br /> <br /> '''Example Object Security Context:'''<br /> &lt;pre&gt;<br /> # These are the message queue directory object security contexts <br /> # taken from an ls -Zd command (edited for clarity):<br /> <br /> system_u:object_r:in_queue_t /user/message_queue/in_queue<br /> system_u:object_r:out_queue_t /user/message_queue/out_queue<br /> <br /> # Note that they are instantiated with system_u and object_r<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> # These are the message queue file object security contexts <br /> # taken from an ls -Z command (edited for clarity):<br /> <br /> /user/message_queue/in_queue:<br /> user_u:object_r:in_file_t Message-1<br /> user_u:object_r:in_file_t Message-2<br /> <br /> /user/message_queue/out_queue:<br /> user_u:object_r:out_file_t Message-10<br /> user_u:object_r:out_file_t Message-11<br /> <br /> # Note that they are instantiated with user_u as that was the <br /> # SELinux user id of the process that created the files (see the<br /> # process example above). The role remained as object_r.<br /> &lt;/pre&gt;<br /> <br /> ----<br /> &lt;references/&gt;<br /> [[Category:Notebook]]</div> Jaxelson https://selinuxproject.org/page/Security_context Security context 2010-09-13T20:43:12Z <p>Jaxelson: created redirect</p> <hr /> <div>#REDIRECT[[NB SC]]</div> Jaxelson https://selinuxproject.org/page/SIDStatements SIDStatements 2010-09-10T22:25:01Z <p>Jaxelson: /* Security ID (SID) Statement */ added a link for security context</p> <hr /> <div>= Security ID (SID) Statement =<br /> There are two SID statements, the first one declares the actual SID identifier and is defined at the start of a policy source file. The second statement is used to add an initial [[security context]] to the SID that is used when SELinux initialises or as a default if an object is not labeled correctly. The Building a Basic Policy section shows their usage.<br /> <br /> == sid Statement ==<br /> The sid statement declares the actual SID identifier and is defined at the start of a policy source file.<br /> <br /> '''The statement definition is:'''<br /> &lt;pre&gt;<br /> sid sid_id<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> {|border=&quot;1&quot;<br /> |sid<br /> |The sid keyword.<br /> <br /> |-<br /> |sid_id<br /> |The sid identifier. Note that there is no terminating '&lt;nowiki&gt;;&lt;/nowiki&gt;'.<br /> <br /> |}<br /> <br /> <br /> '''The statement is valid in:'''<br /> {|border=&quot;1&quot;<br /> |&lt;center&gt;'''Monolithic Policy'''&lt;/center&gt;<br /> |&lt;center&gt;'''Base Policy'''&lt;/center&gt;<br /> |&lt;center&gt;'''Module Policy'''&lt;/center&gt;<br /> <br /> |-<br /> |&lt;center&gt;Yes&lt;/center&gt;<br /> |&lt;center&gt;Yes&lt;/center&gt;<br /> |&lt;center&gt;No&lt;/center&gt;<br /> <br /> |-<br /> |&lt;center&gt;'''Conditional Policy (if) Statement'''&lt;/center&gt;<br /> |&lt;center&gt;'''optional Statement'''&lt;/center&gt;<br /> |&lt;center&gt;'''require Statement'''&lt;/center&gt;<br /> <br /> |-<br /> |&lt;center&gt;No&lt;/center&gt;<br /> |&lt;center&gt;No&lt;/center&gt;<br /> |&lt;center&gt;No&lt;/center&gt;<br /> <br /> |}<br /> <br /> <br /> '''Example:'''<br /> This example has been taken from the Reference Policy source ../policy/flask/initial_sids file.<br /> &lt;pre&gt;<br /> &lt;nowiki&gt;# This example was taken from the&lt;/nowiki&gt;<br /> &lt;nowiki&gt;# ./policy/flask/initial_sids file and &lt;/nowiki&gt;declares some <br /> &lt;nowiki&gt;# of the initial SIDs:&lt;/nowiki&gt;<br /> &lt;nowiki&gt;#&lt;/nowiki&gt;<br /> <br /> sid kernel<br /> sid security<br /> sid unlabeled<br /> sid fs<br /> &lt;/pre&gt;<br /> <br /> == sid context Statement ==<br /> The sid context statement is used to add an initial security context to the SID that is used when SELinux initialises, or as a default if an object is not labeled correctly.<br /> &lt;pre&gt;<br /> sid sid_id context<br /> &lt;/pre&gt;<br /> <br /> '''Where:'''<br /> {|border=&quot;1&quot;<br /> |sid<br /> |The sid keyword.<br /> <br /> |-<br /> |sid_id<br /> |The previously declared sid identifier. <br /> <br /> |-<br /> |context<br /> |The initial security context associated with the SID. Note that there is no terminating '&lt;nowiki&gt;;&lt;/nowiki&gt;'.<br /> <br /> |}<br /> <br /> <br /> '''The statements are valid in:'''<br /> {|border=&quot;1&quot;<br /> |&lt;center&gt;'''Monolithic Policy'''&lt;/center&gt;<br /> |&lt;center&gt;'''Base Policy'''&lt;/center&gt;<br /> |&lt;center&gt;'''Module Policy'''&lt;/center&gt;<br /> <br /> |-<br /> |&lt;center&gt;Yes&lt;/center&gt;<br /> |&lt;center&gt;Yes&lt;/center&gt;<br /> |&lt;center&gt;No&lt;/center&gt;<br /> <br /> |-<br /> |&lt;center&gt;'''Conditional Policy (if) Statement'''&lt;/center&gt;<br /> |&lt;center&gt;'''optional Statement'''&lt;/center&gt;<br /> |&lt;center&gt;'''require Statement'''&lt;/center&gt;<br /> <br /> |-<br /> |&lt;center&gt;No&lt;/center&gt;<br /> |&lt;center&gt;No&lt;/center&gt;<br /> |&lt;center&gt;No&lt;/center&gt;<br /> <br /> |}<br /> <br /> <br /> '''Examples:'''<br /> &lt;pre&gt;<br /> &lt;nowiki&gt;# These statements add an initial security context to an object &lt;/nowiki&gt;<br /> &lt;nowiki&gt;# that is used when SELinux initialises or as a default if a&lt;/nowiki&gt;<br /> &lt;nowiki&gt;# context is not available or labeled incorrectly. &lt;/nowiki&gt;<br /> &lt;nowiki&gt;#&lt;/nowiki&gt;<br /> &lt;nowiki&gt;# This one is from a targeted policy:&lt;/nowiki&gt;<br /> <br /> sid unlabeled system_u:object_r:unlabeled_t<br /> <br /> &lt;nowiki&gt;# This one is from an MLS policy. Note that the security level is&lt;/nowiki&gt;<br /> &lt;nowiki&gt;# set to SystemHigh as it may need to label any object in the&lt;/nowiki&gt;<br /> &lt;nowiki&gt;# system.&lt;/nowiki&gt;<br /> <br /> sid unlabeled system_u:object_r:unlabeled_t:s15:c0.c255 <br /> &lt;/pre&gt;</div> Jaxelson https://selinuxproject.org/page/Refpolicy Refpolicy 2010-09-10T22:11:31Z <p>Jaxelson: Redirecting to NB RefPolicy</p> <hr /> <div>#REDIRECT[[NB RefPolicy]]</div> Jaxelson https://selinuxproject.org/page/NB_TE NB TE 2010-08-31T20:25:53Z <p>Jaxelson: </p> <hr /> <div>''See Also: [[TypeEnforcement]]''<br /> = Type Enforcement (TE) =<br /> SELinux makes use of a specific style of type enforcement&lt;ref name=&quot;ftn5&quot;&gt;&lt;sup&gt;There are various &quot;type enforcement&quot; technologies. &lt;/sup&gt;&lt;/ref&gt; (TE) to enforce mandatory access control. For SELinux it means that all [[NB_Subjects | subjects]] and [[NB_Objects | objects]] have a type identifier associated to them that can then be used to enforce rules laid down in a policy. <br /> <br /> The SELinux type identifier is a simple variable-length string that is defined in the policy and then associated to a [[NB_SC | security context]]. It is also used in the majority of [[PolicyLanguage | SELinux language statements and rules]] used to build a policy that will, when loaded into the security server, enforce the policy.<br /> <br /> Because the type identifier (or just &quot;type&quot;) is associated to all subjects and objects, it can sometimes be difficult to distinguish what the type is actually associated with (it's not helped by the fact that by convention, type identifiers all end in &quot;&lt;tt&gt;_t&lt;/tt&gt;&quot;). In the end it comes down to understanding how they are allocated in the policy itself and how they are used by SELinux services. <br /> <br /> Basically if the type identifier is used to reference a subject it is referring to a GNU / Linux process or domain (i.e. domain type). If the type identifier is used to reference an object then it is specifying its object type (i.e. file type).<br /> <br /> While SELinux refers to a subject as being an active process that is associated to a domain type, the scope of an SELinux type enforcement domain can vary widely. For example in the simple policy built in the Building a Basic Policy section of volume 2, all the processes on the system run in the unconfined_t domain, therefore every process is &quot;of type &lt;tt&gt;unconfined_t&lt;/tt&gt;&quot; (that means it can do whatever it likes within the limits of the standard Linux DAC policy).<br /> <br /> It is only when additional policies are implemented in the simple policy (via loadable modules), that areas start to be confined, for example an external gateway is run in its own isolated domain (&lt;tt&gt;ext_gateway_t&lt;/tt&gt;) that cannot be &quot;interfered&quot; with by any of the &lt;tt&gt;unconfined_t&lt;/tt&gt; processes (except to run or transition the gateway process into its own domain). This scenario is similar to the &quot;targeted&quot; policy delivered as standard in Red Hat Fedora where the majority of user space processes run under the unconfined_t domain (although don't think they are equivalent as the policies supplied with the Reference Policy have areas isolated by various domains and has evolved over years of work).<br /> <br /> == Constraints ==<br /> Within a TE environment the way that subjects are allowed to access an object is via an &lt;tt&gt;allow&lt;/tt&gt; rule, for example:<br /> &lt;pre&gt;<br /> allow unconfined_t ext_gateway_t : process transition;<br /> &lt;/pre&gt;<br /> <br /> This is explained in more detail later, however it states that a process running in the &lt;tt&gt;unconfined_t&lt;/tt&gt; domain has permission to transition a process to the &lt;tt&gt;ext_gateway_t&lt;/tt&gt; domain. However it could be that the policy writer wants to constrain this further and state that this can only happen if the role of the source domain is the same as the role of the target domain. To achieve this a constraint can be imposed using a &lt;tt&gt;constrain&lt;/tt&gt; statement:<br /> &lt;pre&gt;<br /> constrain process transition ( r1 == r2 );<br /> &lt;/pre&gt;<br /> <br /> This states that a process transition can only occur if the source role is the same as the target role, therefore a constraint is a condition that must be satisfied in order for one or more permissions to be granted (i.e. a constraint imposes additional restrictions on TE rules). An example of this can be found in the [[ConstraintStatements | Constraint Statements]] section.<br /> <br /> There are a number of different constraint statements within the policy language to support areas such as MLS (see the [[ConstraintStatements | Constraint Statements]] and [[MLSStatements | MLS Statements]] sections). <br /> <br /> <br /> <br /> ----<br /> &lt;references/&gt;</div> Jaxelson https://selinuxproject.org/page/TypeEnforcement TypeEnforcement 2010-08-31T20:25:29Z <p>Jaxelson: </p> <hr /> <div>''See Also: [[NB TE|Type Enforcement (Notebook)]]''<br /> <br /> Type enforcement is the primary access control mechanism in SELinux. For an access to succeed, it must be allowed by type enforcement rules, at a minimum. The other mechanisms, such as roles, are used to constrain what access is allowed.<br /> <br /> Type enforcement is an access control system which makes decisions on if an access is allowed based on the type of the source of the access and type of the target of the access. They are also referred to as the subject and object. The subject is an active entity (a process) performing an access. An object, such as a file, directory, or another process, is an entity being accessed. For example, when vim opens a file to be edited, the subject is the vim process and the object is the file.<br /> <br /> As discussed in [[BasicConcepts]], a type is a security attribute. Types are an equivalence class, meaning all subjects and objects in the system which have the same security attributes should have the same type. For example, all shared libraries on the system have the same type, ''lib_t'', since they are all equivalent, in terms of security.<br /> <br /> The SELinux security policy contains the type enforcement rules which describe the accesses that are allowed. The SELinux policy is flexible, unlike other systems which have a fixed policy, such as a Bell-LaPadula/Mult-Level security systems. Many security goals can be encoded into the policy, such as integrity and separation. The current Reference Policy primarily protects the integrity of the system, but secondarily provides role separation. The complexity of SELinux policy is not inherent to SELinux or type enforcement, but rather due to Linux being a complex, general purpose operating system.</div> Jaxelson https://selinuxproject.org/page/Type_enforcement Type enforcement 2010-08-31T20:23:49Z <p>Jaxelson: created redirect</p> <hr /> <div>#REDIRECT[[NB TE]]</div> Jaxelson https://selinuxproject.org/page/COTS COTS 2010-08-31T20:22:59Z <p>Jaxelson: created page</p> <hr /> <div>COTS stands for Commercial off-the-shelf Software. Meaning software that your are able to acquire already made. This sometimes includes [[open source software]]. See [http://en.wikipedia.org/wiki/Commercial_off-the-shelf wikipedia] for more info.</div> Jaxelson