[PATCH 2 of 4] ima: related Makefile compile order change and Readme

[PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Reiner Sailer]

The IBM Integrity Measurement Architecture (IMA) builds information
about the software that was loaded into a system run-time since the
last reboot. For each loaded executable (binary, kernel module,
library), the IMA calculates once a SHA1 value over the executable file 
and stores it for later reference. IMA uses (optionally) the Trusted
Computing Group Trusted Platform Module to protect the integrity of
the accumulated measurements. IMA can, for example, be used to build 
services that detect compromised malicious software loaded into the 
runtime or can be used to validate expected system configurations.

IMA consists of 3 patches (patch 2,3,4 of 4) and needs another patch
(1 of 4) to enable it to use the TPM driver from inside the kernel.

This current patch 2of4 changes the compile order and ensures that the
crypto api is initialized before IMA comes up and uses it. It also
includes a high-level documentation file.

This patch applies to the clean 2.6.12-rc4 test kernel.

Signed-off-by: Reiner Sailer <sailer@watson.ibm.com>
---
diff -uprN linux-2.6.12-rc4/Documentation/integrity_measurements.txt linux-2.6.12-rc4-ima/Documentation/integrity_measurements.txt
--- linux-2.6.12-rc4/Documentation/integrity_measurements.txt	1969-12-31 19:00:00.000000000 -0500
+++ linux-2.6.12-rc4-ima/Documentation/integrity_measurements.txt	2005-05-19 21:09:37.000000000 -0400
@@ -0,0 +1,87 @@
+The IBM Integrity Measurement Architecture (IMA) offers means to
+securely identify the software that was loaded into a system run-time
+since the last reboot. The IMA builds the information necessary to
+identify the loaded software and provides the basis for services to
+build on top of such information. However, it does not include any
+means that would enable remote parties to extract the information
+itself.
+
+Guarantees: IMA offers "software load-guarantees" in that
+identification of all loaded software is guaranteed to be reflected in
+measurement data and protected in a hardware TPM security chip (if
+available). IMA is non-intrusive and neither disturbs the system, nor
+prevents the system from any actions. However, if running in real
+mode, when the TPM chip is not accessible IMA might require the system
+not to start (for security guarantee reasons).
+
+Limitations: IMA does not detect corruption of software once it is
+loaded into main memory. Instead, it indicates known vulnerabilities
+in such software (e.g., buffer overflow) by securely identifying the
+software at load-time. Only executable files (binaries, libraries,
+kernel modules) are measured by default. However, IMA offers a
+sysfs-interface that allows applications to instruct the kernel to
+measure files that they have opened.
+
+Assumed usage: Verify system installed software configurations and
+system run-time integrity from a secure management location.
+
+Operation: IMA is mainly an LSM module that measures all files mapped
+executable in the kernel as well as kernel modules. It operates after
+the principle >measure before load< as it is known from the Trusted
+Computing Group to identify static system boot configurations and
+extends this principle into the dynamic run-time. To this end, the
+file_mmap security hook builds a SHA1 hash value (our measurement)
+over the whole file, which is probably only partly mapped. These
+measurements are kept in an ordered list inside the kernel. We measure
+executable files only the first time they are loaded and after they
+changed. We use for efficiency dirty-flagging both in the inode of the
+mapped file (re-use) and in the kernel-held measurement list.
+
+Each time a new measurement entry is created and added to the
+measurement list, the hash value of this measurement entry is also
+"extended" into the hardware TPM chip (if available, see INSTALL). All
+these extensions result in a unique aggregate value (160 bit) inside
+the TPM chip, which securely identifies the current measurement list
+inside the kernel.
+
+Since the TPM chip cannot be manipulated from software and since the
+aggregation of the extended values is done in a way that cannot be
+undone (uses HW SHA1), the aggregate in the TPM serves as an integrity
+check value for the current measurement list in the kernel - since the
+kernel can be corrupted if the system software becomes
+compromised. Any software that might corrupt the system has already
+been measured and its measure value has already been aggregated into
+the hardware TPM chip before such software can corrupt the integrity
+measurement architecture itself.
+
+Benefit: Authorized parties can (i) ask the Linux system that runs IMA
+for the kernel-held measurement list and the current signed
+TPM-aggregate, (ii) recalculate the aggregate using the measurement
+list, and (iii) compare the calculated aggregate with the signed TPM
+aggregate. If both aggregates are the same, then the system has
+delivered the correct and latest measurement list. Since each
+measurement of the measurement list uniquely defines a certain
+executable file, the authorized (remote) party can therefore validate
+the software that was loaded into the Linux system since reboot. Many
+applications are possible. The control of the system is fully in the
+hands of the person that controls the Linux client; this person must
+actively offer services to remote parties so they can retrieve the
+measurement list and/or the signed TPM aggregate.
+
+Some of our work shows that IMA is very useful to detect Rootkit
+exploits that totally take over the software of a Linux system but
+cannot hide themselves from contributing to the TPM aggregate and this
+will be detectable from a non-corrupted platform. While the corrupted
+system might not show the Rootkit, a remote party can securely
+identify known bad or unknown software having been loaded into the
+system.
+
+Practice: IMA runs up about 650 measurements when running a Fedora
+Core 3 environment including Gnome desktop. Our system (cron switched
+off) does not accumulate more than this after 18 days uptime. If lots
+of different files (executables, libraries, and kernel modules) are
+executed, then the list may become very long and evaluating the
+measurements might incur increasing overhead. Generally, IMA is useful
+where the executed content is foreseeable and the validating party
+knows which measurements to expect.
+
diff -uprN linux-2.6.12-rc4/Makefile linux-2.6.12-rc4-ima/Makefile
--- linux-2.6.12-rc4/Makefile	2005-05-07 01:20:31.000000000 -0400
+++ linux-2.6.12-rc4-ima/Makefile	2005-05-19 17:59:20.000000000 -0400
@@ -562,7 +562,7 @@ export MODLIB
 
 
 ifeq ($(KBUILD_EXTMOD),)
