Messages in this thread | | | Subject | Re: [PATCH v6 8/8] selinux: measure state and hash of the policy using IMA | From | Tushar Sugandhi <> | Date | Mon, 23 Nov 2020 11:37:47 -0800 |
| |
Hi James,
On 2020-11-20 6:05 p.m., James Morris wrote: > On Thu, 19 Nov 2020, Tushar Sugandhi wrote: > >> an impact on the security guarantees provided by SELinux. Measuring >> such in-memory data structures through IMA subsystem provides a secure >> way for a remote attestation service to know the state of the system >> and also the runtime changes in the state of the system. > > I think we need better clarity on the security model here than just "a > secure way...". Secure how and against what threats? > Thanks for taking a look at this patch series.
Here is the overall threat model:
For a given device inside an organization, various services/ infrastructure tools owned by the org interact with the device. These services/tools can be external to the device. They can interact with the device both during setup and rest of the device lifetime. These interactions may involve sharing the org sensitive data and/or running business critical workload on that device. Before sharing data/running workload on that device - the org would want to know the security profile of the device. E.g. SELinux is enforced (with the policy that is expected by the org), disks are encrypted with a certain configuration, secure boot is enabled etc. If the org requirements are satisfied, then only the external services will start interacting with the device.
For the org, extracting that information from the device is tricky. The services could look for some markers on the device necessary to satisfy the org requirements. But the device could already be compromised with some malware, and could simply lie to the external services by putting false markers on the device. For instance, the malware can put a random SELinux policy file at the expected location even when SELinux is not even enabled on the device.
If the org trusts these false markers, the compromised device could go undetected - and can do further damage once it has access to the org sensitive data / business critical processes.
This is the threat we are trying to address.
For the org, to address this threat - at least three things are needed:
(1) Producers of the markers are as close to the source as possible: The source that does the work of actually protecting the device. E.g. SELinux state reported from the SELinux kernel LVM itself, rather than some user mode process extracting that information). This will make it harder for the bad actors to mimic the information - thus reducing the ROI for them.
(2) Extracting the information from the device in a tamper resistant way: Even if the information is produced by the expected source, it can still get altered by attackers. This can happen before the info reaches the external services - the services that make the decision whether to trust the device with org sensitive info or not. The IMA measurement infrastructure, with TPM extend and quoting, provides the necessary assurance to those services - that the information coming from the device is not tampered with.
(3) Tracking the state change during the lifetime of the device: The device may start in a good configuration. But over the lifetime, that configuration may deteriorate. E.g. SELinux stores the current operating mode, in memory, which could be "enforce" or "audit". Changes to this data at runtime impacts the security guarantees provided by SELinux. Such changes could be made inadvertently or by malware running on the device.
The IMA hook plus policies in the first 7/8 patches provide the necessary functionality to achieve (2).
The last SELinux 8/8 patch helps achieve (1).
And the patches in the series overall work together to achieve (3).
> This looks to me like configuration assurance, i.e. you just want to know > that systems have been configured correctly, not to detect a competent > attack. Is that correct?
The attestation service would look at various measurements coming from the device. And there could be a discrepancy between the measurements, or the measurements won't match the expected predetermined values. In that case, the attestation service may conclude that not only the device is misconfigured, but also that misconfiguration is a result of potentially compromised device. Then the necessary action can be taken for the device (removing it from the network, not sharing data/workload with it etc.)
~Tushar
| |