Changes in Kconfig

02e2f9aa - ipe: allow secondary and platform keyrings to install/update policies

Sun, 15 Sep 2024 09:11:19 +0000

ipe: allow secondary and platform keyrings to install/update policiesThe current policy management makes it impossible to use IPEin a general purpose distribution. In such cases the users are notbuilding the kernel, the distribution is, and access to the privatekey included in the trusted keyring is, for obvious reason, notavailable.This means that users have no way to enable IPE, since there willbe no built-in generic policy, and no access to the key to signupdates validated by the trusted keyring.Just as we do for dm-verity, kernel modules and more, allow thesecondary and platform keyrings to also validate policies. Thisallows users enrolling their own keys in UEFI db or MOK to alsosign policies, and enroll them. This makes it sensible to enableIPE in general purpose distributions, as it becomes usable byany user wishing to do so. Keys in these keyrings can alreadyload kernels and kernel modules, so there is no securitydowngrade.Add a kconfig each, like dm-verity does, but default to enabled ifthe dependencies are available.Signed-off-by: Luca Boccassi Reviewed-by: Serge Hallyn [FW: fixed some style issues]Signed-off-by: Fan Wu List of files: /linux-6.15/security/ipe/Kconfig

10ca05a7 - ipe: kunit test for parser

Sat, 03 Aug 2024 06:08:32 +0000

ipe: kunit test for parserAdd various happy/unhappy unit tests for both IPE's policy parser.Besides, a test suite for IPE functionality is available athttps://github.com/microsoft/ipe/tree/test-suiteSigned-off-by: Deven Bowers Signed-off-by: Fan Wu Signed-off-by: Paul Moore List of files: /linux-6.15/security/ipe/Kconfig

ba199dc9 - scripts: add boot policy generation program

Sat, 03 Aug 2024 06:08:31 +0000

scripts: add boot policy generation programEnables an IPE policy to be enforced from kernel start, enabling accesscontrol based on trust from kernel startup. This is accomplished bytransforming an IPE policy indicated by CONFIG_IPE_BOOT_POLICY into ac-string literal that is parsed at kernel startup as an unsigned policy.Signed-off-by: Deven Bowers Signed-off-by: Fan Wu Signed-off-by: Paul Moore List of files: /linux-6.15/security/ipe/Kconfig

31f8c868 - ipe: enable support for fs-verity as a trust provider

Sat, 03 Aug 2024 06:08:30 +0000

