Re: [PATCH v2 00/15] ima: digest list feature

[Mimi Zohar]

On Fri, 2017-11-17 at 09:55 +0100, Roberto Sassu wrote:
> On 11/17/2017 2:08 AM, Kees Cook wrote:
> > On Tue, Nov 7, 2017 at 8:45 AM, Roberto Sassu  
> > wrote:
> >> On 11/7/2017 2:37 PM, Mimi Zohar wrote:
> >>> Normally, the protection of kernel memory is out of scope for IMA.
> >>> This patch set introduces an in kernel white list, which would be a
> >>> prime target for attackers looking for ways of by-passing IMA-
> >>> measurement, IMA-appraisal and IMA-audit.  Others might disagree, but
> >>> from my perspective, this risk is too high.
> > 
> > BTW, which part of the series does the whitelist? I'd agree generally,
> > though: we don't want to make things writable if they're normally
> > read-only.

The white list is a proposed new feature.

> Patch 5/15 introduces the hash table ima_digests_htable and the
> functions to add/search file digests
> 
> Patches 6-7-8/15 add file digests to ima_digests_htable
> 
> Patch 10/15 searches file digests in ima_digests_htable
> 
> 
> Original files containing digest lists are discarded after being parsed.
> 
> 
> >> It would be much easier for an attacker to just set ima_policy_flag to
> >> zero.
> > 
> > That's a fair point. I wonder if ima_policy_flag could be marked
> > __ro_after_init? Most of the writes are from __init sections, but I
> > haven't looked closely at when ima_update_policy() gets called.
> 
> Unfortunately not. New policies can be loaded by writing to a file in
> the securityfs filesystem. They could enable different actions
> (measurement/appraisal/audit).

The ima_policy_flag is an optimization indicating which actions -
MEASURE, APPRAISE, AUDIT - the policy contains.  The IMA policy,
itself, can be replaced with a signed custom policy just once.  This
is normally done in the initramfs, after the LSM policies have been
loaded, in order to define policy rules in terms of LSM labels.  Once
the new policy is loaded, the ima_policy_flag is set.

A Kconfig option allows additional signed rules to be added to the IMA
policy.  After adding these new rules, additional actions can be added
to the policy flag, but not cleared.

The system admin/owner knows, prior to loading the custom policy,
which actions will be defined.  Instead of waiting for the policy to
be written, the ima_policy_flag could be set at init.  (We could
extend the existing "ima_policy=" boot command line option.)  If not
the ima_policy_flag, itself, then a shadow of the ima_policy_flag,
which is OR'ed with the ima_policy_flag.

Mimi

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

Re: [PATCH v2 00/15] ima: digest list feature

[Kees Cook]

On Tue, Nov 7, 2017 at 8:45 AM, Roberto Sassu  wrote:
> On 11/7/2017 2:37 PM, Mimi Zohar wrote:
>> Normally, the protection of kernel memory is out of scope for IMA.
>> This patch set introduces an in kernel white list, which would be a
>> prime target for attackers looking for ways of by-passing IMA-
>> measurement, IMA-appraisal and IMA-audit.  Others might disagree, but
>> from my perspective, this risk is too high.

BTW, which part of the series does the whitelist? I'd agree generally,
though: we don't want to make things writable if they're normally
read-only.

> It would be much easier for an attacker to just set ima_policy_flag to
> zero.

That's a fair point. I wonder if ima_policy_flag could be marked
__ro_after_init? Most of the writes are from __init sections, but I
haven't looked closely at when ima_update_policy() gets called.

-Kees

-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/15] ima: digest list feature

[Roberto Sassu]

On 11/9/2017 5:46 PM, Matthew Garrett wrote:

On Thu, Nov 9, 2017 at 11:13 AM, Roberto Sassu  wrote:

On 11/9/2017 3:47 PM, Matthew Garrett wrote:

There's no need to have a policy that measures those files, because
they're part of the already-measured initramfs. Just set the IMA
policy after you've loaded the digest list.



The default IMA policy measures files accessed from the initial ram
disk. It is easier to verify individual files, rather than the whole
image.


That's a matter of implementation. You're not forced to use the default policy.


This seems very over-complicated, and it's unclear why the kernel
needs to open the file itself. You *know* that all of userland is



You can have a look at ima_fs.c. If appraisal is in enforcing mode,
direct upload of a policy is not permitted. The kernel reads the policy,
calculates the digest, and verifies the signature.


Is there an expectation that you'll load additional digest lists at runtime?


Yes, before new packages are installed.



trustworthy at this point even in the absence of signatures. It seem >
reasonable to provide a interface that allows userland to pass a
digest list to the kernel, in the same way that userland can pass an
IMA policy to the kernel. You can then restrict access to that
interface via an LSM.



Then digest lists cannot be used alone, without an LSM. Also, verifiers
have to check the LSM policy to ensure that only the parser was able to
upload the digest lists.


