The IBM Integrity Measurement Architecture (IMA) is being submitted for
inclusion by Reiner Sailer. The IMA is a LSM that uses TPM
functionality. This patch provides and internal kernel interface for
IMA and any other subsystems to access TPM functionality. A subsystem
first requests the chip it is trying to access with the tpm_chip_lookup
function and then submitts TPM commands to that chip with the tpm_transmit
function. For security reasons IMA needs to be built into the
kernel, in order for the TPM driver to be available during IMA
initialization the module_init is replaced with an fs_initcall when the
driver is built into the kernel.
This patch should apply against 2.6.12-rc4-mm2 plus the patch I submitted
on May 16 to remove the unnecessary lpc initialization stuff.
Signed-off-by: Kylene Hall <[email protected]>
---
--- linux-2.6.12-rc4/drivers/char/tpm/tpm.c.orig 2005-05-17 14:15:53.000000000 -0500
+++ linux-2.6.12-rc4/drivers/char/tpm/tpm.c 2005-05-17 14:18:56.000000000 -0500
@@ -50,15 +50,35 @@ static void user_reader_timeout(unsigned
}
/*
+ * This function should be used by other kernel subsystems attempting to use the tpm through the tpm_transmit interface.
+ * A call to this function will return the chip structure corresponding to the TPM you are looking for that can then be sent with your command to tpm_transmit.
+ * Passing 0 as the argument corresponds to /dev/tpm0 and thus the first and probably primary TPM on the system. Passing 1 corresponds to /dev/tpm1 and the next TPM discovered. If a TPM with the given chip_num does not exist NULL will be returned.
+ */
+struct tpm_chip* tpm_chip_lookup(int chip_num)
+{
+
+ struct tpm_chip *pos;
+ list_for_each_entry(pos, &tpm_chip_list, list)
+ if (pos->dev_num == chip_num)
+ return pos;
+
+ return NULL;
+
+}
+
+/*
* Internal kernel interface to transmit TPM commands
*/
-static ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
+ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
size_t bufsiz)
{
ssize_t rc;
u32 count;
unsigned long stop;
+ if ( !chip )
+ return -ENODEV;
+
count = be32_to_cpu(*((__be32 *) (buf + 2)));
if (count == 0)
@@ -110,6 +130,7 @@ out:
up(&chip->tpm_mutex);
return rc;
}
+EXPORT_SYMBOL_GPL(tpm_transmit);
#define TPM_DIGEST_SIZE 20
#define CAP_PCR_RESULT_SIZE 18
--- linux-2.6.12-rc3-ima/drivers/char/tpm/tpm.h 2005-04-20 19:03:13.000000000 -0500
+++ linux-2.6.12-rc3-ima/drivers/char/tpm/tpm.h 2005-05-02 14:08:44.000000000 -0500
@@ -91,3 +91,8 @@ extern ssize_t tpm_read(struct file *, c
extern void __devexit tpm_remove(struct pci_dev *);
extern int tpm_pm_suspend(struct pci_dev *, pm_message_t);
extern int tpm_pm_resume(struct pci_dev *);
+
+/* internal kernel interface */
+extern ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
+ size_t bufsiz);
+extern struct tpm_chip *tpm_chip_lookup(int chip_num);
--- linux-2.6.12-rc3-ima/drivers/char/tpm/tpm_atmel.c 2005-04-20 19:03:13.000000000 -0500
+++ linux-2.6.12-rc3-ima/drivers/char/tpm/tpm_atmel.c 2005-05-02 14:06:35.000000000 -0500
@@ -207,7 +207,11 @@ static void __exit cleanup_atmel(void)
pci_unregister_driver(&atmel_pci_driver);
}
+#ifdef MODULE
module_init(init_atmel);
+#else
+fs_initcall(init_atmel);
+#endif
module_exit(cleanup_atmel);
MODULE_AUTHOR("Leendert van Doorn ([email protected])");
--- linux-2.6.12-rc3-ima/drivers/char/tpm/tpm_nsc.c 2005-04-20 19:03:13.000000000 -0500
+++ linux-2.6.12-rc3-ima/drivers/char/tpm/tpm_nsc.c 2005-05-02 14:09:34.000000000 -0500
@@ -364,7 +364,11 @@ static void __exit cleanup_nsc(void)
pci_unregister_driver(&nsc_pci_driver);
}
+#ifdef MODULE
module_init(init_nsc);
+#else
+fs_initcall(init_nsc);
+#endif
module_exit(cleanup_nsc);
MODULE_AUTHOR("Leendert van Doorn ([email protected])");
Why are you using LSM for this?
LSM should be used for comprehensive access control frameworks which
significantly enhance or even replace existing Unix DAC security.
We're going to end up with a proliferation of arbitrary security features
lacking an overall architectural view (I've written about this before,
see http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/0300.html).
I think it would be better to implement this directly.
- James
--
James Morris
<[email protected]>
James Morris <[email protected]> wrote on 05/20/2005 10:56:20 AM:
> Why are you using LSM for this?
>
> LSM should be used for comprehensive access control frameworks which
> significantly enhance or even replace existing Unix DAC security.
I see LSM is framework for security. IMA is an architecture that
enforces access control in a different way than SELinux. IMA guarantees
that executable content is measured and accounted for before
it is loaded and can access (and possibly corrupt) system resources.
> We're going to end up with a proliferation of arbitrary security
features
> lacking an overall architectural view (I've written about this before,
> see http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/0300.html).
>
> I think it would be better to implement this directly.
The reason IMA is implemented as a Linux security module is that the LSM
interface allows the least intrusive implementation with regard to existing
kernel code. IMA is non-intrusive (its hooks return always nicely) and
implements security guarantees that are orthogonal to those of, e.g.,
SELinux. Interactions with other LSM users are not expected. Experience
shows that maintining IMA as LSM is simple.
There is no reason though why IMA must use LSM; however, it seems not the
straightforward solution to replicate LSM hooks that are already
available.
>
> - James
> --
> James Morris
> <[email protected]>
>
>
Thanks
Reiner
On Fri, 20 May 2005, Reiner Sailer wrote:
> > Why are you using LSM for this?
> >
> > LSM should be used for comprehensive access control frameworks which
> > significantly enhance or even replace existing Unix DAC security.
>
> I see LSM is framework for security. IMA is an architecture that
> enforces access control in a different way than SELinux. IMA guarantees
> that executable content is measured and accounted for before
> it is loaded and can access (and possibly corrupt) system resources.
LSM is an access control framework. Your (few) LSM hooks always return
zero, and don't enforce access control at all. You even have a separate
measurement hook for modules.
I suggest implementing all of your code via distinct measurement hooks, so
measurement becomes a distinct and well defined security entity within the
kernel.
LSM should not be used just because it has a few hooks in the right place
for your code.
- James
--
James Morris
<[email protected]>
James Morris <[email protected]> wrote on 05/20/2005 04:32:58 PM:
> On Fri, 20 May 2005, Reiner Sailer wrote:
>
> > > Why are you using LSM for this?
> > >
> > > LSM should be used for comprehensive access control frameworks which
> > > significantly enhance or even replace existing Unix DAC security.
> >
> > I see LSM is framework for security. IMA is an architecture that
> > enforces access control in a different way than SELinux. IMA guarantees
> > that executable content is measured and accounted for before
> > it is loaded and can access (and possibly corrupt) system resources.
>
> LSM is an access control framework. Your (few) LSM hooks always return
> zero, and don't enforce access control at all. You even have a separate
> measurement hook for modules.
>
> I suggest implementing all of your code via distinct measurement hooks, so
> measurement becomes a distinct and well defined security entity within the
> kernel.
This is certainly possible. This means that there will be 5 more hooks
(such as the one in kernel/module.c, see PATCH 4 of 4).
If the kernel maintainers are in favor of this approach, then there is not
much that stands against this.
> LSM should not be used just because it has a few hooks in the right place
> for your code.
>
>
> - James
> --
> James Morris
> <[email protected]>
>
>
>
>
Thanks
Reiner
On Fri, May 20, 2005 at 04:41:23PM -0400, Reiner Sailer wrote:
> James Morris <[email protected]> wrote on 05/20/2005 04:32:58 PM:
> > On Fri, 20 May 2005, Reiner Sailer wrote:
> >
> > > > Why are you using LSM for this?
> > > >
> > > > LSM should be used for comprehensive access control frameworks which
> > > > significantly enhance or even replace existing Unix DAC security.
> > >
> > > I see LSM is framework for security. IMA is an architecture that
> > > enforces access control in a different way than SELinux. IMA guarantees
> > > that executable content is measured and accounted for before
> > > it is loaded and can access (and possibly corrupt) system resources.
> >
> > LSM is an access control framework. Your (few) LSM hooks always return
> > zero, and don't enforce access control at all. You even have a separate
> > measurement hook for modules.
> >
> > I suggest implementing all of your code via distinct measurement hooks, so
> > measurement becomes a distinct and well defined security entity within the
> > kernel.
>
> This is certainly possible. This means that there will be 5 more hooks
> (such as the one in kernel/module.c, see PATCH 4 of 4).
>
> If the kernel maintainers are in favor of this approach, then there is not
> much that stands against this.
Yes, and it will force you to justify those hooks :)
Good luck,
greg k-h