-core-y		+= kernel/ mm/ fs/ ipc/ security/ crypto/
+core-y		+= kernel/ mm/ fs/ ipc/ crypto/ security/
 
 vmlinux-dirs	:= $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
 		     $(core-y) $(core-m) $(drivers-y) $(drivers-m) \

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Greg KH]

On Fri, May 20, 2005 at 09:36:20AM -0400, Reiner Sailer wrote:
> The IBM Integrity Measurement Architecture (IMA) builds information
> about the software that was loaded into a system run-time since the
> last reboot. For each loaded executable (binary, kernel module,
> library), the IMA calculates once a SHA1 value over the executable file 
> and stores it for later reference. IMA uses (optionally) the Trusted
> Computing Group Trusted Platform Module to protect the integrity of
> the accumulated measurements. IMA can, for example, be used to build 
> services that detect compromised malicious software loaded into the 
> runtime or can be used to validate expected system configurations.

Do you have any benchmarks with this code running in TPM and non-TPM
mode vs. normal operation?

Also, your coding style has some issues (spaces instead of tabs), {} for
one line if statements, etc.  Please fix them up.

Also DO NOT USE PROC!  Please use the proper kernel interfaces if you
wish to dump loads of statistics to userspace (your own filesystem,
sysfs, debugfs (hint, hint, hint...)

Also, there are a lot more virtual fs in the kernel than you are
checking against in your "don't care about these files" test.  You need
to have a comprehensive list if you want to get it correct.

thanks,

greg k-h

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Pavel Machek]

Hi!

> +Limitations: IMA does not detect corruption of software once it is
> +loaded into main memory. Instead, it indicates known vulnerabilities
> +in such software (e.g., buffer overflow) by securely identifying the
> +software at load-time. Only executable files (binaries, libraries,
> +kernel modules) are measured by default. However, IMA offers a
> +sysfs-interface that allows applications to instruct the kernel to
> +measure files that they have opened.

What is it good for, then? So I have to put my backdoor into script,
not into an executable...

> +Some of our work shows that IMA is very useful to detect Rootkit
> +exploits that totally take over the software of a Linux system but
> +cannot hide themselves from contributing to the TPM aggregate and this
> +will be detectable from a non-corrupted platform. While the corrupted
> +system might not show the Rootkit, a remote party can securely
> +identify known bad or unknown software having been loaded into the
> +system.

How does it work? It is corrupted software, not your TPM chip that is
talking over network.... Do you sign the measurements inside TPM chip?

								Pavel

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Reiner Sailer]

Pavel Machek <pavel@ucw.cz> wrote on 05/22/2005 03:37:17 PM:

> Hi!
> 
> > +Limitations: IMA does not detect corruption of software once it is
> > +loaded into main memory. Instead, it indicates known vulnerabilities
> > +in such software (e.g., buffer overflow) by securely identifying the
> > +software at load-time. Only executable files (binaries, libraries,
> > +kernel modules) are measured by default. However, IMA offers a
> > +sysfs-interface that allows applications to instruct the kernel to
> > +measure files that they have opened.
> 
> What is it good for, then? So I have to put my backdoor into script,
> not into an executable...

Scripts can be measured as well (from the user space).
 