Only if you want to add additional digest lists at runtime, but yes,
you really want to be verifying the LSM policy in any case.


If the trustworthiness of the initial ram disk can be guaranteed with
low effort, for example if the image is distributed by the vendor, it
would be easier to guarantee that digest lists were uploaded by the
parser.

But, likely, the initial ram disk is generated by the local system.
Relying on the assumption that the vendor distributes the initial ram
disk would limit, in my opinion, the applicability of the digest list
feature. Relying on the enforcement by an LSM would make the integrity
evaluation much more complex.

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-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/15] ima: digest list feature

[Mimi Zohar]

On Thu, 2017-11-09 at 09:47 -0500, Matthew Garrett wrote:

> This seems very over-complicated, and it's unclear why the kernel
> needs to open the file itself. You *know* that all of userland is
> trustworthy at this point even in the absence of signatures.

Assuming the initramfs is signed, then yes the rootfs files would be
trusted.  rootfs can still access files from real root, which is where
policies are normally stored.

> It seems
> reasonable to provide a interface that allows userland to pass a
> digest list to the kernel, in the same way that userland can pass an
> IMA policy to the kernel. You can then restrict access to that
> interface via an LSM.

IMA can and should be configured to require signed policies.

Mimi

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

Re: [PATCH v2 00/15] ima: digest list feature

[Roberto Sassu]

On 11/9/2017 3:47 PM, Matthew Garrett wrote:

On Thu, Nov 9, 2017 at 4:51 AM, Roberto Sassu  wrote:

On 11/8/2017 4:48 PM, Matthew Garrett wrote:

The code doing the parsing is in the initramfs, which has already been
measured at boot time. You can guarantee that it's being done by
trusted code.



The parser can be executed in the initial ram disk, but everything
accessed before the parser is executed will be measured/appraised
without digest lists. To do signature-based remote attestation, where
the verification consists on checking the signature of digests of
measured files, it would be necessary to sign systemd, libraries,
everything accessed before the parser, and the parser. If RPM headers
are parsed by the kernel, measurement/appraisal will be done directly
with digest lists.


There's no need to have a policy that measures those files, because
they're part of the already-measured initramfs. Just set the IMA
policy after you've loaded the digest list.


The default IMA policy measures files accessed from the initial ram
disk. It is easier to verify individual files, rather than the whole
image.



The main problem is that the digest list measurement, performed when the
parser accesses the file containing the RPM header, might not reflect
what IMA uses for digest lookup.



Why not?



I assumed you wanted to measure digest lists only at the time they are
read by the parser, and not when they are read by IMA. If instead digest
lists are verified again after conversion, the new workflow should be:

1) the kernel parses digest list metadata before systemd is executed
2) the kernel verifies the signature of digest lists (RPM headers) and
add the digest of digest lists to the hash table, so that appraisal
succeeds
3) systemd (with file signature) is executed
4) the parser (with file signature) is executed
5) the parser reads and converts the digest lists to the generic format,
and writes them to a tmpfs filesystem
6) the parser generates a new digest list metadata file with the path of
converted digest lists and sends the path of the new metadata to IMA
7) IMA reads the generic digest lists

The measurement list should look like:

10  ima-sig  boot_aggregate
10  ima-sig  /etc/ima/digest_lists/metadata
10  ima-sig  /usr/lib/systemd/systemd 
...
10  ima-sig   
10  ima-sig  /tmp/metadata


If parsing of RPM headers is done by the kernel, the measurement list
will look like:

10  ima-ng  boot_aggregate
10  ima-ng  /etc/ima/digest_lists/metadata


A built-in policy should enable appraisal of tmpfs. If not, patch 11/15
disables digest lookup for appraisal. Since generic digest lists will
have a security.ima extended attribute (they are mutable files),
appraisal verification will succeed.

With this solution, digital signatures cannot be required, because
generic digest lists will have a HMAC. For appraisal, it becomes
necessary to ensure that only digest lists written by the parser can be
processed by IMA.


This seems very over-complicated, and it's unclear why the kernel
needs to open the file itself. You *know* that all of userland is


You can have a look at ima_fs.c. If appraisal is in enforcing mode,
direct upload of a policy is not permitted. The kernel reads the policy,
calculates the digest, and verifies the signature.



trustworthy at this point even in the absence of signatures. It seem > 
reasonable to provide a interface that allows userland to pass a
digest list to the kernel, in the same way that userland can pass an
IMA policy to the kernel. You can then restrict access to that
interface via an LSM.


Then digest lists cannot be used alone, without an LSM. Also, verifiers
have to check the LSM policy to ensure that only the parser was able to
upload the digest lists.

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-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/15] ima: digest list feature

[Matthew Garrett]

