On 11/17/2017 2:42 PM, Mimi Zohar wrote:
On Fri, 2017-11-17 at 13:20 +0100, Roberto Sassu wrote:
On 11/16/2017 2:06 PM, Mimi Zohar wrote:
On Thu, 2017-11-16 at 10:23 +0100, Roberto Sassu wrote:
On 11/16/2017 3:13 AM, Mimi Zohar wrote:
On Wed, 2017-11-15 at 16:05 -0800, Matthew Garrett wrote:
On Wed, Nov 15, 2017 at 4:02 PM, James Morris <james.l.morris@xxxxxxxxxx> wrote:
On Wed, 15 Nov 2017, Patrick Ohly wrote:
I have some experience with SMACK, but not with Apparmor. At least with
SMACK the problem is that the LSM depends on integrity protection of
the xattrs, but the integrity protection itself depends on the LSM, so
there's a cycle. An attacker can much too easily make offline changes
which then defeat whatever IMA policy the system might be using.
Isn't this what EVM is supposed to mitigate?
With the default appraisal policy, it can't. IMA determines if a file
must be appraised depending on metadata whose integrity has not been
verified yet. A root process is able to load appraised files with
i_uid = 0 and files with missing/invalid HMAC and i_uid != 0, at the
same time.
The LSMs are responsible for protecting their own labels. Theyhave
the opportunity to verify and deny access to files based on LSM
labels, BEFORE IMA-appraisal is called to verify the file's integrity.
Adding in CC the linux-security-module mailing list.
We need to first clarify, for those reading this thread, that are not
fully aware of the context of this discussion, that the discussion is
not relevant to the "lockdown" patch set.
Kernel modules, the kexec image, IMA policy and firmware call the pre
and post LSM kernel_read_file hooks. For these LSM hooks, IMA policy
rules are not written in terms of LSM labels or any other file
metadata. File signatures will always be appraised.
LSMs are responsible to enforce a security policy at run-time, while
IMA/EVM protect data and metadata against offline attacks. However, if
IMA/EVM protect only part of the system, the security policy might not
be enforced as expected. I give an example.
Suppose that a security policy preserves the integrity of a database by
allowing only one application to modify it. Suppose also, that the
security policy allows that application to modify files which are not
appraised by IMA. Only the database is appraised.
This use case scenario is really strange. The IMA policy should be
verifying the integrity of the application that is allowed to modify
the database, not the database.
Also the integrity of the database should be verified if you want to
detect offline attacks.
From my limited knowledge of databases, databases tend to manage data
caching themselves at the application level (eg. Direct IO), and avoid
file buffer caching. Having IMA calculate the file hash, would negate
the performance benefits of doing their own data caching.
Maybe I didn't choose a good example. I wanted to show an application
allowed by LSM to access valuable information (appraised) and
non-valuable information (not appraised), and the consequence of not
verifying the association between data and metadata (label) before LSM
makes a security decision.
Then, the integrity of the database cannot be guaranteed anymore. When
the system is offline, the database label is swapped with one that is
not included in the IMA policy. When the system is online again, LSMs
would allow the application to access the database, but its integrity
is no longer verified. From the users perspective, the application is
working correctly, while unauthorized modifications could have be done
on the database.
In my opinion, protecting the integrity of a TCB against offline and
online attacks with LSMs and IMA/EVM, can be achieved in two ways:
I really doubt that anyone's definition of TCB would include
databases.
I think it should be, if the goal is to protect the integrity of the
database.
Roberto
- all objects accessed by LSM TCB subjects are a subset of IMA TCB
objects, and LSM prevents accesses to LSM TCB objects by processes
outside LSM TCB
- all objects accessed by IMA TCB subjects are protected by IMA, IMA
prevents accesses to IMA TCB objects by processes outside IMA TCB, and
LSM TCB subjects are a subset of IMA TCB subjects
As you can see, in both cases there is a dependency between the LSM
policy and the IMA policy. In the first case, the dependency is on
objects and LSM is enforcing integrity. In the second case, the
dependency is on subjects, IMA is enforcing integrity and LSM could
enforce a more strict integrity policy or a policy with different goals.
I prefer the second option because:
1) it easier to write a policy in term of subjects rather than objects
2) LSM does not necessarily enforce an integrity policy; LSM could
enforce a policy for isolation and containment, while IMA could
enforce an integrity policy
3) an integrity policy can be enforced without LSM, and both LSM and IMA
can enforce their own integrity policy
4) the effort necessary to enforce an integrity policy with IMA is very
low: if files with valid signature/HMAC are in the IMA TCB and the
IMA policy identifies TCB subjects, the required modification would
be to simply deny access to appraised files if the subject does not
match policy criteria
The first version of the patch set which adds support for the
enforcement of the Biba strict policy can be found at the URL:
https://www.spinics.net/lists/linux-integrity/msg00392.html
I'd be interested in hearing what other people think.
Mimi
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