For example, equipping the bash shell with 5-10 lines of code, bash 
initiates IMA measurements on scripts and files that are sourced into bash before 
they are "executed" by bash. This way, startup scripts and executed scripts can 
be logged as measurements and the measuremnt list will include them. 

> > +Some of our work shows that IMA is very useful to detect Rootkit
> > +exploits that totally take over the software of a Linux system but
> > +cannot hide themselves from contributing to the TPM aggregate and this
> > +will be detectable from a non-corrupted platform. While the corrupted
> > +system might not show the Rootkit, a remote party can securely
> > +identify known bad or unknown software having been loaded into the
> > +system.
> 
> How does it work? It is corrupted software, not your TPM chip that is
> talking over network.... Do you sign the measurements inside TPM chip?
> 
>                         Pavel

We sign the _integrity_value_ of the measurements inside the TPM.

TPMs offer signing of their so-called Platform Configuration 
Registers (PCR) inside the TPM (Quote). IMA uses one of these PCRs (kernel 
configuration option) to maintains an integrity value over the 
kernel-held measurement list. Whenever a new measurement is added, we 
also adjust the TPM PCR holding the integrity value (that's why we call 
it also a measurement aggregate).

You retrieve not only the measurement list from a system (kernel) but also 
a signature over the TPM PCR holding the integrity value. Nonces 
(random numbers) are used to protect against replay of old signed TPM PCR 
contents by the kernel. Since PCR is signed inside the TPM together with 
the nonce, corrupt system software can't cheat unnoticedly.

IMA implements the measurment hooks and maintains the measurement list 
and its integrity value in the TPM PCR. Services retrieving and evaluating 
measurement lists can be based on top of IMA.

Thanks
Reiner

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[James Morris]

On Sun, 22 May 2005, Reiner Sailer wrote:

> IMA implements the measurment hooks and maintains the measurement list 
> and its integrity value in the TPM PCR. Services retrieving and evaluating 
> measurement lists can be based on top of IMA.

Perhaps I don't understand things fully, but what is the purpose of 
providing measurement values locally via proc?

How can they be trusted without the TPM signing an externally generated 
nonce?


- James
-- 
James Morris
<jmorris@redhat.com>

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Mon, 23 May 2005 00:30:15 EDT, James Morris said:

> Perhaps I don't understand things fully, but what is the purpose of 
> providing measurement values locally via proc?
> 
> How can they be trusted without the TPM signing an externally generated 
> nonce?

If you can't trust what the kernel is outputting in /proc, you're screwed.

And for that matter, how would you verify that it's the TPM that signed the
externally generated nonce? (Remember - if you can't trust /proc, then you
have to assume that *any* attempt at talking to the TPM from userspace *is*
a MITM attack - and you don't have access to any out-of-band info.  If the
now-untrusted kernel did a MITM on your nonce and signed it with a fake key,
then it can *also* MITM your attempt to read the "correct" key from /etc/tpm.key
or wherever it is....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Pavel Machek]

Hi!

> > > +Limitations: IMA does not detect corruption of software once it is
> > > +loaded into main memory. Instead, it indicates known vulnerabilities
> > > +in such software (e.g., buffer overflow) by securely identifying the
> > > +software at load-time. Only executable files (binaries, libraries,
> > > +kernel modules) are measured by default. However, IMA offers a
> > > +sysfs-interface that allows applications to instruct the kernel to
> > > +measure files that they have opened.
> > 
> > What is it good for, then? So I have to put my backdoor into script,
> > not into an executable...
> 
> Scripts can be measured as well (from the user space).
>  
> For example, equipping the bash shell with 5-10 lines of code, bash 
> initiates IMA measurements on scripts and files that are sourced into bash before 
> they are "executed" by bash. This way, startup scripts and executed scripts can 
> be logged as measurements and the measuremnt list will include
> them. 

Well, for this to be usefull, you'd have to split files into two
categories:

1) files that do not change

2) files that can not compromise your security.

I guess that /etc/shadow *has to change*, and it still can compromise
your system security.

Same with basch scripts; you can make bash checksum its script, but
when user modifies his first script, you'll detect system as
"compromised".

I guess it can work... but I don't see how it can work in Linux.

								Pavel

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Reiner Sailer]

Valdis.Kletnieks@vt.edu wrote on 05/23/2005 12:52:13 AM:

> On Mon, 23 May 2005 00:30:15 EDT, James Morris said:
> 
> > Perhaps I don't understand things fully, but what is the purpose of 
> > providing measurement values locally via proc?
> > 
> > How can they be trusted without the TPM signing an externally generated 
> > nonce?
> 
> If you can't trust what the kernel is outputting in /proc, you're screwed.