On Thu, Nov 9, 2017 at 4:51 AM, Roberto Sassu  wrote:
> On 11/8/2017 4:48 PM, Matthew Garrett wrote:
>> The code doing the parsing is in the initramfs, which has already been
>> measured at boot time. You can guarantee that it's being done by
>> trusted code.
>
>
> The parser can be executed in the initial ram disk, but everything
> accessed before the parser is executed will be measured/appraised
> without digest lists. To do signature-based remote attestation, where
> the verification consists on checking the signature of digests of
> measured files, it would be necessary to sign systemd, libraries,
> everything accessed before the parser, and the parser. If RPM headers
> are parsed by the kernel, measurement/appraisal will be done directly
> with digest lists.

There's no need to have a policy that measures those files, because
they're part of the already-measured initramfs. Just set the IMA
policy after you've loaded the digest list.

>>> The main problem is that the digest list measurement, performed when the
>>> parser accesses the file containing the RPM header, might not reflect
>>> what IMA uses for digest lookup.
>>
>>
>> Why not?
>
>
> I assumed you wanted to measure digest lists only at the time they are
> read by the parser, and not when they are read by IMA. If instead digest
> lists are verified again after conversion, the new workflow should be:
>
> 1) the kernel parses digest list metadata before systemd is executed
> 2) the kernel verifies the signature of digest lists (RPM headers) and
>add the digest of digest lists to the hash table, so that appraisal
>succeeds
> 3) systemd (with file signature) is executed
> 4) the parser (with file signature) is executed
> 5) the parser reads and converts the digest lists to the generic format,
>and writes them to a tmpfs filesystem
> 6) the parser generates a new digest list metadata file with the path of
>converted digest lists and sends the path of the new metadata to IMA
> 7) IMA reads the generic digest lists
>
> The measurement list should look like:
>
> 10  ima-sig  boot_aggregate
> 10  ima-sig  /etc/ima/digest_lists/metadata
> 10  ima-sig  /usr/lib/systemd/systemd 
> ...
> 10  ima-sig   
> 10  ima-sig  /tmp/metadata
>
>
> If parsing of RPM headers is done by the kernel, the measurement list
> will look like:
>
> 10  ima-ng  boot_aggregate
> 10  ima-ng  /etc/ima/digest_lists/metadata
>
>
> A built-in policy should enable appraisal of tmpfs. If not, patch 11/15
> disables digest lookup for appraisal. Since generic digest lists will
> have a security.ima extended attribute (they are mutable files),
> appraisal verification will succeed.
>
> With this solution, digital signatures cannot be required, because
> generic digest lists will have a HMAC. For appraisal, it becomes
> necessary to ensure that only digest lists written by the parser can be
> processed by IMA.

This seems very over-complicated, and it's unclear why the kernel
needs to open the file itself. You *know* that all of userland is
trustworthy at this point even in the absence of signatures. It seems
reasonable to provide a interface that allows userland to pass a
digest list to the kernel, in the same way that userland can pass an
IMA policy to the kernel. You can then restrict access to that
interface via an LSM.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/15] ima: digest list feature

[Roberto Sassu]

On 11/8/2017 4:48 PM, Matthew Garrett wrote:

On Wed, Nov 8, 2017 at 7:00 AM, Roberto Sassu  wrote:

On 11/7/2017 7:06 PM, Matthew Garrett wrote:

But we're still left in a state where the kernel has to end up
supporting a number of very niche formats, and userland agility is
tied to the kernel. I think it makes significantly more sense to push
the problem out to userland.



At least for appraisal, digest lists must be parsed by the kernel. If
the parser is moved to userspace, I don't know if we are able to provide
the same guarantee, that the correct set of digests has been uploaded to
IMA. A new measurement can be added, when IMA receives the digests, but
a verifier has to verify the signature of the original file, perform
format conversion, calculate the digest and compare it with that in the
new IMA measurement. If digest lists are parsed directly by the kernel,
then the signature can be verified directly.


The code doing the parsing is in the initramfs, which has already been
measured at boot time. You can guarantee that it's being done by
trusted code.


The parser can be executed in the initial ram disk, but everything
accessed before the parser is executed will be measured/appraised
without digest lists. To do signature-based remote attestation, where
the verification consists on checking the signature of digests of
measured files, it would be necessary to sign systemd, libraries,
everything accessed before the parser, and the parser. If RPM headers
are parsed by the kernel, measurement/appraisal will be done directly
with digest lists.



Isn't failing to upload the expected digest list just a DoS? We
already expect to load keys from initramfs, so it seems fine to parse
stuff there - what's the problem with extracting information from
RPMs, translating them to the generic format and pushing that into the
kernel?



The main problem is that the digest list measurement, performed when the
parser accesses the file containing the RPM header, might not reflect
what IMA uses for digest lookup.


Why not?


I assumed you wanted to measure digest lists only at the time they are
read by the parser, and not when they are read by IMA. If instead digest
lists are verified again after conversion, the new workflow should be:

