DOCSEARCHbyAlgolia
Submit Docs

SELinux Userspace

repository·master·Indexed 41 days ago

https://github.com/topjohnwu/selinux

Source code for utilities and system libraries used to configure and manage SELinux-based systems, providing the interface between the Linux Kernel's Mandatory Access Control (MAC) and system administrators. Includes documentation on Common Intermediate Language (CIL) for policy representation, build instructions for various Linux distributions, and API references for libselinux, such as avc_add_callback() and avc_cache_stats().

Tokens
85K
Snippets
300
Records
405
Agent score
100%

What's inside SELinux

  1. Overview of CIL (Common Intermediate Language)

    master

    CIL (Common Intermediate Language) is the intermediate language used by SELinux for policy representation. It provides a structured way to define security policies, including access vector rules, type transitions, and labeling. The documentation for CIL is organized into several functional areas:

    • Core Information: Declarations, definitions, namespaces, and expressions.
    • Access Control: Rules like allow, auditallow, dontaudit, and neverallow.
    • Policy Components: Definitions for class, permission, role, type, user, and sid.
    • Labeling: Statements for file (filecon), network (portcon, netifcon), and Multi-Level Security (sensitivity, category).
    • Control Flow: Conditional statements (boolean, tunable) and container statements (block, optional).
    • Specialized Labeling: Support for Xen, Infiniband, and MLS (Multi-Level Security).

  2. What is SELinux Common Intermediate Language (CIL)?

    master

    The SELinux Common Intermediate Language (CIL) is an intermediate language designed to sit between high-level policy languages (like the current module language) and the low-level kernel policy representation.

    It serves as a bridge that allows multiple high-level languages to interact by sharing common constructs (like interfaces) that are more feature-rich than the raw kernel policy. CIL provides a semantically rich representation that is suitable for policy analysis tools, ensuring that high-level information is preserved during the analysis process.

  3. Key features and goals of CIL

    master

    CIL enables several advanced SELinux policy capabilities that are difficult to achieve with current tools:

    • Policy Customization: Allows administrators to modify or remove access (e.g., removing unwanted access not controlled by a boolean) without modifying the original vendor-shipped policy files, enabling seamless future updates.
    • First-Class Interfaces: Elevates interfaces from pre-processor constructs to first-class language features. This allows compilers and analysis tools to understand them, removing the need to recompile all modules when an interface changes.
    • Rich Policy Relationships: Provides language features to create new types or modules based on existing ones (using templates, interfaces, and attributes) to allow for ad-hoc creation of policy modules.
    • Policy Management Support: Enables management tools like semanage to generate and consume CIL directly, rather than manipulating private data stores to modify binary policy formats.

  4. Explore CIL Access Vector Rules

    master

    Access Vector (AV) rules define what actions are permitted or denied between security contexts. Key rules include:

    • allow: Grants permission for an access vector.
    • auditallow: Grants permission and ensures the access is audited.
    • dontaudit: Allows access but prevents it from being logged in the audit trail.
    • neverallow: A constraint used to ensure certain access vectors are never granted.
    • allowx, auditallowx, dontauditx, neverallowx: Variants of the above rules (likely for extended or specific context types).

    Detailed syntax and usage for each rule can be found in the cil_access_vector_rules.md documentation.

  5. How CIL Declarations and Definitions work

    master

    CIL uses Declarations to create new objects and Definitions to build upon them.

    Declarations

    Declarations can be:

    1. Named: Creates a new identifier (e.g., (type process)).
    2. Explicit Anonymous: Currently restricted to IP addresses (e.g., (127.0.0.1)).
    3. Anonymous: References an object that has already been declared.

    Declaration Keywords: block, optional, common, class, classmap, classmapping, sid, user, role, roleattribute, type, classpermission, classpermissionset, typeattribute, typealias, tunable, sensitivity, sensitivityalias, category, categoryalias, categoryset, level, levelrange, context, ipaddr, macro, policycap.

    Definitions

    Definitions are statements that build on existing objects. Definitions can be repeated; duplicates are resolved to a single definition during compilation.

    Examples:

    • Adding a type to an attribute: (typeattributeset domain (process))
    • Adding an allow rule: (allow domain process (file (read write))))

  6. Explore CIL Labeling Statements

    master

    Labeling statements define how security contexts are applied to system objects:

    • File Labeling: filecon (file contexts), fsuse (filesystem use), and genfscon (generic filesystem contexts).
    • Network Labeling: ipaddr, netifcon (network interface), nodecon, and portcon (port contexts).
    • MLS Labeling: sensitivity, category, and level for Multi-Level Security.
    • Hardware/Virtualization: iomemcon, ioportcon, pcidevicecon (Xen), and ibpkeycon (Infiniband).

  7. Define common permissions with common and classcommon

    master

    To avoid duplicating permission lists across multiple classes, use the common and classcommon statements:

    1. common: Declares a common_id associated with a set of permissions.
    2. classcommon: Associates an existing class_id with a previously declared common_id.

    This allows a class to inherit a predefined set of permissions.

    (common file (ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton))