No, this is not the case. You can establish trust into the measurements 
read through /proc by validating the TPM signature over the measurement 
aggregate on a separate, trusted system. IMA measurements are not intended 
to be used on the local system but on a separate system that is trusted not 
to be compromised. The system validating the measurements does not trust 
the origin; the TPM signature is the part that (i) verifies 
the integrity of the measurement list, and (ii) verifies the platform 
where the signature was created and links the validated measurement list 
to this system.

You can think of IMA as a reliable, Hardware-root-of-trust (TPM) 
based logging mechanism for loaded executables. IMA is a usage-example of 
the TPM HW root-of-trust used to gain confidence into what was loaded into 
another system. Since IMA is released opensource (GPL), people can experiment 
with services putting value to the IMA load-time guarantees. We did experiment 
with IMA, and we found it interesting enough to make it available.

> And for that matter, how would you verify that it's the TPM that signed the
> externally generated nonce? (Remember - if you can't trust /proc, then you
> have to assume that *any* attempt at talking to the TPM from userspace *is*
> a MITM attack - and you don't have access to any out-of-band info.  If the
> now-untrusted kernel did a MITM on your nonce and signed it with a fake key,
> then it can *also* MITM your attempt to read the "correct" key from /etc/tpm.key
> or wherever it is....

Your concern would be relevant if measurements were validated on 
the (measured) system that creates them, which is not the intended use.

Verification is based on the public TPM signature key: The remote party 
has a certificate of the public key of the system from which it retrieves 
measurements. If the public key does not 'validate' the TPM signature 
(delivered with a measurement list) then the retrieved  measurement list 
is not trusted. All signature keys used by the TPM are protected when stored 
outside the TPM chip. A system cannot use TPM signature keys outside the TPM
and cannot create valid signatures over manipulated measurement lists.

Man-in-the-middle-attacks on the measurement-list-retrieval are only successful
if the entity controlling the measured system can guess the 160bit random 
number (nonce) that will be used in the future by a remote party
or if a remote party re-uses nonces. In this case, old measurement lists can be 
replayed; this is very unlikely if the nonces / random numbers are chosen as 
directed in the TPM specs.

Thanks
Reiner

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Pavel Machek]

Hi!

> > > Perhaps I don't understand things fully, but what is the purpose of 
> > > providing measurement values locally via proc?
> > > 
> > > How can they be trusted without the TPM signing an externally generated 
> > > nonce?
> > 
> > If you can't trust what the kernel is outputting in /proc, you're screwed.
> 
> No, this is not the case. You can establish trust into the measurements 
> read through /proc by validating the TPM signature over the measurement 
> aggregate on a separate, trusted system. IMA measurements are not intended 
> to be used on the local system but on a separate system that is trusted not 
> to be compromised. The system validating the measurements does not
> trust 

Actually, you "could" also cat /proc files, then verify the signature
by hand (using pen and paper :-).

It seems to me that the mechanism is sound... it does what the docs
says. Another questions is "is it usefull"?

								Pavel 

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Reiner Sailer]

Pavel Machek <pavel@ucw.cz> wrote on 05/23/2005 04:39:29 PM:

> 
> Actually, you "could" also cat /proc files, then verify the signature
> by hand (using pen and paper :-).

Theoretically, yes. The signature is 2048bit and to validate the signed 
aggregate requires recursively applying SHA1 over all measurements.

> It seems to me that the mechanism is sound... it does what the docs
> says. Another questions is "is it usefull"?
> 
>                         Pavel 
> 

We implemented some exemplary IMA-applications. If you like, visit our 
project page and check out the references:
http://www.research.ibm.com/secure_systems_department/projects/tcglinux/
There you also find a complete  measurement list and a response of a measured 
system replying to an authorized remote measurement-list-request.

Thanks
Reiner

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Pavel Machek]

Hi!

> > Actually, you "could" also cat /proc files, then verify the signature
> > by hand (using pen and paper :-).
> 
> Theoretically, yes. The signature is 2048bit and to validate the signed 
> aggregate requires recursively applying SHA1 over all measurements.

:-)

> > It seems to me that the mechanism is sound... it does what the docs
> > says. Another questions is "is it usefull"?

> We implemented some exemplary IMA-applications. If you like, visit our 
> project page and check out the references:
> http://www.research.ibm.com/secure_systems_department/projects/tcglinux/
> There you also find a complete  measurement list and a response of a measured 
> system replying to an authorized remote measurement-list-request.

To make this usefull, you need to:

* have TPM chip

* modify all the interpreters

* modify all the programs that security-relevant config files. I.e. if
	there's /etc/keylogger.conf with default

	# No keyboard logging enabled

	and attacker changes it to

	do_log_keys_to_remote evil.com

	... you need that config file to be hashed.