1) the kernel parses digest list metadata before systemd is executed
2) the kernel verifies the signature of digest lists (RPM headers) and
   add the digest of digest lists to the hash table, so that appraisal
   succeeds
3) systemd (with file signature) is executed
4) the parser (with file signature) is executed
5) the parser reads and converts the digest lists to the generic format,
   and writes them to a tmpfs filesystem
6) the parser generates a new digest list metadata file with the path of
   converted digest lists and sends the path of the new metadata to IMA
7) IMA reads the generic digest lists

The measurement list should look like:

10  ima-sig  boot_aggregate
10  ima-sig  /etc/ima/digest_lists/metadata
10  ima-sig  /usr/lib/systemd/systemd 
...
10  ima-sig   
10  ima-sig  /tmp/metadata


If parsing of RPM headers is done by the kernel, the measurement list
will look like:

10  ima-ng  boot_aggregate
10  ima-ng  /etc/ima/digest_lists/metadata


A built-in policy should enable appraisal of tmpfs. If not, patch 11/15
disables digest lookup for appraisal. Since generic digest lists will
have a security.ima extended attribute (they are mutable files),
appraisal verification will succeed.

With this solution, digital signatures cannot be required, because
generic digest lists will have a HMAC. For appraisal, it becomes
necessary to ensure that only digest lists written by the parser can be
processed by IMA.

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-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/15] ima: digest list feature

[Matthew Garrett]

On Wed, Nov 8, 2017 at 7:00 AM, Roberto Sassu  wrote:
> On 11/7/2017 7:06 PM, Matthew Garrett wrote:
>> But we're still left in a state where the kernel has to end up
>> supporting a number of very niche formats, and userland agility is
>> tied to the kernel. I think it makes significantly more sense to push
>> the problem out to userland.
>
>
> At least for appraisal, digest lists must be parsed by the kernel. If
> the parser is moved to userspace, I don't know if we are able to provide
> the same guarantee, that the correct set of digests has been uploaded to
> IMA. A new measurement can be added, when IMA receives the digests, but
> a verifier has to verify the signature of the original file, perform
> format conversion, calculate the digest and compare it with that in the
> new IMA measurement. If digest lists are parsed directly by the kernel,
> then the signature can be verified directly.

The code doing the parsing is in the initramfs, which has already been
measured at boot time. You can guarantee that it's being done by
trusted code.

>> Isn't failing to upload the expected digest list just a DoS? We
>> already expect to load keys from initramfs, so it seems fine to parse
>> stuff there - what's the problem with extracting information from
>> RPMs, translating them to the generic format and pushing that into the
>> kernel?
>
>
> The main problem is that the digest list measurement, performed when the
> parser accesses the file containing the RPM header, might not reflect
> what IMA uses for digest lookup.

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

Re: [PATCH v2 00/15] ima: digest list feature

[Roberto Sassu]

On 11/7/2017 7:06 PM, Matthew Garrett wrote:

On Tue, Nov 7, 2017 at 12:53 PM, Roberto Sassu  wrote:

On 11/7/2017 3:49 PM, Matthew Garrett wrote:

RPM's hardly universal, and distributions are in the process of moving
away from using it for distributing non-core applications (Flatpak and
Snap are becoming increasingly popular here). I think this needs to be
a generic solution rather than having the kernel tied to a specific
package format.



Support for new digest list formats can be easily added. Digest list
metadata includes the digest list type, so that the appropriate parser
is selected.


But we're still left in a state where the kernel has to end up
supporting a number of very niche formats, and userland agility is
tied to the kernel. I think it makes significantly more sense to push
the problem out to userland.


At least for appraisal, digest lists must be parsed by the kernel. If
the parser is moved to userspace, I don't know if we are able to provide
the same guarantee, that the correct set of digests has been uploaded to
IMA. A new measurement can be added, when IMA receives the digests, but
a verifier has to verify the signature of the original file, perform
format conversion, calculate the digest and compare it with that in the
new IMA measurement. If digest lists are parsed directly by the kernel,
then the signature can be verified directly.



Digest lists should be parsed directly by the kernel, because processing
the lists in userspace would increase the chances that a compromised
tool does not upload to the kernel the expected digests. Also, digest
lists must be processed before init, otherwise appraisal will deny the
execution. Lastly, the mechanism of parsing files from the kernel is
already used to parse the IMA policy.


Isn't failing to upload the expected digest list just a DoS? We
already expect to load keys from initramfs, so it seems fine to parse
stuff there - what's the problem with extracting information from
RPMs, translating them to the generic format and pushing that into the
kernel?


The main problem is that the digest list measurement, performed when the
parser accesses the file containing the RPM header, might not reflect
what IMA uses for digest lookup.

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-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 00/15] ima: digest list feature

[Safford, David (GE Global Research, US)]

