IMA appraisal master plan?

IMA appraisal master plan?

[Roberto Sassu]

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@oracle.com> 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.

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.

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:

- 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

Roberto


> Look at security/security.c and see that IMA is called AFTER the
> LSMs.??The same is true for the other IMA hooks, that are not co-
> located with LSM hooks.??For example, the security_file_open hook is
> called before the ima_file_check() hook.
> 
> Mimi
> 

-- 
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[Mimi Zohar]

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@oracle.com> 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.

>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.

> 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.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[Roberto Sassu]

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@oracle.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[Stephen Smalley]

On Fri, 2017-11-17 at 08:42 -0500, 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.morr
> > > > > > is at oracle.com> 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.
> 
> > 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.
> 
> > 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.
> 
> > 
> > - 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.

My $0.02, take or leave it as you wish:

First, Biba integrity models don't work well in the real world; that
was one of the motivations for the introduction of Type Enforcement
(c.f. Boebert and Kain 1985, Ross Anderson's Security Engineering, and
many other works in the literature). SELinux TE can be used to enforce
integrity access control goals, and is successfully enforcing such
goals in Android (and to some degree in Fedora/RHEL, modulo the
presence of unconfined domains in the default policy and the
complexities associated with the large and dynamic GNU/Linux TCB). Even
Windows Mandatory Integrity Controls, which are based on Biba, disable
half the Biba model by default to avoid breaking normal system
operation, and are only used in a very constrained manner due to the
limitations of the model.

Second, if you want to protect against offline attacks, use dm-verity
or dm-crypt with an integrity-preserving algorithm.  Trying to keep
extending IMA/EVM to provide a complete solution in this space is a
losing proposition IMHO; you will only end up with something that is
either unusable or insecure - take your pick.  Use IMA for what it was
originally designed to do, i.e. userspace measurement and remote
attestation. 