* remove all the buffer overflows. I.e. if grub contains buffer
	overflow in parsing menu.conf... that is not a security hole
	(as of now) because only administrator can modify menu.conf.
	With IMA enabled, it would make your certification useless...

[probably something more].

...seems to me you need to do quite a lot of work to make this
usefull...

[And now, remote-buffer-overrun in inetd probably breaks your
attestation, no? I'll just load my evil code over the network, without
changing any on-disk executables, then install my evil rootkit into
kernel by writing into /dev/kmem. How do you prevent that one?]
								Pavel

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[James Morris]

On Mon, 23 May 2005, Reiner Sailer wrote:

> > It seems to me that the mechanism is sound... it does what the docs
> > says. Another questions is "is it usefull"?
> > 
> >                         Pavel 
> > 
> 
> We implemented some exemplary IMA-applications. If you like, visit our 
> project page and check out the references:
> http://www.research.ibm.com/secure_systems_department/projects/tcglinux/
> There you also find a complete  measurement list and a response of a measured 
> system replying to an authorized remote measurement-list-request.

How did you retrieve the TPM-aggregate?

I'm still not sure why exporting just the kernel measurement values via 
proc is useful.

Wouldn't you need to retrieve the measurement list atomically with the 
TPM-aggregate?

In which case, we'd need an interface which takes a nonce and returns the
kernel measurement list and the TPM-aggregate together.

Is the source of your example IMA attestation application available?


- James
-- 
James Morris
<jmorris@redhat.com>

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Reiner Sailer]

James Morris <jmorris@redhat.com> wrote on 05/23/2005 07:59:09 PM:

> On Mon, 23 May 2005, Reiner Sailer wrote:
> 
> > > It seems to me that the mechanism is sound... it does what the docs
> > > says. Another questions is "is it usefull"?
> > > 
> > >                         Pavel 
> > > 
> > 
> > We implemented some exemplary IMA-applications. If you like, visit our 

> > project page and check out the references:
> > 
http://www.research.ibm.com/secure_systems_department/projects/tcglinux/
> > There you also find a complete  measurement list and a response of a 
measured 
> > system replying to an authorized remote measurement-list-request.
> 
> How did you retrieve the TPM-aggregate?

We use the general TPM interface and a TPM library that IBM open-sourced 
in the
"early times of TPM". Today, the there is also the TrouSerS open-source 
(sorceforge)
stack that can be used to retrieve a quote. Other libraries are certainly
available as well. Any implementation offering TPM-Spec quote function can 
be used.

> I'm still not sure why exporting just the kernel measurement values via 
> proc is useful.

It is useful in practice because once the system is up and running, the
measurement list grows very slowly. Thus, retrieving the measurements 
separately from the signature did not result in sync problems 
(measurements
being added between retrieving the signature and retrieving the 
measurement
list). We did not have a single case where we run into the problem but one 
can
construct system loads that might trigger an async between the retrievals. 
In this 
case, one can adjust the measurement list (skip entries added after the 
TPM signature
was created) if you first retrieve the TPM signature and then the 
measurement list.
You'll discover the last signed measurement entries by recalculating the 
signed 
aggregate.

> Wouldn't you need to retrieve the measurement list atomically with the 
> TPM-aggregate?

You can do this atomically but then you need to implement the quote 
functionality
in the kernel when retrieving the list or you need to develop a quote* TPM 
command 
that includes the measurement list with the signature blob (non-TPM-spec 
conform). 
We chose to go with the original Quote (TPM signature) and keep the 
defined TPM 
interface, since we preferred keeping existing interfaces until we 
encounter problems.

> In which case, we'd need an interface which takes a nonce and returns 
the
> kernel measurement list and the TPM-aggregate together.

> Is the source of your example IMA attestation application available?

This application is not available at this time. However, its major 
building blocks
are almost all open-source (TSS stack, TPM kernel driver, IMA). The rest 
is mainly
communication infrastructure and building SHA1-databases to compare 
measurements 
against expected and known measurements.

> 
> - James
> -- 
> James Morris
> <jmorris@redhat.com>
> 
> 
> 

The point you are making is a good one. We implemented a trade-off and if 
users of
IMA suggest that the trade-off towards compatibility is leading to 
problems, it is 
worth to re-evaluate this trade-off and create an atomic function.

Thanks.
Reiner

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Reiner Sailer]

Pavel Machek <pavel@ucw.cz> wrote on 05/23/2005 07:44:54 PM:
> 
> To make this usefull, you need to:
> 
> * have TPM chip