> -Original Message-
> From: linux-integrity-ow...@vger.kernel.org [mailto:linux-integrity-
> ow...@vger.kernel.org] On Behalf Of Roberto Sassu
> Sent: Tuesday, November 07, 2017 5:37 AM
> To: linux-integr...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-doc@vger.kernel.org; linux-ker...@vger.kernel.org;
> silviu.vlasce...@huawei.com; Roberto Sassu <roberto.sa...@huawei.com>
> Subject: EXT: [PATCH v2 00/15] ima: digest list feature
> 
> IMA is a security module with the objective of reporting or enforcing the
> integrity of a system, by measuring files accessed with the execve(),
> mmap() and open() system calls. For reporting, it takes advantage of the
> TPM and extends a PCR with the digest of an evaluated event. For enforcing,
> it returns a value which is zero if the operation should be allowed, negative 
> if
> it should be denied.
> 
> Measuring files of an operating system introduces three main issues. First,
> since the overhead introduced by the TPM is noticeable, the performance of
> the system decreases linearly with the number of measurements taken. 
> This can be seen especially at boot time.

If you want the measurement chain of trust, every link must be extended in the 
TPM.
This is inherent in the model. Doing local verification of TCB files is really 
no substitute.
Not to mention that leaving out "known" hashes from attestation eliminates the 
ability to do analytics on the patterns of usage of the good files. Local 
appraisal is a 
good thing, but not a complete substitute for remote attestation.

> Second, managing large measurement
> lists requires computation power and network bandwidth. 

So 200 nodes with 5000 entries, 100bytes per entry average (that's a pretty 
large TCB, but OK):
that's roughly .8 seconds total on a single Gb link.

> Third, it is
> necessary to obtain reference measurements (i.e. digests of software
> known to be good) to evaluate/enforce the integrity of the system. If file
> signatures are used to enforce access, Linux distribution vendors have to
> modify their building systems in order to include signatures in their 
> packages.

Or you can use the initial enrollment to transfer a reference manifest.
Or you can use SWIDS. Or you can sign everything yourself. (That's what we do.)

> Digest lists aim at mitigating these issues. A digest list is a list of 
> digests that
> are taken by IMA as reference measurements and loaded before files are
> accessed. Then, IMA compares calculated digests of accessed files with
> digests from loaded digest lists. If the digest is found, measurement,
> appraisal and audit are not performed.

So who manages the "good" hash lists? They have to go into the initramfs,
and be updated with every package update. And Leaving out attestation of 
good TCB files reduces the potential power of analytics.

> Multiple digest lists can be loaded at the same time, by providing to IMA
> metadata for each list: digest, signature and path. The digest is specified so
> that loaded digest lists can be identified only with the measurement of
> metadata. The signature is used for appraisal. If the verification succeeds,
> IMA loads the digest list even if security.ima is missing.
> 
> Digest lists address the first issue because the TPM is used only if the 
> digest
> of a measured file is unknown. On a minimal system, 10 of 1400
> measurements are unknown because of mutable files (e.g. log files).

At 5ms per extend, you at most save 7 seconds at boot. But the savings are
actually much less, as the extends run simultaneously with most of the
other boot operations. I typically can't tell the difference without a 
stopwatch.

> Digest lists mitigate the second issue because, since digest lists do not
> change, they don't have to be sent at every remote attestation. Sending
> unknown measurements and a reference to digest lists would be sufficient.

The .8 second isn't a problem, and even that can be pretty much eliminated by
sending just the delta measurements.

> Finally, digest lists address also the third issue because Linux distribution
> vendors already provide the digests of files included in each RPM package.
> The digest list is stored in the RPM header, signed by the vendor.

But then tooling is needed to select the desired hashes and put them in
the initramfs for loading.

I guess I don't see the problem, and think the cure introduces issues of its 
own.

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

Re: [PATCH v2 00/15] ima: digest list feature

[Matthew Garrett]

On Tue, Nov 7, 2017 at 12:53 PM, Roberto Sassu  wrote:
> On 11/7/2017 3:49 PM, Matthew Garrett wrote:
>> RPM's hardly universal, and distributions are in the process of moving
>> away from using it for distributing non-core applications (Flatpak and
>> Snap are becoming increasingly popular here). I think this needs to be
>> a generic solution rather than having the kernel tied to a specific
>> package format.
>
>
> Support for new digest list formats can be easily added. Digest list
> metadata includes the digest list type, so that the appropriate parser
> is selected.

But we're still left in a state where the kernel has to end up
supporting a number of very niche formats, and userland agility is
tied to the kernel. I think it makes significantly more sense to push
the problem out to userland.

> Digest lists should be parsed directly by the kernel, because processing
> the lists in userspace would increase the chances that a compromised
> tool does not upload to the kernel the expected digests. Also, digest
> lists must be processed before init, otherwise appraisal will deny the
> execution. Lastly, the mechanism of parsing files from the kernel is
> already used to parse the IMA policy.

Isn't failing to upload the expected digest list just a DoS? We
already expect to load keys from initramfs, so it seems fine to parse
stuff there - what's the problem with extracting information from
RPMs, translating them to the generic format and pushing that into the
kernel?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/15] ima: digest list feature

