| 1 | |
| 2 |
|
| 3 | Integrity Policy Enforcement (IPE)
|
| 4 | ==================================
|
| 5 |
|
| 6 | .. NOTE::
|
| 7 |
|
| 8 | This is the documentation for admins, system builders, or individuals
|
| 9 | attempting to use IPE. If you're looking for more developer-focused
|
| 10 | documentation about IPE please see :doc:`the design docs </security/ipe>`.
|
| 11 |
|
| 12 | Overview
|
| 13 | --------
|
| 14 |
|
| 15 | Integrity Policy Enforcement (IPE) is a Linux Security Module that takes a
|
| 16 | complementary approach to access control. Unlike traditional access control
|
| 17 | mechanisms that rely on labels and paths for decision-making, IPE focuses
|
| 18 | on the immutable security properties inherent to system components. These
|
| 19 | properties are fundamental attributes or features of a system component
|
| 20 | that cannot be altered, ensuring a consistent and reliable basis for
|
| 21 | security decisions.
|
| 22 |
|
| 23 | To elaborate, in the context of IPE, system components primarily refer to
|
| 24 | files or the devices these files reside on. However, this is just a
|
| 25 | starting point. The concept of system components is flexible and can be
|
| 26 | extended to include new elements as the system evolves. The immutable
|
| 27 | properties include the origin of a file, which remains constant and
|
| 28 | unchangeable over time. For example, IPE policies can be crafted to trust
|
| 29 | files originating from the initramfs. Since initramfs is typically verified
|
| 30 | by the bootloader, its files are deemed trustworthy; "file is from
|
| 31 | initramfs" becomes an immutable property under IPE's consideration.
|
| 32 |
|
| 33 | The immutable property concept extends to the security features enabled on
|
| 34 | a file's origin, such as dm-verity or fs-verity, which provide a layer of
|
| 35 | integrity and trust. For example, IPE allows the definition of policies
|
| 36 | that trust files from a dm-verity protected device. dm-verity ensures the
|
| 37 | integrity of an entire device by providing a verifiable and immutable state
|
| 38 | of its contents. Similarly, fs-verity offers filesystem-level integrity
|
| 39 | checks, allowing IPE to enforce policies that trust files protected by
|
| 40 | fs-verity. These two features cannot be turned off once established, so
|
| 41 | they are considered immutable properties. These examples demonstrate how
|
| 42 | IPE leverages immutable properties, such as a file's origin and its
|
| 43 | integrity protection mechanisms, to make access control decisions.
|
| 44 |
|
| 45 | For the IPE policy, specifically, it grants the ability to enforce
|
| 46 | stringent access controls by assessing security properties against
|
| 47 | reference values defined within the policy. This assessment can be based on
|
| 48 | the existence of a security property (e.g., verifying if a file originates
|
| 49 | from initramfs) or evaluating the internal state of an immutable security
|
| 50 | property. The latter includes checking the roothash of a dm-verity
|
| 51 | protected device, determining whether dm-verity possesses a valid
|
| 52 | signature, assessing the digest of a fs-verity protected file, or
|
| 53 | determining whether fs-verity possesses a valid built-in signature. This
|
| 54 | nuanced approach to policy enforcement enables a highly secure and
|
| 55 | customizable system defense mechanism, tailored to specific security
|
| 56 | requirements and trust models.
|
| 57 |
|
| 58 | To enable IPE, ensure that ``CONFIG_SECURITY_IPE`` (under
|
| 59 | :menuselection:`Security -> Integrity Policy Enforcement (IPE)`) config
|
| 60 | option is enabled.
|
| 61 |
|
| 62 | Use Cases
|
| 63 | ---------
|
| 64 |
|
| 65 | IPE works best in fixed-function devices: devices in which their purpose
|
| 66 | is clearly defined and not supposed to be changed (e.g. network firewall
|
| 67 | device in a data center, an IoT device, etcetera), where all software and
|
| 68 | configuration is built and provisioned by the system owner.
|
| 69 |
|
| 70 | IPE is a long-way off for use in general-purpose computing: the Linux
|
| 71 | community as a whole tends to follow a decentralized trust model (known as
|
| 72 | the web of trust), which IPE has no support for it yet. Instead, IPE
|
| 73 | supports PKI (public key infrastructure), which generally designates a
|
| 74 | set of trusted entities that provide a measure of absolute trust.
|
| 75 |
|
| 76 | Additionally, while most packages are signed today, the files inside
|
| 77 | the packages (for instance, the executables), tend to be unsigned. This
|
| 78 | makes it difficult to utilize IPE in systems where a package manager is
|
| 79 | expected to be functional, without major changes to the package manager
|
| 80 | and ecosystem behind it.
|
| 81 |
|
| 82 | The digest_cache LSM is a system that when combined with IPE,
|
| 83 | could be used to enable and support general-purpose computing use cases.
|
| 84 |
|
| 85 | Known Limitations
|
| 86 | -----------------
|
| 87 |
|
| 88 | IPE cannot verify the integrity of anonymous executable memory, such as
|
| 89 | the trampolines created by gcc closures and libffi (<3.4.2), or JIT'd code.
|
| 90 | Unfortunately, as this is dynamically generated code, there is no way
|
| 91 | for IPE to ensure the integrity of this code to form a trust basis.
|
| 92 |
|
| 93 | IPE cannot verify the integrity of programs written in interpreted
|
| 94 | languages when these scripts are invoked by passing these program files
|
| 95 | to the interpreter. This is because the way interpreters execute these
|
| 96 | files; the scripts themselves are not evaluated as executable code
|
| 97 | through one of IPE's hooks, but they are merely text files that are read
|
| 98 | (as opposed to compiled executables). However, with the introduction of the
|
| 99 | ``AT_EXECVE_CHECK`` flag (:doc:`AT_EXECVE_CHECK </userspace-api/check_exec>`),
|
| 100 | interpreters can use it to signal the kernel that a script file will be executed,
|
| 101 | and request the kernel to perform LSM security checks on it.
|
| 102 |
|
| 103 | IPE's EXECUTE operation enforcement differs between compiled executables and
|
| 104 | interpreted scripts: For compiled executables, enforcement is triggered
|
| 105 | automatically by the kernel during ``execve()``, ``execveat()``, ``mmap()``
|
| 106 | and ``mprotect()`` syscalls when loading executable content. For interpreted
|
| 107 | scripts, enforcement requires explicit interpreter integration using
|
| 108 | ``execveat()`` with ``AT_EXECVE_CHECK`` flag. Unlike exec syscalls that IPE
|
| 109 | intercepts during the execution process, this mechanism needs the interpreter
|
| 110 | to take the initiative, and existing interpreters won't be automatically
|
| 111 | supported unless the signal call is added.
|
| 112 |
|
| 113 | Threat Model
|
| 114 | ------------
|
| 115 |
|
| 116 | IPE specifically targets the risk of tampering with user-space executable
|
| 117 | code after the kernel has initially booted, including the kernel modules
|
| 118 | loaded from userspace via ``modprobe`` or ``insmod``.
|
| 119 |
|
| 120 | To illustrate, consider a scenario where an untrusted binary, possibly
|
| 121 | malicious, is downloaded along with all necessary dependencies, including a
|
| 122 | loader and libc. The primary function of IPE in this context is to prevent
|
| 123 | the execution of such binaries and their dependencies.
|
| 124 |
|
| 125 | IPE achieves this by verifying the integrity and authenticity of all
|
| 126 | executable code before allowing them to run. It conducts a thorough
|
| 127 | check to ensure that the code's integrity is intact and that they match an
|
| 128 | authorized reference value (digest, signature, etc) as per the defined
|
| 129 | policy. If a binary does not pass this verification process, either
|
| 130 | because its integrity has been compromised or it does not meet the
|
| 131 | authorization criteria, IPE will deny its execution. Additionally, IPE
|
| 132 | generates audit logs which may be utilized to detect and analyze failures
|
| 133 | resulting from policy violation.
|
| 134 |
|
| 135 | Tampering threat scenarios include modification or replacement of
|
| 136 | executable code by a range of actors including:
|
| 137 |
|
| 138 | - Actors with physical access to the hardware
|
| 139 | - Actors with local network access to the system
|
| 140 | - Actors with access to the deployment system
|
| 141 | - Compromised internal systems under external control
|
| 142 | - Malicious end users of the system
|
| 143 | - Compromised end users of the system
|
| 144 | - Remote (external) compromise of the system
|
| 145 |
|
| 146 | IPE does not mitigate threats arising from malicious but authorized
|
| 147 | developers (with access to a signing certificate), or compromised
|
| 148 | developer tools used by them (i.e. return-oriented programming attacks).
|
| 149 | Additionally, IPE draws hard security boundary between userspace and
|
| 150 | kernelspace. As a result, kernel-level exploits are considered outside
|
| 151 | the scope of IPE and mitigation is left to other mechanisms.
|
| 152 |
|
| 153 | Policy
|
| 154 | ------
|
| 155 |
|
| 156 | IPE policy is a plain-text policy composed of multiple statements
|
| 157 | over several lines. There is one required line, at the top of the
|
| 158 | policy, indicating the policy name, and the policy version, for
|
| 159 | instance::
|
| 160 |
|
| 161 | policy_name=Ex_Policy policy_version=0.0.0
|
| 162 |
|
| 163 | The policy name is a unique key identifying this policy in a human
|
| 164 | readable name. This is used to create nodes under securityfs as well as
|
| 165 | uniquely identify policies to deploy new policies vs update existing
|
| 166 | policies.
|
| 167 |
|
| 168 | The policy version indicates the current version of the policy (NOT the
|
| 169 | policy syntax version). This is used to prevent rollback of policy to
|
| 170 | potentially insecure previous versions of the policy.
|
| 171 |
|
| 172 | The next portion of IPE policy are rules. Rules are formed by key=value
|
| 173 | pairs, known as properties. IPE rules require two properties: ``action``,
|
| 174 | which determines what IPE does when it encounters a match against the
|
| 175 | rule, and ``op``, which determines when the rule should be evaluated.
|
| 176 | The ordering is significant, a rule must start with ``op``, and end with
|
| 177 | ``action``. Thus, a minimal rule is::
|
| 178 |
|
| 179 | op=EXECUTE action=ALLOW
|
| 180 |
|
| 181 | This example will allow any execution. Additional properties are used to
|
| 182 | assess immutable security properties about the files being evaluated.
|
| 183 | These properties are intended to be descriptions of systems within the
|
| 184 | kernel that can provide a measure of integrity verification, such that IPE
|
| 185 | can determine the trust of the resource based on the value of the property.
|
| 186 |
|
| 187 | Rules are evaluated top-to-bottom. As a result, any revocation rules,
|
| 188 | or denies should be placed early in the file to ensure that these rules
|
| 189 | are evaluated before a rule with ``action=ALLOW``.
|
| 190 |
|
| 191 | IPE policy supports comments. The character '#' will function as a
|
| 192 | comment, ignoring all characters to the right of '#' until the newline.
|
| 193 |
|
| 194 | The default behavior of IPE evaluations can also be expressed in policy,
|
| 195 | through the ``DEFAULT`` statement. This can be done at a global level,
|
| 196 | or a per-operation level::
|
| 197 |
|
| 198 | # Global
|
| 199 | DEFAULT action=ALLOW
|
| 200 |
|
| 201 | # Operation Specific
|
| 202 | DEFAULT op=EXECUTE action=ALLOW
|
| 203 |
|
| 204 | A default must be set for all known operations in IPE. If you want to
|
| 205 | preserve older policies being compatible with newer kernels that can introduce
|
| 206 | new operations, set a global default of ``ALLOW``, then override the
|
| 207 | defaults on a per-operation basis (as above).
|
| 208 |
|
| 209 | With configurable policy-based LSMs, there's several issues with
|
| 210 | enforcing the configurable policies at startup, around reading and
|
| 211 | parsing the policy:
|
| 212 |
|
| 213 | 1. The kernel *should* not read files from userspace, so directly reading
|
| 214 | the policy file is prohibited.
|
| 215 | 2. The kernel command line has a character limit, and one kernel module
|
| 216 | should not reserve the entire character limit for its own
|
| 217 | configuration.
|
| 218 | 3. There are various boot loaders in the kernel ecosystem, so handing
|
| 219 | off a memory block would be costly to maintain.
|
| 220 |
|
| 221 | As a result, IPE has addressed this problem through a concept of a "boot
|
| 222 | policy". A boot policy is a minimal policy which is compiled into the
|
| 223 | kernel. This policy is intended to get the system to a state where
|
| 224 | userspace is set up and ready to receive commands, at which point a more
|
| 225 | complex policy can be deployed via securityfs. The boot policy can be
|
| 226 | specified via ``SECURITY_IPE_BOOT_POLICY`` config option, which accepts
|
| 227 | a path to a plain-text version of the IPE policy to apply. This policy
|
| 228 | will be compiled into the kernel. If not specified, IPE will be disabled
|
| 229 | until a policy is deployed and activated through securityfs.
|
| 230 |
|
| 231 | Deploying Policies
|
| 232 | ~~~~~~~~~~~~~~~~~~
|
| 233 |
|
| 234 | Policies can be deployed from userspace through securityfs. These policies
|
| 235 | are signed through the PKCS#7 message format to enforce some level of
|
| 236 | authorization of the policies (prohibiting an attacker from gaining
|
| 237 | unconstrained root, and deploying an "allow all" policy). These
|
| 238 | policies must be signed by a certificate that chains to the
|
| 239 | ``SYSTEM_TRUSTED_KEYRING``, or to the secondary and/or platform keyrings if
|
| 240 | ``CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING`` and/or
|
| 241 | ``CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING`` are enabled, respectively.
|
| 242 | With openssl, the policy can be signed by::
|
| 243 |
|
| 244 | openssl smime -sign \
|
| 245 | -in "$MY_POLICY" \
|
| 246 | -signer "$MY_CERTIFICATE" \
|
| 247 | -inkey "$MY_PRIVATE_KEY" \
|
| 248 | -noattr \
|
| 249 | -nodetach \
|
| 250 | -nosmimecap \
|
| 251 | -outform der \
|
| 252 | -out "$MY_POLICY.p7b"
|
| 253 |
|
| 254 | Deploying the policies is done through securityfs, through the
|
| 255 | ``new_policy`` node. To deploy a policy, simply cat the file into the
|
| 256 | securityfs node::
|
| 257 |
|
| 258 | cat "$MY_POLICY.p7b" > /sys/kernel/security/ipe/new_policy
|
| 259 |
|
| 260 | Upon success, this will create one subdirectory under
|
| 261 | ``/sys/kernel/security/ipe/policies/``. The subdirectory will be the
|
| 262 | ``policy_name`` field of the policy deployed, so for the example above,
|
| 263 | the directory will be ``/sys/kernel/security/ipe/policies/Ex_Policy``.
|
| 264 | Within this directory, there will be seven files: ``pkcs7``, ``policy``,
|
| 265 | ``name``, ``version``, ``active``, ``update``, and ``delete``.
|
| 266 |
|
| 267 | The ``pkcs7`` file is read-only. Reading it returns the raw PKCS#7 data
|
| 268 | that was provided to the kernel, representing the policy. If the policy being
|
| 269 | read is the boot policy, this will return ``ENOENT``, as it is not signed.
|
| 270 |
|
| 271 | The ``policy`` file is read only. Reading it returns the PKCS#7 inner
|
| 272 | content of the policy, which will be the plain text policy.
|
| 273 |
|
| 274 | The ``active`` file is used to set a policy as the currently active policy.
|
| 275 | This file is rw, and accepts a value of ``"1"`` to set the policy as active.
|
| 276 | Since only a single policy can be active at one time, all other policies
|
| 277 | will be marked inactive. The policy being marked active must have a policy
|
| 278 | version greater or equal to the currently-running version.
|
| 279 |
|
| 280 | The ``update`` file is used to update a policy that is already present
|
| 281 | in the kernel. This file is write-only and accepts a PKCS#7 signed
|
| 282 | policy. Two checks will always be performed on this policy: First, the
|
| 283 | ``policy_names`` must match with the updated version and the existing
|
| 284 | version. Second the updated policy must have a policy version greater than
|
| 285 | the currently-running version. This is to prevent rollback attacks.
|
| 286 |
|
| 287 | The ``delete`` file is used to remove a policy that is no longer needed.
|
| 288 | This file is write-only and accepts a value of ``1`` to delete the policy.
|
| 289 | On deletion, the securityfs node representing the policy will be removed.
|
| 290 | However, delete the current active policy is not allowed and will return
|
| 291 | an operation not permitted error.
|
| 292 |
|
| 293 | Similarly, writing to both ``update`` and ``new_policy`` could result in
|
| 294 | bad message(policy syntax error) or file exists error. The latter error happens
|
| 295 | when trying to deploy a policy with a ``policy_name`` while the kernel already
|
| 296 | has a deployed policy with the same ``policy_name``.
|
| 297 |
|
| 298 | Deploying a policy will *not* cause IPE to start enforcing the policy. IPE will
|
| 299 | only enforce the policy marked active. Note that only one policy can be active
|
| 300 | at a time.
|
| 301 |
|
| 302 | Once deployment is successful, the policy can be activated, by writing file
|
| 303 | ``/sys/kernel/security/ipe/policies/$policy_name/active``.
|
| 304 | For example, the ``Ex_Policy`` can be activated by::
|
| 305 |
|
| 306 | echo 1 > "/sys/kernel/security/ipe/policies/Ex_Policy/active"
|
| 307 |
|
| 308 | From above point on, ``Ex_Policy`` is now the enforced policy on the
|
| 309 | system.
|
| 310 |
|
| 311 | IPE also provides a way to delete policies. This can be done via the
|
| 312 | ``delete`` securityfs node,
|
| 313 | ``/sys/kernel/security/ipe/policies/$policy_name/delete``.
|
| 314 | Writing ``1`` to that file deletes the policy::
|
| 315 |
|
| 316 | echo 1 > "/sys/kernel/security/ipe/policies/$policy_name/delete"
|
| 317 |
|
| 318 | There is only one requirement to delete a policy: the policy being deleted
|
| 319 | must be inactive.
|
| 320 |
|
| 321 | .. NOTE::
|
| 322 |
|
| 323 | If a traditional MAC system is enabled (SELinux, apparmor, smack), all
|
| 324 | writes to ipe's securityfs nodes require ``CAP_MAC_ADMIN``.
|
| 325 |
|
| 326 | Modes
|
| 327 | ~~~~~
|
| 328 |
|
| 329 | IPE supports two modes of operation: permissive (similar to SELinux's
|
| 330 | permissive mode) and enforced. In permissive mode, all events are
|
| 331 | checked and policy violations are logged, but the policy is not really
|
| 332 | enforced. This allows users to test policies before enforcing them.
|
| 333 |
|
| 334 | The default mode is enforce, and can be changed via the kernel command
|
| 335 | line parameter ``ipe.enforce=(0|1)``, or the securityfs node
|
| 336 | ``/sys/kernel/security/ipe/enforce``.
|
| 337 |
|
| 338 | .. NOTE::
|
| 339 |
|
| 340 | If a traditional MAC system is enabled (SELinux, apparmor, smack, etcetera),
|
| 341 | all writes to ipe's securityfs nodes require ``CAP_MAC_ADMIN``.
|
| 342 |
|
| 343 | Audit Events
|
| 344 | ~~~~~~~~~~~~
|
| 345 |
|
| 346 | 1420 AUDIT_IPE_ACCESS
|
| 347 | ^^^^^^^^^^^^^^^^^^^^^
|
| 348 | Event Examples::
|
| 349 |
|
| 350 | type=1420 audit(1653364370.067:61): ipe_op=EXECUTE ipe_hook=MMAP enforcing=1 pid=2241 comm="ld-linux.so" path="/deny/lib/libc.so.6" dev="sda2" ino=14549020 rule="DEFAULT action=DENY"
|
| 351 | type=1300 audit(1653364370.067:61): SYSCALL arch=c000003e syscall=9 success=no exit=-13 a0=7f1105a28000 a1=195000 a2=5 a3=812 items=0 ppid=2219 pid=2241 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ld-linux.so" exe="/tmp/ipe-test/lib/ld-linux.so" subj=unconfined key=(null)
|
| 352 | type=1327 audit(1653364370.067:61): 707974686F6E3300746573742F6D61696E2E7079002D6E00
|
| 353 |
|
| 354 | type=1420 audit(1653364735.161:64): ipe_op=EXECUTE ipe_hook=MMAP enforcing=1 pid=2472 comm="mmap_test" path=? dev=? ino=? rule="DEFAULT action=DENY"
|
| 355 | type=1300 audit(1653364735.161:64): SYSCALL arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=1000 a2=4 a3=21 items=0 ppid=2219 pid=2472 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="mmap_test" exe="/root/overlake_test/upstream_test/vol_fsverity/bin/mmap_test" subj=unconfined key=(null)
|
| 356 | type=1327 audit(1653364735.161:64): 707974686F6E3300746573742F6D61696E2E7079002D6E00
|
| 357 |
|
| 358 | This event indicates that IPE made an access control decision; the IPE
|
| 359 | specific record (1420) is always emitted in conjunction with a
|
| 360 | ``AUDITSYSCALL`` record.
|
| 361 |
|
| 362 | Determining whether IPE is in permissive or enforced mode can be derived
|
| 363 | from ``success`` property and exit code of the ``AUDITSYSCALL`` record.
|
| 364 |
|
| 365 |
|
| 366 | Field descriptions:
|
| 367 |
|
| 368 | +-----------+------------+-----------+---------------------------------------------------------------------------------+
|
| 369 | | Field | Value Type | Optional? | Description of Value |
|
| 370 | +===========+============+===========+=================================================================================+
|
| 371 | | ipe_op | string | No | The IPE operation name associated with the log |
|
| 372 | +-----------+------------+-----------+---------------------------------------------------------------------------------+
|
| 373 | | ipe_hook | string | No | The name of the LSM hook that triggered the IPE event |
|
| 374 | +-----------+------------+-----------+---------------------------------------------------------------------------------+
|
| 375 | | enforcing | integer | No | The current IPE enforcing state 1 is in enforcing mode, 0 is in permissive mode |
|
| 376 | +-----------+------------+-----------+---------------------------------------------------------------------------------+
|
| 377 | | pid | integer | No | The pid of the process that triggered the IPE event. |
|
| 378 | +-----------+------------+-----------+---------------------------------------------------------------------------------+
|
| 379 | | comm | string | No | The command line program name of the process that triggered the IPE event |
|
| 380 | +-----------+------------+-----------+---------------------------------------------------------------------------------+
|
| 381 | | path | string | Yes | The absolute path to the evaluated file |
|
| 382 | +-----------+------------+-----------+---------------------------------------------------------------------------------+
|
| 383 | | ino | integer | Yes | The inode number of the evaluated file |
|
| 384 | +-----------+------------+-----------+---------------------------------------------------------------------------------+
|
| 385 | | dev | string | Yes | The device name of the evaluated file, e.g. vda |
|
| 386 | +-----------+------------+-----------+---------------------------------------------------------------------------------+
|
| 387 | | rule | string | No | The matched policy rule |
|
| 388 | +-----------+------------+-----------+---------------------------------------------------------------------------------+
|
| 389 |
|
| 390 | 1421 AUDIT_IPE_CONFIG_CHANGE
|
| 391 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| 392 |
|
| 393 | Event Example::
|
| 394 |
|
| 395 | type=1421 audit(1653425583.136:54): old_active_pol_name="Allow_All" old_active_pol_version=0.0.0 old_policy_digest=sha256:E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 new_active_pol_name="boot_verified" new_active_pol_version=0.0.0 new_policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F26765076DD8EED7B8F4DB auid=4294967295 ses=4294967295 lsm=ipe res=1
|
| 396 | type=1300 audit(1653425583.136:54): SYSCALL arch=c000003e syscall=1 success=yes exit=2 a0=3 a1=5596fcae1fb0 a2=2 a3=2 items=0 ppid=184 pid=229 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10" key=(null)
|
| 397 | type=1327 audit(1653425583.136:54): PROCTITLE proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2
|
| 398 |
|
| 399 | This event indicates that IPE switched the active poliy from one to another
|
| 400 | along with the version and the hash digest of the two policies.
|
| 401 | Note IPE can only have one policy active at a time, all access decision
|
| 402 | evaluation is based on the current active policy.
|
| 403 | The normal procedure to deploy a new policy is loading the policy to deploy
|
| 404 | into the kernel first, then switch the active policy to it.
|
| 405 |
|
| 406 | This record will always be emitted in conjunction with a ``AUDITSYSCALL`` record for the ``write`` syscall.
|
| 407 |
|
| 408 | Field descriptions:
|
| 409 |
|
| 410 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 411 | | Field | Value Type | Optional? | Description of Value |
|
| 412 | +========================+============+===========+===================================================+
|
| 413 | | old_active_pol_name | string | Yes | The name of previous active policy |
|
| 414 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 415 | | old_active_pol_version | string | Yes | The version of previous active policy |
|
| 416 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 417 | | old_policy_digest | string | Yes | The hash of previous active policy |
|
| 418 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 419 | | new_active_pol_name | string | No | The name of current active policy |
|
| 420 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 421 | | new_active_pol_version | string | No | The version of current active policy |
|
| 422 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 423 | | new_policy_digest | string | No | The hash of current active policy |
|
| 424 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 425 | | auid | integer | No | The login user ID |
|
| 426 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 427 | | ses | integer | No | The login session ID |
|
| 428 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 429 | | lsm | string | No | The lsm name associated with the event |
|
| 430 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 431 | | res | integer | No | The result of the audited operation(success/fail) |
|
| 432 | +------------------------+------------+-----------+---------------------------------------------------+
|
| 433 |
|
| 434 | 1422 AUDIT_IPE_POLICY_LOAD
|
| 435 | ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| 436 |
|
| 437 | Event Example::
|
| 438 |
|
| 439 | type=1422 audit(1653425529.927:53): policy_name="boot_verified" policy_version=0.0.0 policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F26765076DD8EED7B8F4DB auid=4294967295 ses=4294967295 lsm=ipe res=1 errno=0
|
| 440 | type=1300 audit(1653425529.927:53): arch=c000003e syscall=1 success=yes exit=2567 a0=3 a1=5596fcae1fb0 a2=a07 a3=2 items=0 ppid=184 pid=229 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10" key=(null)
|
| 441 | type=1327 audit(1653425529.927:53): PROCTITLE proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2E
|
| 442 |
|
| 443 | This record indicates a new policy has been loaded into the kernel with the policy name, policy version and policy hash.
|
| 444 |
|
| 445 | This record will always be emitted in conjunction with a ``AUDITSYSCALL`` record for the ``write`` syscall.
|
| 446 |
|
| 447 | Field descriptions:
|
| 448 |
|
| 449 | +----------------+------------+-----------+-------------------------------------------------------------+
|
| 450 | | Field | Value Type | Optional? | Description of Value |
|
| 451 | +================+============+===========+=============================================================+
|
| 452 | | policy_name | string | Yes | The policy_name |
|
| 453 | +----------------+------------+-----------+-------------------------------------------------------------+
|
| 454 | | policy_version | string | Yes | The policy_version |
|
| 455 | +----------------+------------+-----------+-------------------------------------------------------------+
|
| 456 | | policy_digest | string | Yes | The policy hash |
|
| 457 | +----------------+------------+-----------+-------------------------------------------------------------+
|
| 458 | | auid | integer | No | The login user ID |
|
| 459 | +----------------+------------+-----------+-------------------------------------------------------------+
|
| 460 | | ses | integer | No | The login session ID |
|
| 461 | +----------------+------------+-----------+-------------------------------------------------------------+
|
| 462 | | lsm | string | No | The lsm name associated with the event |
|
| 463 | +----------------+------------+-----------+-------------------------------------------------------------+
|
| 464 | | res | integer | No | The result of the audited operation(success/fail) |
|
| 465 | +----------------+------------+-----------+-------------------------------------------------------------+
|
| 466 | | errno | integer | No | Error code from policy loading operations (see table below) |
|
| 467 | +----------------+------------+-----------+-------------------------------------------------------------+
|
| 468 |
|
| 469 | Policy error codes (errno):
|
| 470 |
|
| 471 | The following table lists the error codes that may appear in the errno field while loading or updating the policy:
|
| 472 |
|
| 473 | +----------------+--------------------------------------------------------+
|
| 474 | | Error Code | Description |
|
| 475 | +================+========================================================+
|
| 476 | | 0 | Success |
|
| 477 | +----------------+--------------------------------------------------------+
|
| 478 | | -EPERM | Insufficient permission |
|
| 479 | +----------------+--------------------------------------------------------+
|
| 480 | | -EEXIST | Same name policy already deployed |
|
| 481 | +----------------+--------------------------------------------------------+
|
| 482 | | -EBADMSG | Policy is invalid |
|
| 483 | +----------------+--------------------------------------------------------+
|
| 484 | | -ENOMEM | Out of memory (OOM) |
|
| 485 | +----------------+--------------------------------------------------------+
|
| 486 | | -ERANGE | Policy version number overflow |
|
| 487 | +----------------+--------------------------------------------------------+
|
| 488 | | -EINVAL | Policy version parsing error |
|
| 489 | +----------------+--------------------------------------------------------+
|
| 490 | | -ENOKEY | Key used to sign the IPE policy not found in keyring |
|
| 491 | +----------------+--------------------------------------------------------+
|
| 492 | | -EKEYREJECTED | Policy signature verification failed |
|
| 493 | +----------------+--------------------------------------------------------+
|
| 494 | | -ESTALE | Attempting to update an IPE policy with older version |
|
| 495 | +----------------+--------------------------------------------------------+
|
| 496 | | -ENOENT | Policy was deleted while updating |
|
| 497 | +----------------+--------------------------------------------------------+
|
| 498 |
|
| 499 | 1404 AUDIT_MAC_STATUS
|
| 500 | ^^^^^^^^^^^^^^^^^^^^^
|
| 501 |
|
| 502 | Event Examples::
|
| 503 |
|
| 504 | type=1404 audit(1653425689.008:55): enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=ipe res=1
|
| 505 | type=1300 audit(1653425689.008:55): arch=c000003e syscall=1 success=yes exit=2 a0=1 a1=55c1065e5c60 a2=2 a3=0 items=0 ppid=405 pid=441 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=)
|
| 506 | type=1327 audit(1653425689.008:55): proctitle="-bash"
|
| 507 |
|
| 508 | type=1404 audit(1653425689.008:55): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=ipe res=1
|
| 509 | type=1300 audit(1653425689.008:55): arch=c000003e syscall=1 success=yes exit=2 a0=1 a1=55c1065e5c60 a2=2 a3=0 items=0 ppid=405 pid=441 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=)
|
| 510 | type=1327 audit(1653425689.008:55): proctitle="-bash"
|
| 511 |
|
| 512 | This record will always be emitted in conjunction with a ``AUDITSYSCALL`` record for the ``write`` syscall.
|
| 513 |
|
| 514 | Field descriptions:
|
| 515 |
|
| 516 | +---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
| 517 | | Field | Value Type | Optional? | Description of Value |
|
| 518 | +===============+============+===========+=================================================================================================+
|
| 519 | | enforcing | integer | No | The enforcing state IPE is being switched to, 1 is in enforcing mode, 0 is in permissive mode |
|
| 520 | +---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
| 521 | | old_enforcing | integer | No | The enforcing state IPE is being switched from, 1 is in enforcing mode, 0 is in permissive mode |
|
| 522 | +---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
| 523 | | auid | integer | No | The login user ID |
|
| 524 | +---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
| 525 | | ses | integer | No | The login session ID |
|
| 526 | +---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
| 527 | | enabled | integer | No | The new TTY audit enabled setting |
|
| 528 | +---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
| 529 | | old-enabled | integer | No | The old TTY audit enabled setting |
|
| 530 | +---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
| 531 | | lsm | string | No | The lsm name associated with the event |
|
| 532 | +---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
| 533 | | res | integer | No | The result of the audited operation(success/fail) |
|
| 534 | +---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
| 535 |
|
| 536 |
|
| 537 | Success Auditing
|
| 538 | ^^^^^^^^^^^^^^^^
|
| 539 |
|
| 540 | IPE supports success auditing. When enabled, all events that pass IPE
|
| 541 | policy and are not blocked will emit an audit event. This is disabled by
|
| 542 | default, and can be enabled via the kernel command line
|
| 543 | ``ipe.success_audit=(0|1)`` or
|
| 544 | ``/sys/kernel/security/ipe/success_audit`` securityfs file.
|
| 545 |
|
| 546 | This is *very* noisy, as IPE will check every userspace binary on the
|
| 547 | system, but is useful for debugging policies.
|
| 548 |
|
| 549 | .. NOTE::
|
| 550 |
|
| 551 | If a traditional MAC system is enabled (SELinux, apparmor, smack, etcetera),
|
| 552 | all writes to ipe's securityfs nodes require ``CAP_MAC_ADMIN``.
|
| 553 |
|
| 554 | Properties
|
| 555 | ----------
|
| 556 |
|
| 557 | As explained above, IPE properties are ``key=value`` pairs expressed in IPE
|
| 558 | policy. Two properties are built-into the policy parser: 'op' and 'action'.
|
| 559 | The other properties are used to restrict immutable security properties
|
| 560 | about the files being evaluated. Currently those properties are:
|
| 561 | '``boot_verified``', '``dmverity_signature``', '``dmverity_roothash``',
|
| 562 | '``fsverity_signature``', '``fsverity_digest``'. A description of all
|
| 563 | properties supported by IPE are listed below:
|
| 564 |
|
| 565 | op
|
| 566 | ~~
|
| 567 |
|
| 568 | Indicates the operation for a rule to apply to. Must be in every rule,
|
| 569 | as the first token. IPE supports the following operations:
|
| 570 |
|
| 571 | ``EXECUTE``
|
| 572 |
|
| 573 | Pertains to any file attempting to be executed, or loaded as an
|
| 574 | executable.
|
| 575 |
|
| 576 | ``FIRMWARE``:
|
| 577 |
|
| 578 | Pertains to firmware being loaded via the firmware_class interface.
|
| 579 | This covers both the preallocated buffer and the firmware file
|
| 580 | itself.
|
| 581 |
|
| 582 | ``KMODULE``:
|
| 583 |
|
| 584 | Pertains to loading kernel modules via ``modprobe`` or ``insmod``.
|
| 585 |
|
| 586 | ``KEXEC_IMAGE``:
|
| 587 |
|
| 588 | Pertains to kernel images loading via ``kexec``.
|
| 589 |
|
| 590 | ``KEXEC_INITRAMFS``
|
| 591 |
|
| 592 | Pertains to initrd images loading via ``kexec --initrd``.
|
| 593 |
|
| 594 | ``POLICY``:
|
| 595 |
|
| 596 | Controls loading policies via reading a kernel-space initiated read.
|
| 597 |
|
| 598 | An example of such is loading IMA policies by writing the path
|
| 599 | to the policy file to ``$securityfs/ima/policy``
|
| 600 |
|
| 601 | ``X509_CERT``:
|
| 602 |
|
| 603 | Controls loading IMA certificates through the Kconfigs,
|
| 604 | ``CONFIG_IMA_X509_PATH`` and ``CONFIG_EVM_X509_PATH``.
|
| 605 |
|
| 606 | action
|
| 607 | ~~~~~~
|
| 608 |
|
| 609 | Determines what IPE should do when a rule matches. Must be in every
|
| 610 | rule, as the final clause. Can be one of:
|
| 611 |
|
| 612 | ``ALLOW``:
|
| 613 |
|
| 614 | If the rule matches, explicitly allow access to the resource to proceed
|
| 615 | without executing any more rules.
|
| 616 |
|
| 617 | ``DENY``:
|
| 618 |
|
| 619 | If the rule matches, explicitly prohibit access to the resource to
|
| 620 | proceed without executing any more rules.
|
| 621 |
|
| 622 | boot_verified
|
| 623 | ~~~~~~~~~~~~~
|
| 624 |
|
| 625 | This property can be utilized for authorization of files from initramfs.
|
| 626 | The format of this property is::
|
| 627 |
|
| 628 | boot_verified=(TRUE|FALSE)
|
| 629 |
|
| 630 |
|
| 631 | .. WARNING::
|
| 632 |
|
| 633 | This property will trust files from initramfs(rootfs). It should
|
| 634 | only be used during early booting stage. Before mounting the real
|
| 635 | rootfs on top of the initramfs, initramfs script will recursively
|
| 636 | remove all files and directories on the initramfs. This is typically
|
| 637 | implemented by using switch_root(8) [#switch_root]_. Therefore the
|
| 638 | initramfs will be empty and not accessible after the real
|
| 639 | rootfs takes over. It is advised to switch to a different policy
|
| 640 | that doesn't rely on the property after this point.
|
| 641 | This ensures that the trust policies remain relevant and effective
|
| 642 | throughout the system's operation.
|
| 643 |
|
| 644 | dmverity_roothash
|
| 645 | ~~~~~~~~~~~~~~~~~
|
| 646 |
|
| 647 | This property can be utilized for authorization or revocation of
|
| 648 | specific dm-verity volumes, identified via their root hashes. It has a
|
| 649 | dependency on the DM_VERITY module. This property is controlled by
|
| 650 | the ``IPE_PROP_DM_VERITY`` config option, it will be automatically
|
| 651 | selected when ``SECURITY_IPE`` and ``DM_VERITY`` are all enabled.
|
| 652 | The format of this property is::
|
| 653 |
|
| 654 | dmverity_roothash=DigestName:HexadecimalString
|
| 655 |
|
| 656 | The supported DigestNames for dmverity_roothash are
|
| 657 |
|
| 658 | + blake2b-512
|
| 659 | + blake2s-256
|
| 660 | + sha256
|
| 661 | + sha384
|
| 662 | + sha512
|
| 663 | + sha3-224
|
| 664 | + sha3-256
|
| 665 | + sha3-384
|
| 666 | + sha3-512
|
| 667 | + sm3
|
| 668 | + rmd160
|
| 669 |
|
| 670 | dmverity_signature
|
| 671 | ~~~~~~~~~~~~~~~~~~
|
| 672 |
|
| 673 | This property can be utilized for authorization of all dm-verity
|
| 674 | volumes that have a signed roothash that validated by a keyring
|
| 675 | specified by dm-verity's configuration, either the system trusted
|
| 676 | keyring, or the secondary keyring. It depends on
|
| 677 | ``DM_VERITY_VERIFY_ROOTHASH_SIG`` config option and is controlled by
|
| 678 | the ``IPE_PROP_DM_VERITY_SIGNATURE`` config option, it will be automatically
|
| 679 | selected when ``SECURITY_IPE``, ``DM_VERITY`` and
|
| 680 | ``DM_VERITY_VERIFY_ROOTHASH_SIG`` are all enabled.
|
| 681 | The format of this property is::
|
| 682 |
|
| 683 | dmverity_signature=(TRUE|FALSE)
|
| 684 |
|
| 685 | fsverity_digest
|
| 686 | ~~~~~~~~~~~~~~~
|
| 687 |
|
| 688 | This property can be utilized for authorization of specific fsverity
|
| 689 | enabled files, identified via their fsverity digests.
|
| 690 | It depends on ``FS_VERITY`` config option and is controlled by
|
| 691 | the ``IPE_PROP_FS_VERITY`` config option, it will be automatically
|
| 692 | selected when ``SECURITY_IPE`` and ``FS_VERITY`` are all enabled.
|
| 693 | The format of this property is::
|
| 694 |
|
| 695 | fsverity_digest=DigestName:HexadecimalString
|
| 696 |
|
| 697 | The supported DigestNames for fsverity_digest are
|
| 698 |
|
| 699 | + sha256
|
| 700 | + sha512
|
| 701 |
|
| 702 | fsverity_signature
|
| 703 | ~~~~~~~~~~~~~~~~~~
|
| 704 |
|
| 705 | This property is used to authorize all fs-verity enabled files that have
|
| 706 | been verified by fs-verity's built-in signature mechanism. The signature
|
| 707 | verification relies on a key stored within the ".fs-verity" keyring. It
|
| 708 | depends on ``FS_VERITY_BUILTIN_SIGNATURES`` config option and
|
| 709 | it is controlled by the ``IPE_PROP_FS_VERITY`` config option,
|
| 710 | it will be automatically selected when ``SECURITY_IPE``, ``FS_VERITY``
|
| 711 | and ``FS_VERITY_BUILTIN_SIGNATURES`` are all enabled.
|
| 712 | The format of this property is::
|
| 713 |
|
| 714 | fsverity_signature=(TRUE|FALSE)
|
| 715 |
|
| 716 | Policy Examples
|
| 717 | ---------------
|
| 718 |
|
| 719 | Allow all
|
| 720 | ~~~~~~~~~
|
| 721 |
|
| 722 | ::
|
| 723 |
|
| 724 | policy_name=Allow_All policy_version=0.0.0
|
| 725 | DEFAULT action=ALLOW
|
| 726 |
|
| 727 | Allow only initramfs
|
| 728 | ~~~~~~~~~~~~~~~~~~~~
|
| 729 |
|
| 730 | ::
|
| 731 |
|
| 732 | policy_name=Allow_Initramfs policy_version=0.0.0
|
| 733 | DEFAULT action=DENY
|
| 734 |
|
| 735 | op=EXECUTE boot_verified=TRUE action=ALLOW
|
| 736 |
|
| 737 | Allow any signed and validated dm-verity volume and the initramfs
|
| 738 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 739 |
|
| 740 | ::
|
| 741 |
|
| 742 | policy_name=Allow_Signed_DMV_And_Initramfs policy_version=0.0.0
|
| 743 | DEFAULT action=DENY
|
| 744 |
|
| 745 | op=EXECUTE boot_verified=TRUE action=ALLOW
|
| 746 | op=EXECUTE dmverity_signature=TRUE action=ALLOW
|
| 747 |
|
| 748 | Prohibit execution from a specific dm-verity volume
|
| 749 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 750 |
|
| 751 | ::
|
| 752 |
|
| 753 | policy_name=Deny_DMV_By_Roothash policy_version=0.0.0
|
| 754 | DEFAULT action=DENY
|
| 755 |
|
| 756 | op=EXECUTE dmverity_roothash=sha256:cd2c5bae7c6c579edaae4353049d58eb5f2e8be0244bf05345bc8e5ed257baff action=DENY
|
| 757 |
|
| 758 | op=EXECUTE boot_verified=TRUE action=ALLOW
|
| 759 | op=EXECUTE dmverity_signature=TRUE action=ALLOW
|
| 760 |
|
| 761 | Allow only a specific dm-verity volume
|
| 762 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 763 |
|
| 764 | ::
|
| 765 |
|
| 766 | policy_name=Allow_DMV_By_Roothash policy_version=0.0.0
|
| 767 | DEFAULT action=DENY
|
| 768 |
|
| 769 | op=EXECUTE dmverity_roothash=sha256:401fcec5944823ae12f62726e8184407a5fa9599783f030dec146938 action=ALLOW
|
| 770 |
|
| 771 | Allow any fs-verity file with a valid built-in signature
|
| 772 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 773 |
|
| 774 | ::
|
| 775 |
|
| 776 | policy_name=Allow_Signed_And_Validated_FSVerity policy_version=0.0.0
|
| 777 | DEFAULT action=DENY
|
| 778 |
|
| 779 | op=EXECUTE fsverity_signature=TRUE action=ALLOW
|
| 780 |
|
| 781 | Allow execution of a specific fs-verity file
|
| 782 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 783 |
|
| 784 | ::
|
| 785 |
|
| 786 | policy_name=ALLOW_FSV_By_Digest policy_version=0.0.0
|
| 787 | DEFAULT action=DENY
|
| 788 |
|
| 789 | op=EXECUTE fsverity_digest=sha256:fd88f2b8824e197f850bf4c5109bea5cf0ee38104f710843bb72da796ba5af9e action=ALLOW
|
| 790 |
|
| 791 | Additional Information
|
| 792 | ----------------------
|
| 793 |
|
| 794 | - `Github Repository <https://github.com/microsoft/ipe>`_
|
| 795 | - :doc:`Developer and design docs for IPE </security/ipe>`
|
| 796 |
|
| 797 | FAQ
|
| 798 | ---
|
| 799 |
|
| 800 | Q:
|
| 801 | What's the difference between other LSMs which provide a measure of
|
| 802 | trust-based access control?
|
| 803 |
|
| 804 | A:
|
| 805 |
|
| 806 | In general, there's two other LSMs that can provide similar functionality:
|
| 807 | IMA, and Loadpin.
|
| 808 |
|
| 809 | IMA and IPE are functionally very similar. The significant difference between
|
| 810 | the two is the policy.
|
| 811 |
|
| 812 | Loadpin and IPE differ fairly dramatically, as Loadpin only covers the IPE's
|
| 813 | kernel read operations, whereas IPE is capable of controlling execution
|
| 814 | on top of kernel read. The trust model is also different; Loadpin roots its
|
| 815 | trust in the initial super-block, whereas trust in IPE is stemmed from kernel
|
| 816 | itself (via ``SYSTEM_TRUSTED_KEYS``).
|
| 817 |
|
| 818 | -----------
|
| 819 |
|
| 820 |
|
| 821 |
|
| 822 |
|
| 823 | this topic.
|
| 824 |
|
| 825 |
|
| 826 |
|
| 827 |
|
| 828 | the Linux crypto API; IPE does not impose any
|
| 829 | restrictions on the digest algorithm itself;
|
| 830 | thus, this list may be out of date.
|
| 831 |
|
| 832 |
|
| 833 | kernel's fsverity support; IPE does not impose any
|
| 834 | restrictions on the digest algorithm itself;
|
| 835 | thus, this list may be out of date.
|