ipe: enable support for fs-verity as a trust providerEnable IPE policy authors to indicate trust for a singular fsverityfile, identified by the digest information, through "fsverity_digest"and all files using valid fsverity builtin signatures via"fsverity_signature".This enables file-level integrity claims to be expressed in IPE,allowing individual files to be authorized, giving some flexibilityfor policy authors. Such file-level claims are important to be expressedfor enforcing the integrity of packages, as well as address some of thescalability issues in a sole dm-verity based solution (# of loop backdevices, etc).This solution cannot be done in userspace as the minimum threat thatIPE should mitigate is an attacker downloads malicious payload withall required dependencies. These dependencies can lack the userspacecheck, bypassing the protection entirely. A similar attack succeeds ifthe userspace component is replaced with a version that does notperform the check. As a result, this can only be done in the commonentry point - the kernel.Signed-off-by: Deven Bowers Signed-off-by: Fan Wu Signed-off-by: Paul Moore List of files: /linux-6.15/security/ipe/Kconfig

e155858d - ipe: add support for dm-verity as a trust provider

Sat, 03 Aug 2024 06:08:27 +0000

ipe: add support for dm-verity as a trust providerAllows author of IPE policy to indicate trust for a singular dm-verityvolume, identified by roothash, through "dmverity_roothash" and allsigned and validated dm-verity volumes, through "dmverity_signature".Signed-off-by: Deven Bowers Signed-off-by: Fan Wu [PM: fixed some line length issues in the comments]Signed-off-by: Paul Moore List of files: /linux-6.15/security/ipe/Kconfig

f44554b5 - audit,ipe: add IPE auditing support

Sat, 03 Aug 2024 06:08:23 +0000

audit,ipe: add IPE auditing supportUsers of IPE require a way to identify when and why an operation fails,allowing them to both respond to violations of policy and be notifiedof potentially malicious actions on their systems with respect to IPEitself.This patch introduces 3 new audit events.AUDIT_IPE_ACCESS(1420) indicates the result of an IPE policy evaluationof a resource.AUDIT_IPE_CONFIG_CHANGE(1421) indicates the current active IPE policyhas been changed to another loaded policy.AUDIT_IPE_POLICY_LOAD(1422) indicates a new IPE policy has been loadedinto the kernel.This patch also adds support for success auditing, allowing users toidentify why an allow decision was made for a resource. However, it isrecommended to use this option with caution, as it is quite noisy.Here are some examples of the new audit record types:AUDIT_IPE_ACCESS(1420): audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1 pid=297 comm="sh" path="/root/vol/bin/hello" dev="tmpfs" ino=3897 rule="op=EXECUTE boot_verified=TRUE action=ALLOW" audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1 pid=299 comm="sh" path="/mnt/ipe/bin/hello" dev="dm-0" ino=2 rule="DEFAULT action=DENY" audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1 pid=300 path="/tmp/tmpdp2h1lub/deny/bin/hello" dev="tmpfs" ino=131 rule="DEFAULT action=DENY"The above three records were generated when the active IPE policy onlyallows binaries from the initramfs to run. The three identical `hello`binary were placed at different locations, only the first hello fromthe rootfs(initramfs) was allowed.Field ipe_op followed by the IPE operation name associated with the log.Field ipe_hook followed by the name of the LSM hook that triggered the IPEevent.Field enforcing followed by the enforcement state of IPE. (it will beintroduced in the next commit)Field pid followed by the pid of the process that triggered the IPEevent.Field comm followed by the command line program name of the process thattriggered the IPE event.Field path followed by the file's path name.Field dev followed by the device name as found in /dev where the file isfrom.Note that for device mappers it will use the name `dm-X` instead ofthe name in /dev/mapper.For a file in a temp file system, which is not from a device, it will use`tmpfs` for the field.The implementation of this part is following another existing use caseLSM_AUDIT_DATA_INODE in security/lsm_audit.cField ino followed by the file's inode number.Field rule followed by the IPE rule made the access decision. The wholerule must be audited because the decision is based on the combination ofall property conditions in the rule.Along with the syscall audit event, user can know why a blockedhappened. For example: audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1 pid=2138 comm="bash" path="/mnt/ipe/bin/hello" dev="dm-0" ino=2 rule="DEFAULT action=DENY" audit[1956]: SYSCALL arch=c000003e syscall=59 success=no exit=-13 a0=556790138df0 a1=556790135390 a2=5567901338b0 a3=ab2a41a67f4f1f4e items=1 ppid=147 pid=1956 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" key=(null)The above two records showed bash used execve to run "hello" and gotblocked by IPE. Note that the IPE records are always prior to a SYSCALLrecord.AUDIT_IPE_CONFIG_CHANGE(1421): audit: AUDIT1421 old_active_pol_name="Allow_All" old_active_pol_version=0.0.0 old_policy_digest=sha256:E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649 new_active_pol_name="boot_verified" new_active_pol_version=0.0.0 new_policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F auid=4294967295 ses=4294967295 lsm=ipe res=1The above record showed the current IPE active policy switch from`Allow_All` to `boot_verified` along with the version and the hashdigest of the two policies. Note IPE can only have one policy activeat a time, all access decision evaluation is based on the current activepolicy.The normal procedure to deploy a policy is loading the policy to deployinto the kernel first, then switch the active policy to it.AUDIT_IPE_POLICY_LOAD(1422): audit: AUDIT1422 policy_name="boot_verified" policy_version=0.0.0 policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F2676 auid=4294967295 ses=4294967295 lsm=ipe res=1The above record showed a new policy has been loaded into the kernelwith the policy name, policy version and policy hash.Signed-off-by: Deven Bowers Signed-off-by: Fan Wu [PM: subject line tweak]Signed-off-by: Paul Moore List of files: /linux-6.15/security/ipe/Kconfig

03115077 - lsm: add IPE lsm

Sat, 03 Aug 2024 06:08:15 +0000

lsm: add IPE lsmIntegrity Policy Enforcement (IPE) is an LSM that provides ancomplimentary approach to Mandatory Access Control than existing LSMstoday.Existing LSMs have centered around the concept of access to a resourceshould be controlled by the current user's credentials. IPE's approach,is that access to a resource should be controlled by the system's trustof a current resource.The basis of this approach is defining a global policy to specify whichresource can be trusted.Signed-off-by: Deven Bowers Signed-off-by: Fan Wu [PM: subject line tweak]Signed-off-by: Paul Moore List of files: /linux-6.15/security/ipe/Kconfig