[Roberto Sassu]

On 11/7/2017 3:49 PM, Matthew Garrett wrote:

On Tue, Nov 7, 2017 at 2:36 AM, Roberto Sassu  wrote:

Finally, digest lists address also the third issue because Linux
distribution vendors already provide the digests of files included in each
RPM package. The digest list is stored in the RPM header, signed by the
vendor.


RPM's hardly universal, and distributions are in the process of moving
away from using it for distributing non-core applications (Flatpak and
Snap are becoming increasingly popular here). I think this needs to be
a generic solution rather than having the kernel tied to a specific
package format.


Support for new digest list formats can be easily added. Digest list
metadata includes the digest list type, so that the appropriate parser
is selected.

I defined a new generic format for digest lists in Patch 7/15. I would
appreciate if we can discuss this format, and if you can give me
suggestions about how to improve it. I think it would not be a problem
to support your use case and associate metadata to each digest.

Digest lists should be parsed directly by the kernel, because processing
the lists in userspace would increase the chances that a compromised
tool does not upload to the kernel the expected digests. Also, digest
lists must be processed before init, otherwise appraisal will deny the
execution. Lastly, the mechanism of parsing files from the kernel is
already used to parse the IMA policy.

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-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/15] ima: digest list feature

[Roberto Sassu]

On 11/7/2017 2:37 PM, Mimi Zohar wrote:

Hi Roberto,

On Tue, 2017-11-07 at 11:36 +0100, Roberto Sassu wrote:

IMA is a security module with the objective of reporting or enforcing the
integrity of a system, by measuring files accessed with the execve(),
mmap() and open() system calls. For reporting, it takes advantage of the
TPM and extends a PCR with the digest of an evaluated event. For enforcing,
it returns a value which is zero if the operation should be allowed,
negative if it should be denied.

Measuring files of an operating system introduces three main issues. First,
since the overhead introduced by the TPM is noticeable, the performance of
the system decreases linearly with the number of measurements taken. This
can be seen especially at boot time.


I've said this previously.  The solution IS FIRST to improve the
performance of the TPM device driver, before finding solutions around
it.

TPM performance patches:
a233a0289cf9 "tpm: msleep() delays - replace with usleep_range() in i2c nuvoton 
driver"
0afb7118ae02 "tpm: add sleep only for retry in i2c_nuvoton_write_status()"
9f3fc7bcddcb "tpm: replace msleep() with  usleep_range() in TPM 1.2/2.0 generic 
drivers"

Nayna Jain submitted additional performance improvements, that were posted
https://www.spinics.net/lists/linux-integrity/msg00238.html and are
currently being tested.

Even after these TPM performance improvements, there are still more
TPM performance improvements.


Hi Mimi

I applied the patches you mentioned, and indeed the performance
improvement is great, from 1 minute and 30 seconds to 24 seconds
compared to the normal boot time of 8.5 seconds. However, especially for
embedded devices performances requirements might be more strict, and
much more files might be measured. For desktops, also it would be
desirable to have low latency.



Second, managing large measurement
lists requires computation power and network bandwidth.


"Large" for whom?  Large for the attestation server?  Large for the
client?  Smaller devices would have fewer measurements than larger
devices.  We're not discussing gigabytes/terabytes of data here.
  Attestation servers should be able to handle the bandwidth.  If it
becomes a problem, then the attestation server/client communication
could be optimized to send just the recent measurements, not the
entire measurement list.


I'm not considering an individual system, but a datacenter with several
nodes. An attestation server processing for example 200 measurement
lists with 5000 entries must be much more powerful than one that
processes the same number of lists with 10 entries.



Third, it is
necessary to obtain reference measurements (i.e. digests of software known
to be good) to evaluate/enforce the integrity of the system. If file
signatures are used to enforce access, Linux distribution vendors have to
modify their building systems in order to include signatures in their
packages.


Although IMA-appraisal verifies file integrity based on either a file
hash or signature, they are not equivalent.  File signatures provide
file provenance.  Not only does the file hash have to match, but a
certificate used to sign the file data must be loaded onto the IMA
keyring.  File hashes should be limited to mutable files.


Digest lists work the same. If appraisal is in enforcing mode, digest
lists must have a valid digital signature.



Instead of working around the problem of a lack of file signatures in
software packages, help promote including them so that there are
measurement and signature chains of trust anchored in hardware.


One of the key point of digest lists feature is that it reuses
information that is already available, while providing the same security
properties. I find it difficult to promote a solution that would
introduce redundant information and complicate the management of Linux
distributions.



Digest lists aim at mitigating these issues. A digest list is a list of
digests that are taken by IMA as reference measurements and loaded before
files are accessed. Then, IMA compares calculated digests of accessed files
with digests from loaded digest lists. If the digest is found, measurement,
appraisal and audit are not performed.