TPM chips are becoming broadly available in many new
desktop and laptop systems. Drivers are open-source, see tpmdd
and TrouSerS projects on sourceforge.

> * remove all the buffer overflows. I.e. if grub contains buffer
>    overflow in parsing menu.conf... that is not a security hole
>    (as of now) because only administrator can modify menu.conf.
>    With IMA enabled, it would make your certification useless...

Taking your example: Even if you run a buffer-overflow grub, IMA will 
enable remote parties to differentiate between systems that run
the vulnerable grub and systems that don't. IMA in this case actually
can put value to running better software.

Additionally, you can see whether the operating system implements 
'useful' measures against buffer overflows. Information you don't easily 
get otherwise when communicating with /logging into a  
remote system. So you can determine if buffer-overflow-vulnerable 
applications run in operating environments that actually allow attackers 
to exploit such vulnerabilities.

> [probably something more].
> 
> ...seems to me you need to do quite a lot of work to make this
> usefull...

Things can be useful even though they don't solve all security problems. 
Think of IPSEC,  SSL, firewalls, tripwire. I find them useful even though 
they are not  offering total security. The experiments are aimed at 
finding useful trade-offs for different usage pattern (e.g., remote 
access) that raise the bar for attackers.
 
> [And now, remote-buffer-overrun in inetd probably breaks your
> attestation, no? I'll just load my evil code over the network, without
> changing any on-disk executables, then install my evil rootkit into
> kernel by writing into /dev/kmem. How do you prevent that one?]
>                         Pavel

We have IMA kernel configuration options to detect direct writes onto 
/dev/kmem and some other devices. If /dev/kmem is directly opened for 
writing, the aggregate in the TPM is invalidated. This system will not be 
able to deliver a measurement list with a fitting TPM aggregate signature 
until next reboot and clearing of all state.

Thanks 
Reiner

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Pavel Machek]

Hi!

> > * remove all the buffer overflows. I.e. if grub contains buffer
> >    overflow in parsing menu.conf... that is not a security hole
> >    (as of now) because only administrator can modify menu.conf.
> >    With IMA enabled, it would make your certification useless...
> 
> Taking your example: Even if you run a buffer-overflow grub, IMA will 
> enable remote parties to differentiate between systems that run
> the vulnerable grub and systems that don't. IMA in this case actually
> can put value to running better software.

Yes, but see above: that buffer overflow in grub was *not* a
vulnerability... not until you introduce IMA.

That is my biggest concern. You are completely changing rules for
userland code. Buffer overflow that only root could exploit used to be
okay. It used to be okay to read config files without communicating
with TPM.
								Pavel

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Reiner Sailer]

Pavel Machek <pavel@ucw.cz> wrote on 05/24/2005 02:47:52 PM:

> Hi!
> 
> > > * remove all the buffer overflows. I.e. if grub contains buffer
> > >    overflow in parsing menu.conf... that is not a security hole
> > >    (as of now) because only administrator can modify menu.conf.
> > >    With IMA enabled, it would make your certification useless...
> > 
> > Taking your example: Even if you run a buffer-overflow grub, IMA will 
> > enable remote parties to differentiate between systems that run
> > the vulnerable grub and systems that don't. IMA in this case actually
> > can put value to running better software.
> 
> Yes, but see above: that buffer overflow in grub was *not* a
> vulnerability... not until you introduce IMA.
> 
> That is my biggest concern. You are completely changing rules for
> userland code. Buffer overflow that only root could exploit used to be
> okay. It used to be okay to read config files without communicating
> with TPM.
>                         Pavel
> 

I don't follow your argumentation.

Measuring a file is done by new IMA code (hook) that opens the file, 
calculates the SHA1, closes the file, and saves new SHA1 measurements in the 
measurement list. This code must be carefully inspected. The only code 
that a user can trigger through IMA is the IMA kernel code that calculates 
the SHA1 over a file that the user has already opened (requires file 
descriptor).

Can you be more specific about how IMA affects existing buffer overflow 
vulnerabilities in grub or other applications?


Also, grub/grub.conf is not measured by users or the kernel but by the stages 
loading it (see below) according to the  "measure-before-load" principle, 
coined by the Trusted Computing Group.

I shortly summarize the steps involving TPM and measurements when booting 
a system to avoid misunderstandings of "who is measuring what and when":
 
(i) On TPM-enabled systems, the BIOS automatically measures the first 
bootstage (MBR) and some platform configuration parameters (usually 
configurable in the BIOS setup).