(classcommon dir file)

  8. Core design principles of CIL

    master

    CIL is designed with several key principles to ensure it remains a performant and reliable intermediate layer:

    • Intermediate Language Focus: Provides rich semantics for cross-language interaction but avoids features that can be handled by high-level languages to maintain simplicity.
    • Machine-First Syntax: Prioritizes clear, simple syntax (based on s-expressions) that is easy for compilers, analysis tools, and policy generation tools to parse and generate. Machine processing is prioritized over human readability.
    • Faithful Kernel Representation: Aims to fully and faithfully represent the kernel policy without obscuring or hiding the essence of kernel enforcement. It acts like "portable assembler" (C) rather than a pure functional language.
    • Source-Oriented: Operates in a source-oriented world; the only intended binary format is for communication with the kernel.
    • Declarative and Order-Independent: Maintains the existing SELinux paradigm of being declarative and order-independent, removing ordering constraints found in previous languages.
    • Elimination of Pre-processors: Designed to eliminate the need for M4 and other pre-processors by incorporating necessary logic directly into the language.
    • Single Compilation Unit: Processes the language as a single compilation unit rather than module-by-module to simplify processing and improve error reporting.

  9. Define type attributes with `typeattribute` and `typeattributeset`

    master

    Type attributes allow grouping types.

    • typeattribute: Declares a type attribute identifier.
    • typeattributeset: Associates one or more type, typealias, or typeattribute identifiers to a typeattribute identifier. You can use logical expressions like and, or, xor, not, and all to refine these associations.

    Example: Creating an attribute not_in_appdomain that includes all policy types except those in appdomain:

    (typeattribute not_in_appdomain)

(typeattributeset not_in_appdomain (not (appdomain)))

  10. Explore CIL Type and Role Statements

    master

    CIL uses specific statements to define the core entities of the SELinux security model:

    Type Statements

    Used to manage object types and their attributes:

    • type: Defines a new type.
    • typeattribute: Assigns attributes to a type.
    • typetransition: Defines how a type changes during an operation.
    • typepermissive: Sets a type to permissive mode.

    Role Statements

    Used to manage user roles and their capabilities:

    • role: Defines a new role.
    • roleattribute: Assigns attributes to a role.
    • roletransition: Defines how a role changes.
    • roleallow: Grants permissions to a role.

  11. Create a type alias with `typealias` and `typealiasactual`

    master

    To create a type alias, you must use two statements:

    1. typealias: Declares the alias identifier.
    2. typealiasactual: Associates the declared typealias identifier to a previously declared type identifier.

    Example of aliasing unconfined.process as unconfined_t:

    (typealias unconfined_t)
(typealiasactual unconfined_t unconfined.process)

(block unconfined
    (type process)
)

  12. Understand Access Vector (AV) Rules in CIL

    master

    Access Vector (AV) rules define the relationship between a source type, a target type, and specific class permissions or extended permissions.

    Rule Structure: (av_flavor source_id target_id|self|notself|other classpermission_id|permissionx_id)

    Key Components:

    • av_flavor: The type of rule (e.g., allow, deny, neverallow).
    • source_id: A previously defined type, typealias, or typeattribute.
    • target_id: A type, typealias, or typeattribute. Special keywords include:
      • self: The source and target are the same.
      • notself: The target is all types except those in the source.
      • other: A shorthand for pairing the source with all other types (excluding itself).
    • classpermission_id: Used for standard rules (allow, auditallow, dontaudit, neverallow). It can be a named/anonymous classpermissionset or a set of classmap/classmapping identifiers.
    • permissionx_id: Used for extended permission rules (allowx, auditallowx, dontauditx, neverallowx).