Although the previous patch set did not break userspace per-se, it
changed the existing meaning of the IMA measurement list.  Without
taking into account my previous comments, this patch set makes similar
changes to IMA-appraisal and IMA-measurement.


For appraisal, I think only the verification method changes: instead of
verifying file signatures individually, IMA verifies one signature per
many file digests.



Instead of including the individual file measurements, the previous
version of this patch set, I assume it hasn't changed, includes a hash
of a file containing a list of all potential file measurements, not
the actual file measurements.


Digest lists do not introduce false positives due to not including a
measurement. Files whose digest is included in a digest 

Re: [PATCH v2 00/15] ima: digest list feature

[Matthew Garrett]

On Tue, Nov 7, 2017 at 2:36 AM, Roberto Sassu  wrote:
> Finally, digest lists address also the third issue because Linux
> distribution vendors already provide the digests of files included in each
> RPM package. The digest list is stored in the RPM header, signed by the
> vendor.

RPM's hardly universal, and distributions are in the process of moving
away from using it for distributing non-core applications (Flatpak and
Snap are becoming increasingly popular here). I think this needs to be
a generic solution rather than having the kernel tied to a specific
package format.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/15] ima: digest list feature

[Mimi Zohar]

Hi Roberto,

On Tue, 2017-11-07 at 11:36 +0100, Roberto Sassu wrote:
> IMA is a security module with the objective of reporting or enforcing the
> integrity of a system, by measuring files accessed with the execve(),
> mmap() and open() system calls. For reporting, it takes advantage of the
> TPM and extends a PCR with the digest of an evaluated event. For enforcing,
> it returns a value which is zero if the operation should be allowed,
> negative if it should be denied.
> 
> Measuring files of an operating system introduces three main issues. First,
> since the overhead introduced by the TPM is noticeable, the performance of
> the system decreases linearly with the number of measurements taken. This
> can be seen especially at boot time.

I've said this previously.  The solution IS FIRST to improve the
performance of the TPM device driver, before finding solutions around
it.

TPM performance patches:
a233a0289cf9 "tpm: msleep() delays - replace with usleep_range() in i2c nuvoton 
driver"
0afb7118ae02 "tpm: add sleep only for retry in i2c_nuvoton_write_status()"
9f3fc7bcddcb "tpm: replace msleep() with  usleep_range() in TPM 1.2/2.0 generic 
drivers"

Nayna Jain submitted additional performance improvements, that were posted
https://www.spinics.net/lists/linux-integrity/msg00238.html and are
currently being tested.

Even after these TPM performance improvements, there are still more
TPM performance improvements.

> Second, managing large measurement
> lists requires computation power and network bandwidth.

"Large" for whom?  Large for the attestation server?  Large for the
client?  Smaller devices would have fewer measurements than larger
devices.  We're not discussing gigabytes/terabytes of data here.
 Attestation servers should be able to handle the bandwidth.  If it
becomes a problem, then the attestation server/client communication
could be optimized to send just the recent measurements, not the
entire measurement list.

> Third, it is
> necessary to obtain reference measurements (i.e. digests of software known
> to be good) to evaluate/enforce the integrity of the system. If file
> signatures are used to enforce access, Linux distribution vendors have to
> modify their building systems in order to include signatures in their
> packages.

Although IMA-appraisal verifies file integrity based on either a file
hash or signature, they are not equivalent.  File signatures provide
file provenance.  Not only does the file hash have to match, but a
certificate used to sign the file data must be loaded onto the IMA
keyring.  File hashes should be limited to mutable files.

Instead of working around the problem of a lack of file signatures in
software packages, help promote including them so that there are
measurement and signature chains of trust anchored in hardware.

> Digest lists aim at mitigating these issues. A digest list is a list of
> digests that are taken by IMA as reference measurements and loaded before
> files are accessed. Then, IMA compares calculated digests of accessed files
> with digests from loaded digest lists. If the digest is found, measurement,
> appraisal and audit are not performed.

Although the previous patch set did not break userspace per-se, it
changed the existing meaning of the IMA measurement list.  Without
taking into account my previous comments, this patch set makes similar
changes to IMA-appraisal and IMA-measurement.

Instead of including the individual file measurements, the previous
version of this patch set, I assume it hasn't changed, includes a hash
of a file containing a list of all potential file measurements, not
the actual file measurements.

Instead of changing the meaning of the IMA measurement list, I
previously suggested defining a new securityfs file for this purpose.

> Multiple digest lists can be loaded at the same time, by providing to IMA
> metadata for each list: digest, signature and path. The digest is specified
> so that loaded digest lists can be identified only with the measurement of
> metadata. The signature is used for appraisal. If the verification
> succeeds, IMA loads the digest list even if security.ima is missing.

Previously IMA-appraisal verified the file signature of the file
containing the file hashes.  It now sounds like even this guarantee is
gone.

