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
