Changes in Makefile

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/Makefile

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/Makefile

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/Makefile

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/Makefile

2261306f - ipe: add userspace interface

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

ipe: add userspace interfaceAs is typical with LSMs, IPE uses securityfs as its interface withuserspace. for a complete list of the interfaces and the respectiveinputs/outputs, please see the documentation underadmin-guide/LSM/ipe.rstSigned-off-by: Deven Bowers Signed-off-by: Fan Wu Signed-off-by: Paul Moore List of files: /linux-6.15/security/ipe/Makefile

52443cb6 - ipe: add LSM hooks on execution and kernel read

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

ipe: add LSM hooks on execution and kernel readIPE's initial goal is to control both execution and the loading ofkernel modules based on the system's definition of trust. Itaccomplishes this by plugging into the security hooks forbprm_check_security, file_mprotect, mmap_file, kernel_load_data,and kernel_read_data.Signed-off-by: Deven Bowers Signed-off-by: Fan Wu Signed-off-by: Paul Moore List of files: /linux-6.15/security/ipe/Makefile

05a35163 - ipe: add evaluation loop

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

ipe: add evaluation loopIntroduce a core evaluation function in IPE that will be triggered byvarious security hooks (e.g., mmap, bprm_check, kexec). This functionsystematically assesses actions against the defined IPE policy, byiterating over rules specific to the action being taken. This criticaladdition enables IPE to enforce its security policies effectively,ensuring that actions intercepted by these hooks are scrutinized for policycompliance before they are allowed to proceed.Signed-off-by: Deven Bowers Signed-off-by: Fan Wu Reviewed-by: Serge Hallyn Signed-off-by: Paul Moore List of files: /linux-6.15/security/ipe/Makefile

54a88cd2 - ipe: add policy parser

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

ipe: add policy parserIPE's interpretation of the what the user trusts is accomplished throughits policy. IPE's design is to not provide support for a single trustprovider, but to support multiple providers to enable the end-user tochoose the best one to seek their needs.This requires the policy to be rather flexible and modular so thatintegrity providers, like fs-verity, dm-verity, or some other system,can plug into the policy with minimal code changes.Signed-off-by: Deven Bowers Signed-off-by: Fan Wu [PM: added NULL check in parse_rule() as discussed]Signed-off-by: Paul Moore List of files: /linux-6.15/security/ipe/Makefile

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/Makefile