(ii) Then tcg-grub (if installed) measures its configuration file and 
later tcg-grub stages. Grub finally measures kernel and initrd before 
booting the kernel. This requires a grub-patch that creates the 
SHA1 measurements and extends TPM PCRs. There are to my knowlege 
opensource versions of grub extensions for tpm support already available 
and there are patches in preparation to be released soon.

(iii) Once started, the kernel part of IMA (the currently submitted ima 
patches) picks up these boot measurements and integrates them as the 
very first measurement into the measurement list and TPM PCR aggregate 
(look for it in the initialization code of the IMA patches submitted).

(iv) From then on, the IMA in the kernel is responsible for measuring 
executables/modules before loading them and for maintaining the 
measurement list and its TPM aggregate. 

(v) Remote parties will validate the boot stages with the very first
measurement, which they receive as part of the measurement list from IMA.

Thanks
Reiner

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Pavel Machek]

Hi!

> > > > * remove all the buffer overflows. I.e. if grub contains buffer
> > > >    overflow in parsing menu.conf... that is not a security hole
> > > >    (as of now) because only administrator can modify menu.conf.
> > > >    With IMA enabled, it would make your certification useless...
> > > 
> > > Taking your example: Even if you run a buffer-overflow grub, IMA will 
> > > enable remote parties to differentiate between systems that run
> > > the vulnerable grub and systems that don't. IMA in this case actually
> > > can put value to running better software.
> > 
> > Yes, but see above: that buffer overflow in grub was *not* a
> > vulnerability... not until you introduce IMA.
> > 
> > That is my biggest concern. You are completely changing rules for
> > userland code. Buffer overflow that only root could exploit used to be
> > okay. It used to be okay to read config files without communicating
> > with TPM.
> 
> I don't follow your argumentation.

Maybe I'm just wrong... I definitely chosen bad example (grub) because
it is also bootloader...

> (iv) From then on, the IMA in the kernel is responsible for measuring 
> executables/modules before loading them and for maintaining the 
> measurement list and its TPM aggregate. 

Kernel does not know what is exacutable and what is data. Thanks to
buffer overflows, the line between executable and data is extremely
blury.

Now, to my argumentation. Imagine bootscripts containing
"show_etc_issue" command. (That shows /etc/issue). If there's buffer
overflow in "show_etc_issue" command, it is *not* security issue as of
now, because it only works on data provided by root. But it becomes
issue when IMA system is in use, because now /etc/issue can be used to
inject code into system; something that was not possible before.

OTOH buffer overrun in show_etc_issue is certainly bad thing, because
it is unexpected behaviour; and if IMA means such stuff is fixed...

It just seems like a lot of work. You are basically adding check at
every place where user can
shoot_himself_in_the_foot^W^W^W^W^Wdo_something_stupid_to_system_security
. I suspect many config files can be used to compromise system
security...

								Pavel

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Reiner Sailer]

Pavel Machek <pavel@ucw.cz> wrote on 05/24/2005 06:41:44 PM:

> 
> Maybe I'm just wrong... I definitely chosen bad example (grub) because
> it is also bootloader...
> 
> > (iv) From then on, the IMA in the kernel is responsible for measuring 
> > executables/modules before loading them and for maintaining the 
> > measurement list and its TPM aggregate. 
> 
> Kernel does not know what is exacutable and what is data. Thanks to
> buffer overflows, the line between executable and data is extremely
> blury.
> 
> Now, to my argumentation. Imagine bootscripts containing
> "show_etc_issue" command. (That shows /etc/issue). If there's buffer
> overflow in "show_etc_issue" command, it is *not* security issue as of
> now, because it only works on data provided by root. But it becomes
> issue when IMA system is in use, because now /etc/issue can be used to
> inject code into system; something that was not possible before.
> 
> OTOH buffer overrun in show_etc_issue is certainly bad thing, because
> it is unexpected behaviour; and if IMA means such stuff is fixed...
> 
> It just seems like a lot of work. You are basically adding check at
> every place where user can
>  shoot_himself_in_the_foot^W^W^W^W^Wdo_something_stupid_to_system_security
> . I suspect many config files can be used to compromise system
> security...
> 
>                         Pavel
> 

Pavel, I cannot follow your argumentation. Could you please expand on how
measuring a script file would affect existing buffer overflows at all?

Just to make sure we are in sync how user space measurements work, here
a summary at the bash example:

(i) bash at point x opens "show_etc_issue" and holds file descriptor in 
    fd_show

(ii) before bash reads the commands from fd_show, we insert a line of code
    writing fd_show down into the kernel (this is a fixed size data 
    structure)

(iii) IMA hook in the kernel now reads the whole file building a SHA1
      (there is no interpretation of any content of any file here)

(iv)  IMA decides whether the measurement of the file must be stored or 
      whether it is already in the measurement list etc.

