On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:
[..]
> > Also I am assuming that from signed initramfs, keys will be loaded in
> > appropriate keyrings and then keyring will be locked so that any
> > tools from unsigned initramfs can not load additional keys.
> >
>
> Exactly like that.
Dmitry,
[ Following up on this thread after a very long time ]
I was thinking about this point that keys can be loaded from signed
initramfs. But how is it better than embedding the keys in kernel the
way we do for module signing and lock down ima keyring before control
is passed to initramfs.
Reason being, that anyway a user can not put its own keys in signed
initramfs. Signed initramfs will be shipped by distribution. So then
it does not matter whether distribution's keys are embedded in the
kernel or are loaded from signed initramfs.
Thanks
Vivek
On Fri, 2013-04-05 at 09:50 -0400, Vivek Goyal wrote:
> On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:
>
> [..]
> > > Also I am assuming that from signed initramfs, keys will be loaded in
> > > appropriate keyrings and then keyring will be locked so that any
> > > tools from unsigned initramfs can not load additional keys.
> > >
> >
> > Exactly like that.
>
> Dmitry,
>
> [ Following up on this thread after a very long time ]
>
> I was thinking about this point that keys can be loaded from signed
> initramfs. But how is it better than embedding the keys in kernel the
> way we do for module signing and lock down ima keyring before control
> is passed to initramfs.
>
> Reason being, that anyway a user can not put its own keys in signed
> initramfs. Signed initramfs will be shipped by distribution. So then
> it does not matter whether distribution's keys are embedded in the
> kernel or are loaded from signed initramfs.
Although both the early initramfs and the kernel are signed, building
the keys into the kernel implies a static set of predefined public keys,
while the initramfs could load, in addition to the distro keys, keys
from the UEFI databases. (Refer to James Bottomley's post on efivarfs.)
If distro's would sign such an early initramfs, it would allow users to
add their own keys in a safe and secure manner, without requiring them
to rebuild the kernel.
Mimi
On Mon, Apr 08, 2013 at 03:43:49PM -0400, Mimi Zohar wrote:
> On Fri, 2013-04-05 at 09:50 -0400, Vivek Goyal wrote:
> > On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:
> >
> > [..]
> > > > Also I am assuming that from signed initramfs, keys will be loaded in
> > > > appropriate keyrings and then keyring will be locked so that any
> > > > tools from unsigned initramfs can not load additional keys.
> > > >
> > >
> > > Exactly like that.
> >
> > Dmitry,
> >
> > [ Following up on this thread after a very long time ]
> >
> > I was thinking about this point that keys can be loaded from signed
> > initramfs. But how is it better than embedding the keys in kernel the
> > way we do for module signing and lock down ima keyring before control
> > is passed to initramfs.
> >
> > Reason being, that anyway a user can not put its own keys in signed
> > initramfs. Signed initramfs will be shipped by distribution. So then
> > it does not matter whether distribution's keys are embedded in the
> > kernel or are loaded from signed initramfs.
>
> Although both the early initramfs and the kernel are signed, building
> the keys into the kernel implies a static set of predefined public keys,
> while the initramfs could load, in addition to the distro keys, keys
> from the UEFI databases.
Kernel already loads all the keys from UEFI database and MOK into module
keyring.
So that can be true for IMA too. A user can add its keys to UEFI database
or MOK and reboot the system and those keys should show up in kernel
keyring.
In addition any keys embedded in kernel at build time will be loaded too.
> (Refer to James Bottomley's post on efivarfs.)
Are you referring to following link.
http://blog.hansenpartnership.com/efitools-1-4-with-linux-key-manipulation-utilities-released/
This one seems to be talking about tools for adding your own keys to
UEFI database if one has PK and KEK.
> If distro's would sign such an early initramfs, it would allow users to
> add their own keys in a safe and secure manner, without requiring them
> to rebuild the kernel.
>
Sorry, I did not understand this part. Even if user adds its own keys
in UEFI database (using efivarfs filesystem), it does not require
rebuiling kernel. Over next reboot these keys should show up in kernel
keyring. So does not look like we will gain anything by creating a signed
initramfs.
Thanks
Vivek
On Mon, Apr 8, 2013 at 4:09 PM, Vivek Goyal <[email protected]> wrote:
> On Mon, Apr 08, 2013 at 03:43:49PM -0400, Mimi Zohar wrote:
>> On Fri, 2013-04-05 at 09:50 -0400, Vivek Goyal wrote:
>> > On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:
>> >
>> > [..]
>> > > > Also I am assuming that from signed initramfs, keys will be loaded in
>> > > > appropriate keyrings and then keyring will be locked so that any
>> > > > tools from unsigned initramfs can not load additional keys.
>> > > >
>> > >
>> > > Exactly like that.
>> >
>> > Dmitry,
>> >
>> > [ Following up on this thread after a very long time ]
>> >
>> > I was thinking about this point that keys can be loaded from signed
>> > initramfs. But how is it better than embedding the keys in kernel the
>> > way we do for module signing and lock down ima keyring before control
>> > is passed to initramfs.
>> >
>> > Reason being, that anyway a user can not put its own keys in signed
>> > initramfs. Signed initramfs will be shipped by distribution. So then
>> > it does not matter whether distribution's keys are embedded in the
>> > kernel or are loaded from signed initramfs.
>>
>> Although both the early initramfs and the kernel are signed, building
>> the keys into the kernel implies a static set of predefined public keys,
>> while the initramfs could load, in addition to the distro keys, keys
>> from the UEFI databases.
>
> Kernel already loads all the keys from UEFI database and MOK into module
> keyring.
Small point of order: there are patches to allow the kernel to do this.
None of those patches are upstream.
josh
On Mon, Apr 08, 2013 at 04:17:56PM -0400, Josh Boyer wrote:
[..]
> >> > I was thinking about this point that keys can be loaded from signed
> >> > initramfs. But how is it better than embedding the keys in kernel the
> >> > way we do for module signing and lock down ima keyring before control
> >> > is passed to initramfs.
> >> >
> >> > Reason being, that anyway a user can not put its own keys in signed
> >> > initramfs. Signed initramfs will be shipped by distribution. So then
> >> > it does not matter whether distribution's keys are embedded in the
> >> > kernel or are loaded from signed initramfs.
> >>
> >> Although both the early initramfs and the kernel are signed, building
> >> the keys into the kernel implies a static set of predefined public keys,
> >> while the initramfs could load, in addition to the distro keys, keys
> >> from the UEFI databases.
> >
> > Kernel already loads all the keys from UEFI database and MOK into module
> > keyring.
>
> Small point of order: there are patches to allow the kernel to do this.
> None of those patches are upstream.
Ok, thanks Josh. We had been talking about copying all the UEFI keys
(including dbx) and MOK keys, so I assumed that patches already went in.
So assuming all that will go in kernel (as it is required for module
signature too), does not look like we will benefit from signed initramfs.
Thanks
Vivek
On Tue, 2013-04-09 at 10:38 -0400, Vivek Goyal wrote:
> On Mon, Apr 08, 2013 at 04:17:56PM -0400, Josh Boyer wrote:
>
> [..]
> > >> > I was thinking about this point that keys can be loaded from signed
> > >> > initramfs. But how is it better than embedding the keys in kernel the
> > >> > way we do for module signing and lock down ima keyring before control
> > >> > is passed to initramfs.
> > >> >
> > >> > Reason being, that anyway a user can not put its own keys in signed
> > >> > initramfs. Signed initramfs will be shipped by distribution. So then
> > >> > it does not matter whether distribution's keys are embedded in the
> > >> > kernel or are loaded from signed initramfs.
> > >>
> > >> Although both the early initramfs and the kernel are signed, building
> > >> the keys into the kernel implies a static set of predefined public keys,
> > >> while the initramfs could load, in addition to the distro keys, keys
> > >> from the UEFI databases.
> > >
> > > Kernel already loads all the keys from UEFI database and MOK into module
> > > keyring.
> >
> > Small point of order: there are patches to allow the kernel to do this.
> > None of those patches are upstream.
>
> Ok, thanks Josh. We had been talking about copying all the UEFI keys
> (including dbx) and MOK keys, so I assumed that patches already went in.
>
> So assuming all that will go in kernel (as it is required for module
> signature too), does not look like we will benefit from signed initramfs.
The module keyring is a special case. Loading these keys from the
kernel and, presumably, locking the keyring is probably fine. In the
case of IMA, however, files will be signed by any number of package
owners. If the _ima keyring is locked by the kernel, how would you add
these other keys?
thanks,
Mimi
On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
[..]
> The module keyring is a special case. Loading these keys from the
> kernel and, presumably, locking the keyring is probably fine. In the
> case of IMA, however, files will be signed by any number of package
> owners. If the _ima keyring is locked by the kernel, how would you add
> these other keys?
Who are package owners here. IOW, in typical IMA setup, where are the keys
and when are these keys loaded in ima keyring?
If we trust root and keys can be loaded any time later, then signed
initramfs will not solve the problem either.
So this boils down to again not trusting root. So secureboot will not
trust root and IMA does.
May be we need an additional IMA keyring which gets locked by kernel
(like module keyring). And during signing, we need to encode keyring
info in file signatuer. IMA will parse keyring info and try to verify
signature against that specified keyring.
/sbin/kexec signing can happen in such a way that we tell IMA to verify
against this locked keyring say, ima_kernel.
And in regular ima keyring, root can continue to load its own keys in
usual way even in secureboot mode.
Just that sys_kexec() will have to call into IMA to make sure that
/sbin/kexec's integrity was verified using keys in ima_kernel keyring
and not using keys in _ima keyring.
IOW, apart from integrity results, we will have to store the keyring
info too in results which should be queryable by the client. And then
client can decide how to interpret integrity results.
Or we can just export the APIs from IMA (which don't do any caching) and
client can specify keyring to verify against as a parameter.
Thoughts?
Thanks
Vivek
On Wed, 2013-04-10 at 15:42 -0400, Vivek Goyal wrote:
> On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
>
> [..]
> > The module keyring is a special case. Loading these keys from the
> > kernel and, presumably, locking the keyring is probably fine. In the
> > case of IMA, however, files will be signed by any number of package
> > owners. If the _ima keyring is locked by the kernel, how would you add
> > these other keys?
>
> Who are package owners here. IOW, in typical IMA setup, where are the keys
> and when are these keys loaded in ima keyring?
Suppose I install third party packages not signed by the distro, but by
the package owner (eg. google, rpmfusion, ...). Not only does the
package signature need to be verified on installation, but the files
need to be installed with signatures. For IMA to enforce file
integrity, the package owner's public key needs to be added to the _ima
keyring.
> If we trust root and keys can be loaded any time later, then signed
> initramfs will not solve the problem either.
Locking the keyring in the kernel will limit the set of permitted keys
to only those specified in UEFI db or builtin. Locking the keyring in
the "early" initramfs, will allow the system owner, whose key is in the
UEFI db, to specify additional keys, such as those for third party
packages. Not all public keys belong in the UEFI db.
Mimi
Hello,
(in plain text)
I respond to the original question of this thread.
signed initramfs allows not only to add keys to the keyrings but
perform other initialization,
which requires user-space.
Keys can be embedded into the kernel. This is fine.
Regards
- Dmitry
On Thu, Apr 11, 2013 at 12:05 AM, Mimi Zohar <[email protected]> wrote:
> On Wed, 2013-04-10 at 15:42 -0400, Vivek Goyal wrote:
>> On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
>>
>> [..]
>> > The module keyring is a special case. Loading these keys from the
>> > kernel and, presumably, locking the keyring is probably fine. In the
>> > case of IMA, however, files will be signed by any number of package
>> > owners. If the _ima keyring is locked by the kernel, how would you add
>> > these other keys?
>>
>> Who are package owners here. IOW, in typical IMA setup, where are the keys
>> and when are these keys loaded in ima keyring?
>
> Suppose I install third party packages not signed by the distro, but by
> the package owner (eg. google, rpmfusion, ...). Not only does the
> package signature need to be verified on installation, but the files
> need to be installed with signatures. For IMA to enforce file
> integrity, the package owner's public key needs to be added to the _ima
> keyring.
>
>> If we trust root and keys can be loaded any time later, then signed
>> initramfs will not solve the problem either.
>
> Locking the keyring in the kernel will limit the set of permitted keys
> to only those specified in UEFI db or builtin. Locking the keyring in
> the "early" initramfs, will allow the system owner, whose key is in the
> UEFI db, to specify additional keys, such as those for third party
> packages. Not all public keys belong in the UEFI db.
>
> Mimi
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 10, 2013 at 05:05:22PM -0400, Mimi Zohar wrote:
> On Wed, 2013-04-10 at 15:42 -0400, Vivek Goyal wrote:
> > On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
> >
> > [..]
> > > The module keyring is a special case. Loading these keys from the
> > > kernel and, presumably, locking the keyring is probably fine. In the
> > > case of IMA, however, files will be signed by any number of package
> > > owners. If the _ima keyring is locked by the kernel, how would you add
> > > these other keys?
> >
> > Who are package owners here. IOW, in typical IMA setup, where are the keys
> > and when are these keys loaded in ima keyring?
>
> Suppose I install third party packages not signed by the distro, but by
> the package owner (eg. google, rpmfusion, ...). Not only does the
> package signature need to be verified on installation, but the files
> need to be installed with signatures. For IMA to enforce file
> integrity, the package owner's public key needs to be added to the _ima
> keyring.
Ok, got it.
>
> > If we trust root and keys can be loaded any time later, then signed
> > initramfs will not solve the problem either.
>
> Locking the keyring in the kernel will limit the set of permitted keys
> to only those specified in UEFI db or builtin. Locking the keyring in
> the "early" initramfs, will allow the system owner, whose key is in the
> UEFI db, to specify additional keys, such as those for third party
> packages. Not all public keys belong in the UEFI db.
Ok, so third party public key you don't want to add in UEFI db. Instead
platform owner (whose key is in UEFI db) will regenerate initrafs and
sign it.
So above use case is primarily for user space files and verifying its
integrity and IMA keyring is used for that. secureboot does not require
IMA keyring to be locked as none of that code runs at ring0.
This locking requirement of IMA keyring is coming in only because we are
trying to also verify the integrity of a process who will load code which
runs at ring0.
So how do you like the idea of using another keyring (say system keyring)
for this purpose and what keyring to use integrity of a file can be
encoded in file signature.
This is something similar to INTEGRITY_KEYRING_MODULE keyring for modules.
(Though I don't see this code fully hooked up yet).
Or, given the fact that module signature and here /sbin/kexec verification
will make use of similar keys, we can create a system keyring, make module
code make use of that keyring. And IMA code can make use of that keyring
too if a file's digital signature indicates so.
Thanks
Vivek
On Thu, 2013-04-11 at 10:52 -0400, Vivek Goyal wrote:
> On Wed, Apr 10, 2013 at 05:05:22PM -0400, Mimi Zohar wrote:
> > On Wed, 2013-04-10 at 15:42 -0400, Vivek Goyal wrote:
> > > On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
> > >
> > > [..]
> > > > The module keyring is a special case. Loading these keys from the
> > > > kernel and, presumably, locking the keyring is probably fine. In the
> > > > case of IMA, however, files will be signed by any number of package
> > > > owners. If the _ima keyring is locked by the kernel, how would you add
> > > > these other keys?
> > >
> > > Who are package owners here. IOW, in typical IMA setup, where are the keys
> > > and when are these keys loaded in ima keyring?
> >
> > Suppose I install third party packages not signed by the distro, but by
> > the package owner (eg. google, rpmfusion, ...). Not only does the
> > package signature need to be verified on installation, but the files
> > need to be installed with signatures. For IMA to enforce file
> > integrity, the package owner's public key needs to be added to the _ima
> > keyring.
>
> Ok, got it.
>
> >
> > > If we trust root and keys can be loaded any time later, then signed
> > > initramfs will not solve the problem either.
> >
> > Locking the keyring in the kernel will limit the set of permitted keys
> > to only those specified in UEFI db or builtin. Locking the keyring in
> > the "early" initramfs, will allow the system owner, whose key is in the
> > UEFI db, to specify additional keys, such as those for third party
> > packages. Not all public keys belong in the UEFI db.
>
> Ok, so third party public key you don't want to add in UEFI db. Instead
> platform owner (whose key is in UEFI db) will regenerate initrafs and
> sign it.
>
> So above use case is primarily for user space files and verifying its
> integrity and IMA keyring is used for that. secureboot does not require
> IMA keyring to be locked as none of that code runs at ring0.
>
> This locking requirement of IMA keyring is coming in only because we are
> trying to also verify the integrity of a process who will load code which
> runs at ring0.
>
> So how do you like the idea of using another keyring (say system keyring)
> for this purpose and what keyring to use integrity of a file can be
> encoded in file signature.
>
> This is something similar to INTEGRITY_KEYRING_MODULE keyring for modules.
> (Though I don't see this code fully hooked up yet).
>
> Or, given the fact that module signature and here /sbin/kexec verification
> will make use of similar keys, we can create a system keyring, make module
> code make use of that keyring. And IMA code can make use of that keyring
> too if a file's digital signature indicates so.
Sounds good to me!
thanks,
Mimi