Third, the integrity framework/modules shouldn't be defining or
enforcing an access control policy; leave that to the security
framework/modules, please.  Some might argue that they started doing
that the day they introduced IMA-appraisal (which itself is an
interesting topic; there is a reason why "remote" is in "remote
attestation", but we'll leave that to another day) but I think it would
be a mistake to extend it to a conventional access control policy like
Biba.  If you truly want a Biba integrity policy, then do it in a small
LSM and use that to motivate extreme stacking.  But think hard whether
Biba is truly the right answer (and if so, what was question that
motivated it), given that it really doesn't work in practice.

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[James Morris]

On Fri, 17 Nov 2017, Roberto Sassu wrote:

> LSMs are responsible to enforce a security policy at run-time, while
> IMA/EVM protect data and metadata against offline attacks.

In my view, IMA can also protect against making an online attack 
persistent across boots, and that would be the most compelling use of it 
for many general purpose applications.



-- 
James Morris
<james.l.morris@oracle.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[Patrick Ohly]

On Mon, 2017-11-20 at 07:47 +1100, James Morris wrote:
> On Fri, 17 Nov 2017, Roberto Sassu wrote:
> 
> > LSMs are responsible to enforce a security policy at run-time,
> > while IMA/EVM protect data and metadata against offline attacks.
> 
> In my view, IMA can also protect against making an online attack?
> persistent across boots, and that would be the most compelling use of
> it?for many general purpose applications.

I do not quite buy that interpretation. If the online attack succeeds
in bypassing the run-time checks, for example with a full root exploit,
then he has pretty much the same capabilities to make persistent file
changes as during an offline attack.

When allowing local hashing, it's actually worse: during an offline
attack, the attacker might not have access to the TPM and thus cannot
easily update the EVM HMAC. During an online attack, the kernel will
happily update that and the IMA hash for the attacker, resulting in a
file that passes appraisal after a reboot.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[Mimi Zohar]

On Mon, 2017-11-20 at 11:20 +0100, Patrick Ohly wrote:
> On Mon, 2017-11-20 at 07:47 +1100, James Morris wrote:
> > On Fri, 17 Nov 2017, Roberto Sassu wrote:
> > 
> > > LSMs are responsible to enforce a security policy at run-time,
> > > while IMA/EVM protect data and metadata against offline attacks.
> > 
> > In my view, IMA can also protect against making an online attack?
> > persistent across boots, and that would be the most compelling use of
> > it?for many general purpose applications.
> 
> I do not quite buy that interpretation. If the online attack succeeds
> in bypassing the run-time checks, for example with a full root exploit,
> then he has pretty much the same capabilities to make persistent file
> changes as during an offline attack.

In the face of a full root exploit, there is not much that one can do,
"other" than to detect it. ?This is why remote attestation is so
important.

> When allowing local hashing, it's actually worse: during an offline
> attack, the attacker might not have access to the TPM and thus cannot
> easily update the EVM HMAC. During an online attack, the kernel will
> happily update that and the IMA hash for the attacker, resulting in a
> file that passes appraisal after a reboot.

The assumption is that most files in the TCB are not changing and are
signed. ?Custom policies should require file signatures for these
files.

Assuming that the private keys that are used to sign these files, as
well as the private key used for signing other keys added to the IMA
keyring, are stored off line, new files can not be signed.

The number of mutable files in the TCB should be very limited,
probably < 20 files. ?Their usage can be constrained by MAC.

That said, IMA/IMA-appraisal is work in progress. ?There are still
measurement/appraisal gaps that need to be closed. ?One such example
are files read by interpreters and interpreted files. ?There have been
some initial proposals in this area.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info@ http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[Patrick Ohly]

On Mon, 2017-11-20 at 09:59 -0500, Mimi Zohar wrote:
> > When allowing local hashing, it's actually worse: during an offline
> > attack, the attacker might not have access to the TPM and thus
> > cannot
> > easily update the EVM HMAC. During an online attack, the kernel
> > will
> > happily update that and the IMA hash for the attacker, resulting in
> > a
> > file that passes appraisal after a reboot.
> 
> The assumption is that most files in the TCB are not changing and are
> signed. ?Custom policies should require file signatures for these
> files.
> 
> Assuming that the private keys that are used to sign these files, as
> well as the private key used for signing other keys added to the IMA
> keyring, are stored off line, new files can not be signed.
> 
> The number of mutable files in the TCB should be very limited,
> probably < 20 files. ?Their usage can be constrained by MAC.

I'm not sure what exactly "constrained by MAC" implies, but I suspect
that these mutable files will be as important for the integrity of the
TCB as everything else (<insert my systemd configuration file example
again here>). Compromised is compromised, an installation cannot be
"half compromised". So once the policy allows mutable files, a run-time 
exploit that bypasses the MAC can compromise the TCB permanently.

> That said, IMA/IMA-appraisal is work in progress. ?There are still
> measurement/appraisal gaps that need to be closed. ?One such example
> are files read by interpreters and interpreted files. ?There have
> been some initial proposals in this area.

That's what brings us back to my initial question: are the current set
of patches enough to make appraisal useful? Matthew seems to be
optimistic that the answer is yes and I certainly don't want to
discourage him especially as he's doing some actual work while I
couldn't do that, but I remain a bit more skeptical.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[James Morris]

On Mon, 20 Nov 2017, Mimi Zohar wrote:

> On Mon, 2017-11-20 at 11:20 +0100, Patrick Ohly wrote:
> > On Mon, 2017-11-20 at 07:47 +1100, James Morris wrote:
> > > On Fri, 17 Nov 2017, Roberto Sassu wrote:
> > > 
> > > > LSMs are responsible to enforce a security policy at run-time,
> > > > while IMA/EVM protect data and metadata against offline attacks.
> > > 
> > > In my view, IMA can also protect against making an online attack?
> > > persistent across boots, and that would be the most compelling use of
> > > it?for many general purpose applications.
> > 
> > I do not quite buy that interpretation. If the online attack succeeds
> > in bypassing the run-time checks, for example with a full root exploit,
> > then he has pretty much the same capabilities to make persistent file
> > changes as during an offline attack.
> 
> In the face of a full root exploit, there is not much that one can do,
> "other" than to detect it. ?This is why remote attestation is so
> important.

Right, although the consensus seems to be that RA is essential rather than 
simply important.


-- 
James Morris
<james.l.morris@oracle.com>

IMA appraisal master plan?

[Roberto Sassu]

On 11/20/2017 11:20 AM, Patrick Ohly wrote:
> On Mon, 2017-11-20 at 07:47 +1100, James Morris wrote:
>> On Fri, 17 Nov 2017, Roberto Sassu wrote:
>>
>>> LSMs are responsible to enforce a security policy at run-time,
>>> while IMA/EVM protect data and metadata against offline attacks.
>>
>> In my view, IMA can also protect against making an online attack
>> persistent across boots, and that would be the most compelling use of
>> it?for many general purpose applications.

It would be possible, if IMA knows when the system is in the expected
state. For example, if the system is in the expected state after digest
lists have been loaded, IMA could erase the EVM key, sealed to that
state, when a file with unknown digest is measured. The system won't be
able to produce valid HMACs, and files modified after the attack can be
identified at the next boot, due to the invalid HMAC. Also accessing
files with invalid HMAC will cause the EVM key to be zeroed.

Since IMA would erase the EVM key when a new measurement entry is
created, digests of mutable files with valid HMAC should not be added to
the measurement list (the initial digest must be provided with a digest
list, or files must be signed). This requires that the integrity of
mutable files is guaranteed by LSMs or by IMA, with the patch set 'ima:
preserve integrity of dynamic data'.


> I do not quite buy that interpretation. If the online attack succeeds
> in bypassing the run-time checks, for example with a full root exploit,
> then he has pretty much the same capabilities to make persistent file
> changes as during an offline attack.

If the full root exploit modifies the current system state, persistent
changes can be detected, as I explained above. The effectiveness of the
solution depends on which checks are done by the system. For example, in
addition to checking if the digest of measured files is in a digest
list, IMA could check that a specific application is running (e.g.
antivirus) and that the firewall has been started before network
services. More checks increase the likelihood that the full root exploit
causes a system state change.

Roberto


> When allowing local hashing, it's actually worse: during an offline
> attack, the attacker might not have access to the TPM and thus cannot
> easily update the EVM HMAC. During an online attack, the kernel will
> happily update that and the IMA hash for the attacker, resulting in a
> file that passes appraisal after a reboot.
> 

-- 
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[Mimi Zohar]

On Tue, 2017-11-21 at 10:33 +0100, Roberto Sassu wrote:
> On 11/20/2017 11:20 AM, Patrick Ohly wrote:
> > On Mon, 2017-11-20 at 07:47 +1100, James Morris wrote:
> >> On Fri, 17 Nov 2017, Roberto Sassu wrote:
> >>
> >>> LSMs are responsible to enforce a security policy at run-time,
> >>> while IMA/EVM protect data and metadata against offline attacks.
> >>
> >> In my view, IMA can also protect against making an online attack
> >> persistent across boots, and that would be the most compelling use of
> >> it?for many general purpose applications.
> 
> It would be possible, if IMA knows when the system is in the expected
> state. For example, if the system is in the expected state after digest
> lists have been loaded, IMA could erase the EVM key, sealed to that
> state, when a file with unknown digest is measured. The system won't be
> able to produce valid HMACs, and files modified after the attack can be
> identified at the next boot, due to the invalid HMAC. Also accessing
> files with invalid HMAC will cause the EVM key to be zeroed.

Roberto, allowing the system to boot with an EVM HMAC key, but then
transition to a point when it can't be used, is a good idea. ?The
transitioning, however, shouldn't be tied to white lists. ?Please keep
these concepts independent of each other.

Preventing a device from booting is major. ?Is there a less drastic
solution that would allow detection, without resealing the EVM HMAC
key so it can't be used?

Years ago Dave and I had a prototype of "locking" mutable files, after
a certain point in the boot process, working. ?It allowed the ~20
mutable files to be created/updated, as necessary. ?The limitation was
that any package updates or new packages installations needed to be
done during this window, before the transition, as well.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[Roberto Sassu]

On 11/21/2017 3:05 PM, Mimi Zohar wrote:
> On Tue, 2017-11-21 at 10:33 +0100, Roberto Sassu wrote:
>> On 11/20/2017 11:20 AM, Patrick Ohly wrote:
>>> On Mon, 2017-11-20 at 07:47 +1100, James Morris wrote:
>>>> On Fri, 17 Nov 2017, Roberto Sassu wrote:
>>>>
>>>>> LSMs are responsible to enforce a security policy at run-time,
>>>>> while IMA/EVM protect data and metadata against offline attacks.
>>>>
>>>> In my view, IMA can also protect against making an online attack
>>>> persistent across boots, and that would be the most compelling use of
>>>> it?for many general purpose applications.
>>
>> It would be possible, if IMA knows when the system is in the expected
>> state. For example, if the system is in the expected state after digest
>> lists have been loaded, IMA could erase the EVM key, sealed to that
>> state, when a file with unknown digest is measured. The system won't be
>> able to produce valid HMACs, and files modified after the attack can be
>> identified at the next boot, due to the invalid HMAC. Also accessing
>> files with invalid HMAC will cause the EVM key to be zeroed.
> 
> Roberto, allowing the system to boot with an EVM HMAC key, but then
> transition to a point when it can't be used, is a good idea. ?The
> transitioning, however, shouldn't be tied to white lists. ?Please keep
> these concepts independent of each other.

A predictable system state can be achieved also with file signatures.
The system works as expected when it uses the provided public key to
verify signatures and grants access to signed files. But also in this
case, IMA should know if mutable files are good or not. With the
enforcement of an integrity policy on appraised files, a mutable file is
good if it has a valid HMAC.

An important remark is that having a predictable state does not prevent
reporting all measurements protected with another PCR. The predictable
state is necessary to determine when the EVM key can be used to
calculate HMACs. Also, the EVM key should be securely generated (e.g. by
setting the sensitiveDataOrigin bit with TPM 2.0) and available only
when the sealing policy is verified.


> Preventing a device from booting is major. ?Is there a less drastic
> solution that would allow detection, without resealing the EVM HMAC
> key so it can't be used?

With the enforcement of the Biba strict policy, the EVM key will not be
erased, because IMA prevents corruption of mutable files. I suggest to
not measure files if access will be denied by appraisal.

In the next version of the patch set 'ima: preserve integrity of dynamic
data', I will introduce the policy low watermark for objects. Instead of
denying writing of mutable files by processes outside the TCB, IMA will
allow the operation and demote those files (remove the HMAC).

If appraisal is in enforcing mode, access to demoted files will be
denied. Otherwise, they will be measured (patch 2/2 of the patch set
excludes from measurement only files with appraisal status
INTEGRITY_PASS). The EVM key will be erased before a TCB process reads a
demoted file. At the next boot, the EVM key can be used if demoted files
are not accessed by TCB processes.


> Years ago Dave and I had a prototype of "locking" mutable files, after
> a certain point in the boot process, working. ?It allowed the ~20
> mutable files to be created/updated, as necessary. ?The limitation was
> that any package updates or new packages installations needed to be
> done during this window, before the transition, as well.

If the TCB contains only processes that don't corrupt mutable files and
those files are protected with the enforcement of an integrity policy,
locking them wouldn't be necessary.

Roberto

-- 
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IMA appraisal master plan?

[Mimi Zohar]

On Tue, 2017-11-21 at 16:25 +0100, Roberto Sassu wrote:

> In the next version of the patch set 'ima: preserve integrity of dynamic
> data', I will introduce the policy low watermark for objects. Instead of
> denying writing of mutable files by processes outside the TCB, IMA will
> allow the operation and demote those files (remove the HMAC).

There has been no consensus for the existing patch set you've posted.
In fact, everyone who has responded said to make it a separate LSM.
Extending the patch set makes no sense.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html