Normally, the protection of kernel memory is out of scope for IMA.
This patch set introduces an in kernel white list, which would be a
prime target for attackers looking for ways of by-passing IMA-
measurement, IMA-appraisal and IMA-audit.  Others might disagree, but
from my perspective, this risk is too high.

Mimi

> Digest lists address the first issue because the TPM is used only if the
> digest of a measured file is unknown. On a minimal system, 10 of 1400
> measurements are unknown because of mutable files (e.g. log files).
> 
> Digest lists mitigate the second issue because, since digest lists do not
> change, they don't have to be sent at every remote attestation. Sending
> 

[PATCH v2 00/15] ima: digest list feature

[Roberto Sassu]

IMA is a security module with the objective of reporting or enforcing the
integrity of a system, by measuring files accessed with the execve(),
mmap() and open() system calls. For reporting, it takes advantage of the
TPM and extends a PCR with the digest of an evaluated event. For enforcing,
it returns a value which is zero if the operation should be allowed,
negative if it should be denied.

Measuring files of an operating system introduces three main issues. First,
since the overhead introduced by the TPM is noticeable, the performance of
the system decreases linearly with the number of measurements taken. This
can be seen especially at boot time. Second, managing large measurement
lists requires computation power and network bandwidth. Third, it is
necessary to obtain reference measurements (i.e. digests of software known
to be good) to evaluate/enforce the integrity of the system. If file
signatures are used to enforce access, Linux distribution vendors have to
modify their building systems in order to include signatures in their
packages.

Digest lists aim at mitigating these issues. A digest list is a list of
digests that are taken by IMA as reference measurements and loaded before
files are accessed. Then, IMA compares calculated digests of accessed files
with digests from loaded digest lists. If the digest is found, measurement,
appraisal and audit are not performed.

Multiple digest lists can be loaded at the same time, by providing to IMA
metadata for each list: digest, signature and path. The digest is specified
so that loaded digest lists can be identified only with the measurement of
metadata. The signature is used for appraisal. If the verification
succeeds, IMA loads the digest list even if security.ima is missing.

Digest lists address the first issue because the TPM is used only if the
digest of a measured file is unknown. On a minimal system, 10 of 1400
measurements are unknown because of mutable files (e.g. log files).

Digest lists mitigate the second issue because, since digest lists do not
change, they don't have to be sent at every remote attestation. Sending
unknown measurements and a reference to digest lists would be sufficient.

Finally, digest lists address also the third issue because Linux
distribution vendors already provide the digests of files included in each
RPM package. The digest list is stored in the RPM header, signed by the
vendor.

When using digest lists, a limitation must be considered. Since a
measurement is not reported if the digest of an accessed file is found in a
digest list, the measurement list does not show which files have been
actually accessed, and in which sequence.

A possible solution would be to load a list with digest of files which are
usually accessed. Also, it is possible to selectively enable digest list
lookup only for a subset of IMA policy rules. For example, a policy could
enable digest lookup only for file accesses from the TCB and disable it
for execve() and mmap() from regular users.

Changelog

v1:
- added new policy option digest_list to selectively enable digest lookup
- added support for appraisal
- added support for immutable/mutable files

Roberto Sassu (15):
  ima: generalize ima_read_policy()
  ima: generalize ima_write_policy()
  ima: generalize policy file operations
  ima: use ima_show_htable_value to show hash table data
  ima: add functions to manage digest lists
  ima: add parser of digest lists metadata
  ima: add parser of compact digest list
  ima: add parser of RPM package headers
  ima: introduce securityfs interfaces for digest lists
  ima: disable digest lookup if digest lists are not checked
  ima: add policy action digest_list
  ima: do not update security.ima if appraisal status is not
INTEGRITY_PASS
  evm: add kernel command line option to select protected xattrs
  ima: add support for appraisal with digest lists
  ima: add Documentation/security/IMA-digest-lists.txt

 Documentation/admin-guide/kernel-parameters.txt |   4 +
 Documentation/security/IMA-digest-lists.txt | 161 
 include/linux/evm.h |   6 +
 include/linux/fs.h  |   2 +
 security/integrity/evm/evm_main.c   |  36 +++
 security/integrity/iint.c   |   1 +
 security/integrity/ima/Kconfig  |  19 ++
 security/integrity/ima/Makefile |   1 +
 security/integrity/ima/ima.h|  33 ++-
 security/integrity/ima/ima_api.c|   7 +-
 security/integrity/ima/ima_appraise.c   |  52 +++-
 security/integrity/ima/ima_digest_list.c| 326 
 security/integrity/ima/ima_fs.c | 181 -
 security/integrity/ima/ima_main.c   |  47 +++-
 security/integrity/ima/ima_policy.c |  33 ++-
 security/integrity/ima/ima_queue.c  |  42 +++
 security/integrity/integrity.h  |  11 +
 17 files changed, 877