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 <[email protected]>
---
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) \
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
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
Pavel Machek <[email protected]> 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
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
<[email protected]>
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....
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
[email protected] 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
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
Pavel Machek <[email protected]> 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
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
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
<[email protected]>
Pavel Machek <[email protected]> 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
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
Pavel Machek <[email protected]> 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
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
Pavel Machek <[email protected]> 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
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
Pavel Machek <[email protected]> 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
James Morris <[email protected]> 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
> <[email protected]>
>
>
>
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
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