(v)   writing fd_show returns to bash

(vi) bash reads the commands and executes them

If I understand you, then you are claiming that steps (ii) to (v) 
introduce buffer overflows in bash or show_etc_issue. How?

Thanks
Reiner

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Pavel Machek]

Hi!

> > Maybe I'm just wrong... I definitely chosen bad example (grub) because
> > it is also bootloader...
> > 
> > > (iv) From then on, the IMA in the kernel is responsible for measuring 
> > > executables/modules before loading them and for maintaining the 
> > > measurement list and its TPM aggregate. 
> > 
> > Kernel does not know what is exacutable and what is data. Thanks to
> > buffer overflows, the line between executable and data is extremely
> > blury.
> > 
> > Now, to my argumentation. Imagine bootscripts containing
> > "show_etc_issue" command. (That shows /etc/issue). If there's buffer
> > overflow in "show_etc_issue" command, it is *not* security issue as of
> > now, because it only works on data provided by root. But it becomes
> > issue when IMA system is in use, because now /etc/issue can be used to
> > inject code into system; something that was not possible before.
> > 
> > OTOH buffer overrun in show_etc_issue is certainly bad thing, because
> > it is unexpected behaviour; and if IMA means such stuff is fixed...
> > 
> > It just seems like a lot of work. You are basically adding check at
> > every place where user can
> >  shoot_himself_in_the_foot^W^W^W^W^Wdo_something_stupid_to_system_security
> > . I suspect many config files can be used to compromise system
> > security...

> 
> Pavel, I cannot follow your argumentation. Could you please expand on how
> measuring a script file would affect existing buffer overflows at all?
> 
> Just to make sure we are in sync how user space measurements work, here
> a summary at the bash example:
> 
> (i) bash at point x opens "show_etc_issue" and holds file descriptor in 
>     fd_show
> 
> (ii) before bash reads the commands from fd_show, we insert a line of code
>     writing fd_show down into the kernel (this is a fixed size data 
>     structure)
> 
> (iii) IMA hook in the kernel now reads the whole file building a SHA1
>       (there is no interpretation of any content of any file here)
> 
> (iv)  IMA decides whether the measurement of the file must be stored or 
>       whether it is already in the measurement list etc.
> 
> (v)   writing fd_show returns to bash
> 
> (vi) bash reads the commands and executes them
> 
> If I understand you, then you are claiming that steps (ii) to (v) 
> introduce buffer overflows in bash or show_etc_issue. How?

No, I'm not claiming that. You are certainly *not* introducing any new
problems.

But some problems that used to be harmless (buffer overrun in
show_etc_issue command) are not harmless any more.
								Pavel

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Reiner Sailer]

Pavel Machek <pavel@ucw.cz> wrote on 05/25/2005 11:06:01 AM:

> > 
> > If I understand you, then you are claiming that steps (ii) to (v) 
> > introduce buffer overflows in bash or show_etc_issue. How?
> 
> No, I'm not claiming that. You are certainly *not* introducing any new
> problems.
> 
> But some problems that used to be harmless (buffer overrun in
> show_etc_issue command) are not harmless any more.
>                         Pavel

How is a buffer overrun in a script/application less "harmless" with IMA? 
Please be specific. Preliminary IMA patches are out on the mailing lists.

The only thing that IMA does with respect to existing known buffer 
overruns is that it enables remote parties to know that there is an application 
with a known buffer overrun if this application/script was measured. Such 
information is sensitive and this is one reason why direct access to the 
measurements are restricted to authorized/trusted parties.

Thanks
Reiner

Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Pavel Machek]

Hi!

> > > 
> > > If I understand you, then you are claiming that steps (ii) to (v) 
> > > introduce buffer overflows in bash or show_etc_issue. How?
> > 
> > No, I'm not claiming that. You are certainly *not* introducing any new
> > problems.
> > 
> > But some problems that used to be harmless (buffer overrun in
> > show_etc_issue command) are not harmless any more.
> 
> How is a buffer overrun in a script/application less "harmless" with IMA? 
> Please be specific. Preliminary IMA patches are out on the mailing lists.
> 
> The only thing that IMA does with respect to existing known buffer 
> overruns is that it enables remote parties to know that there is an application 
> with a known buffer overrun if this application/script was measured. Such 
> information is sensitive and this is one reason why direct access to the 
> measurements are restricted to authorized/trusted parties.

Well, you'll have to add measurement of any security-sensitive config
file, any script, and will have to make sure that all parsing of
system config files does not contain buffer-overrun problems. That's
lot of work before IMA is usefull. It is true you do not make
situation any worse.

Good luck and go ahead.
								Pavel