| Message ID | 1363642353-30749-1-git-send-email-matthew.garrett@nebula.com |
|---|---|
| State | Not Applicable |
| Headers | show |
On Mon, 18 Mar 2013, Matthew Garrett wrote:
> This patch introduces CAP_COMPROMISE_KERNEL.
I'd like to see this named CAP_MODIFY_KERNEL, which is more accurate and
less emotive. Otherwise I think core kernel developers will be scratching
their head over where to sprinkle this.
Apart from that, I like the idea, especially when it's wired up to MAC
security.
On lun., 2013-03-18 at 17:32 -0400, Matthew Garrett wrote: > This patch introduces CAP_COMPROMISE_KERNEL. Holding this capability > indicates that a process is empowered to perform tasks that may result > in > modification of the running kernel. While aimed at handling the > specific > use-case of Secure Boot, it is generalisable to any other environment > where > permitting userspace to modify the kernel is undesirable. About that, did someone looked at the way securelevel(7) is handled on OpenBSD? This is more or less the same thing, where there's a desire to distinguish uid 0 from ring0. They're not using a capability but more a global state which allows more or less stuff depending on the value (securelevel=-1 to securelevel=2). Regards,
On 03/18/2013 02:32 PM, Matthew Garrett wrote: > > This means we can return our focus to the kernel. There's currently a number > of kernel interfaces that permit privileged userspace to modify the running > kernel. These are currently protected by CAP_SYS_RAWIO, but unfortunately > the semantics of this capability are poorly defined and it now covers a large > superset of the desired behaviour. > ... except it doesn't. Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the possibility of compromising the kernel, because they let device drivers be bypassed, which means arbitrary DMA, which means you have everything. Now, a lot of the abuses of CAP_SYS_RAWIO have clearly been added by people who had *no bloody clue* what that capability meant, but it really doesn't change the fact that pretty much if you have CAP_SYS_RAWIO you have the machine. So just reject CAP_SYS_RAWIO. -hpa
On 03/18/2013 09:47 PM, James Morris wrote: > On Mon, 18 Mar 2013, Matthew Garrett wrote: > >> This patch introduces CAP_COMPROMISE_KERNEL. > > I'd like to see this named CAP_MODIFY_KERNEL, which is more accurate and > less emotive. Otherwise I think core kernel developers will be scratching > their head over where to sprinkle this. > > Apart from that, I like the idea, especially when it's wired up to MAC > security. The wiring up to MAC security is a nice touch. -hpa
On 03/19/2013 06:02 PM, H. Peter Anvin wrote: > > Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the possibility > of compromising the kernel, because they let device drivers be bypassed, > which means arbitrary DMA, which means you have everything. > Well, *unless* you have an iommu that you *actually know* is protecting you. -hpa
T24gVHVlLCAyMDEzLTAzLTE5IGF0IDE4OjAyIC0wNzAwLCBILiBQZXRlciBBbnZpbiB3cm90ZToN Cg0KPiBMb29raW5nIGF0IGl0IGluIGRldGFpbCwgRVZFUllUSElORyBpbiBDQVBfU1lTX1JBV0lP IGhhcyB0aGUgcG9zc2liaWxpdHkNCj4gb2YgY29tcHJvbWlzaW5nIHRoZSBrZXJuZWwsIGJlY2F1 c2UgdGhleSBsZXQgZGV2aWNlIGRyaXZlcnMgYmUgYnlwYXNzZWQsDQo+IHdoaWNoIG1lYW5zIGFy Yml0cmFyeSBETUEsIHdoaWNoIG1lYW5zIHlvdSBoYXZlIGV2ZXJ5dGhpbmcuDQoNCkhhdmluZyBj aGVja2VkIGFnYWluLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdHJ1ZS4gVGhlIG1vc3Qgb2J2aW91 cyBjYXNlDQppcyBsaWJhdGEsIHdoaWNoIHVzZXMgQ0FQX1NZU19SQVdJTyB0byBsaW1pdCB0aGUg YWJpbGl0eSB0byBzZW5kIHJhdyBBVEENCmNvbW1hbmRzLiBCZWluZyBhYmxlIHRvIGRvIHNvIGNs ZWFybHkgcGVybWl0cyB1c2Vyc3BhY2UgdG8gYXZvaWQgYW55DQpraW5kIG9mIHBvbGljeSB0aGUg dmZzIGhhcyBwdXQgaW4gcGxhY2UsIGJ1dCB0aGVyZSdzIG5vIG9idmlvdXMgd2F5IGZvcg0KdGhl IHVzZXIgdG8gbW9kaWZ5IHRoZSBydW5uaW5nIGtlcm5lbC4gQXJlIHlvdSBzdWdnZXN0aW5nIHRo YXQgcmVtb3ZpbmcNCnRoZSBDQVBfU1lTX1JBV0lPIGNoZWNrIHRoZXJlIHdvdWxkIGJlIHJlYXNv bmFibGU/DQoNCi0tIA0KTWF0dGhldyBHYXJyZXR0IHwgbWpnNTlAc3JjZi51Y2FtLm9yZw0K -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CAP_SYS_RAWIO is definitely inappropriate there. Matthew Garrett <matthew.garrett@nebula.com> wrote: >On Tue, 2013-03-19 at 18:02 -0700, H. Peter Anvin wrote: > >> Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the >possibility >> of compromising the kernel, because they let device drivers be >bypassed, >> which means arbitrary DMA, which means you have everything. > >Having checked again, I don't think this is true. The most obvious case >is libata, which uses CAP_SYS_RAWIO to limit the ability to send raw >ATA >commands. Being able to do so clearly permits userspace to avoid any >kind of policy the vfs has put in place, but there's no obvious way for >the user to modify the running kernel. Are you suggesting that removing >the CAP_SYS_RAWIO check there would be reasonable?
T24gV2VkLCAyMDEzLTAzLTIwIGF0IDA4OjAzIC0wNzAwLCBILiBQZXRlciBBbnZpbiB3cm90ZToN Cj4gQ0FQX1NZU19SQVdJTyBpcyBkZWZpbml0ZWx5IGluYXBwcm9wcmlhdGUgdGhlcmUuDQoNCk9r LiBIb3cgZG8gd2UgZml4IHRoYXQgd2l0aG91dCBicmVha2luZyB1c2Vyc3BhY2UgdGhhdCBleHBl Y3RzDQpDQVBfU1lTX1JBV0lPIHRvIGJlIHN1ZmZpY2llbnQ/DQoNCi0tIA0KTWF0dGhldyBHYXJy ZXR0IHwgbWpnNTlAc3JjZi51Y2FtLm9yZw0K -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2013-03-19 at 15:47 +1100, James Morris wrote: > On Mon, 18 Mar 2013, Matthew Garrett wrote: > > > This patch introduces CAP_COMPROMISE_KERNEL. > > I'd like to see this named CAP_MODIFY_KERNEL, which is more accurate and > less emotive. Otherwise I think core kernel developers will be scratching > their head over where to sprinkle this. > > Apart from that, I like the idea, especially when it's wired up to MAC > security. Matthrew, perhaps you could clarify whether this will be tied to MAC security. Based on the kexec thread, I'm under the impression that is not the intention, or at least not for kexec. As root isn't trusted, neither is the boot command line, nor any policy that is loaded by root, including those for MAC. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/20/2013 08:14 AM, Matthew Garrett wrote: > On Wed, 2013-03-20 at 08:03 -0700, H. Peter Anvin wrote: >> CAP_SYS_RAWIO is definitely inappropriate there. > > Ok. How do we fix that without breaking userspace that expects > CAP_SYS_RAWIO to be sufficient? > I don't think we can to some way, because when what you have is fundamentally broken, it's hard to fix. However, it is extremely likely that the number of affected applications is vanishingly small. There probably are a handful of apps that do this, and I wouldn't be surprised if most of them simply run as root. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
T24gV2VkLCAyMDEzLTAzLTIwIGF0IDEyOjQxIC0wNDAwLCBNaW1pIFpvaGFyIHdyb3RlOg0KDQo+ IE1hdHRocmV3LCBwZXJoYXBzIHlvdSBjb3VsZCBjbGFyaWZ5IHdoZXRoZXIgdGhpcyB3aWxsIGJl IHRpZWQgdG8gTUFDDQo+IHNlY3VyaXR5LiAgQmFzZWQgb24gdGhlIGtleGVjIHRocmVhZCwgSSdt IHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgaXMNCj4gbm90IHRoZSBpbnRlbnRpb24sIG9yIGF0 IGxlYXN0IG5vdCBmb3Iga2V4ZWMuICBBcyByb290IGlzbid0IHRydXN0ZWQsDQo+IG5laXRoZXIg aXMgdGhlIGJvb3QgY29tbWFuZCBsaW5lLCBub3IgYW55IHBvbGljeSB0aGF0IGlzIGxvYWRlZCBi eSByb290LA0KPiBpbmNsdWRpbmcgdGhvc2UgZm9yIE1BQy4NCg0KVGhlIHdvcmsgZG9uZSBvbiBz aWduZWQgaW5pdHJhbWZzIGZyYWdtZW50cyB3b3VsZCBzZWVtIHRvIGJlIHRoZSBiZXN0DQpvcHRp b24gaGVyZSBzbyBmYXI/DQoNCi0tIA0KTWF0dGhldyBHYXJyZXR0IHwgbWpnNTlAc3JjZi51Y2Ft Lm9yZw0K -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2013-03-20 at 16:49 +0000, Matthew Garrett wrote: > On Wed, 2013-03-20 at 12:41 -0400, Mimi Zohar wrote: > > > Matthrew, perhaps you could clarify whether this will be tied to MAC > > security. Based on the kexec thread, I'm under the impression that is > > not the intention, or at least not for kexec. As root isn't trusted, > > neither is the boot command line, nor any policy that is loaded by root, > > including those for MAC. > > The work done on signed initramfs fragments would seem to be the best > option here so far? Sorry, I'm not sure to which work you're referring. If you're referring to Dmitry's "initramfs with digital signature protection" patches, then we're speaking about enforcing integrity, not MAC security. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2013-03-20 at 14:01 -0400, Mimi Zohar wrote: > Sorry, I'm not sure to which work you're referring. If you're referring > to Dmitry's "initramfs with digital signature protection" patches, then > we're speaking about enforcing integrity, not MAC security. Well, in the absence of hardcoded in-kernel policy, there needs to be some mechanism for ensuring the integrity of a policy. Shipping a signed policy initramfs fragment and having any Secure Boot bootloaders pass a flag in bootparams indicating that the kernel should panic if that fragment isn't present would seem to be the easiest way of doing that. Or have I misunderstood the question? -- Matthew Garrett | mjg59@srcf.ucam.org
On Wed, 2013-03-20 at 18:12 +0000, Matthew Garrett wrote: > On Wed, 2013-03-20 at 14:01 -0400, Mimi Zohar wrote: > > > Sorry, I'm not sure to which work you're referring. If you're referring > > to Dmitry's "initramfs with digital signature protection" patches, then > > we're speaking about enforcing integrity, not MAC security. > > Well, in the absence of hardcoded in-kernel policy, there needs to be > some mechanism for ensuring the integrity of a policy. Shipping a signed > policy initramfs fragment and having any Secure Boot bootloaders pass a > flag in bootparams indicating that the kernel should panic if that > fragment isn't present would seem to be the easiest way of doing that. > Or have I misunderstood the question? Ok, I was confused by the term "fragmented" initramfs. So once you have verified the "early" fragmented initramfs signature, this initramfs will load the "trusted" public keys and could also load the MAC policy. (I realize that dracut is currently loading the MAC policy, not the initramfs.) The MAC policy would then be trusted, right? Could we then use the LSM labels for defining an integrity policy for kexec? thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2013-03-20 at 15:16 -0400, Mimi Zohar wrote: > On Wed, 2013-03-20 at 18:12 +0000, Matthew Garrett wrote: > > Well, in the absence of hardcoded in-kernel policy, there needs to be > > some mechanism for ensuring the integrity of a policy. Shipping a signed > > policy initramfs fragment and having any Secure Boot bootloaders pass a > > flag in bootparams indicating that the kernel should panic if that > > fragment isn't present would seem to be the easiest way of doing that. > > Or have I misunderstood the question? > > Ok, I was confused by the term "fragmented" initramfs. So once you have > verified the "early" fragmented initramfs signature, this initramfs will > load the "trusted" public keys and could also load the MAC policy. (I > realize that dracut is currently loading the MAC policy, not the > initramfs.) The MAC policy would then be trusted, right? Could we then > use the LSM labels for defining an integrity policy for kexec? Right, that'd be the rough idea. Any further runtime policy updates would presumably need to be signed with a trusted key. -- Matthew Garrett | mjg59@srcf.ucam.org
On Wed, 2013-03-20 at 20:37 +0000, Matthew Garrett wrote: > On Wed, 2013-03-20 at 15:16 -0400, Mimi Zohar wrote: > > On Wed, 2013-03-20 at 18:12 +0000, Matthew Garrett wrote: > > > Well, in the absence of hardcoded in-kernel policy, there needs to be > > > some mechanism for ensuring the integrity of a policy. Shipping a signed > > > policy initramfs fragment and having any Secure Boot bootloaders pass a > > > flag in bootparams indicating that the kernel should panic if that > > > fragment isn't present would seem to be the easiest way of doing that. > > > Or have I misunderstood the question? > > > > Ok, I was confused by the term "fragmented" initramfs. So once you have > > verified the "early" fragmented initramfs signature, this initramfs will > > load the "trusted" public keys and could also load the MAC policy. (I > > realize that dracut is currently loading the MAC policy, not the > > initramfs.) The MAC policy would then be trusted, right? Could we then > > use the LSM labels for defining an integrity policy for kexec? > > Right, that'd be the rough idea. Any further runtime policy updates > would presumably need to be signed with a trusted key. I'm really sorry to belabor this point, but can kexec rely on an LSM label to identify a specific file, out of all the files being executed, in a secure boot environment? The SELinux integrity rule for kexec would then look something like, appraise func=BPRM_CHECK obj_type=kdump_exec_t appraise_type=imasig We could then follow this up with Serge's idea of, "a capset akin to the bounding set, saying you can only have the caps in this set if the running binary was a signed one." kexec already requires CAP_SYS_BOOT. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2013-03-20 at 17:11 -0400, Mimi Zohar wrote: > On Wed, 2013-03-20 at 20:37 +0000, Matthew Garrett wrote: > > Right, that'd be the rough idea. Any further runtime policy updates > > would presumably need to be signed with a trusted key. > > I'm really sorry to belabor this point, but can kexec rely on an LSM > label to identify a specific file, out of all the files being executed, > in a secure boot environment? The SELinux integrity rule for kexec > would then look something like, > > appraise func=BPRM_CHECK obj_type=kdump_exec_t appraise_type=imasig It would certainly be possible to configure a system such that this was true (assuming support for signed initramfs and restricted policy loading), and anyone wanting to ensure that kexec only loaded trusted binaries would have to ensure that their system was appropriately configured. Having some mechanism to then give the kexec binary CAP_MODIFY_KERNEL would avoid needing an extra kexec entry point. -- Matthew Garrett | mjg59@srcf.ucam.org
On Wed, 20 Mar 2013, Mimi Zohar wrote: > On Tue, 2013-03-19 at 15:47 +1100, James Morris wrote: > > On Mon, 18 Mar 2013, Matthew Garrett wrote: > > > > > This patch introduces CAP_COMPROMISE_KERNEL. > > > > I'd like to see this named CAP_MODIFY_KERNEL, which is more accurate and > > less emotive. Otherwise I think core kernel developers will be scratching > > their head over where to sprinkle this. > > > > Apart from that, I like the idea, especially when it's wired up to MAC > > security. > > Matthrew, perhaps you could clarify whether this will be tied to MAC > security. All capabilities are, via LSM.
On Wed, Mar 20, 2013 at 09:18:10PM +0000, Matthew Garrett wrote: > On Wed, 2013-03-20 at 17:11 -0400, Mimi Zohar wrote: > > On Wed, 2013-03-20 at 20:37 +0000, Matthew Garrett wrote: > > > Right, that'd be the rough idea. Any further runtime policy updates > > > would presumably need to be signed with a trusted key. > > > > I'm really sorry to belabor this point, but can kexec rely on an LSM > > label to identify a specific file, out of all the files being executed, > > in a secure boot environment? The SELinux integrity rule for kexec > > would then look something like, > > > > appraise func=BPRM_CHECK obj_type=kdump_exec_t appraise_type=imasig > > It would certainly be possible to configure a system such that this was > true (assuming support for signed initramfs and restricted policy > loading), and anyone wanting to ensure that kexec only loaded trusted > binaries would have to ensure that their system was appropriately > configured. Having some mechanism to then give the kexec binary > CAP_MODIFY_KERNEL would avoid needing an extra kexec entry point. Giving CAP_MODIFY_KERNEL to processess upon signature verification will simplify things a bit. Only thing is that signature verification alone is not sufficient. We also need to make sure after signature verification executable can not be modified in memory in any way. So that means atleast couple of things. - Process code/data should not be swapped out. Otherwise it can possibly be written by unsigned priviliged processes and then faulted in back. - Because priviliged unsigned processes can bypass file system and directly write to disk, do not cache appraisal results. So create a way in IMA rules to not cache the results. I think memory locking part is little tricky as what part of files are to be locked will depend on the binary loader (and not IMA). May be IMA can set a flag somewhere which gives an hint to binary loader that lock down file. Once the file has been locked down, binary loader should set some flag too and call security hook. This flag will be a hint to IMA that file has been locked down, another appraisal happens and if it passes successfuly, then IMA can give CAP_MODIFY_KERNEL capability to the process. Another small nit is appraise_type=imasig. Given the fact that there can be many formats of digital signature, we might have to make it more fine grained to be able to specify a particular kind of digital signature and not every possible digital signature supported. Assuming all this works, I can look into how /sbin/kexec can call into kernel to verify integrity of bzImage before it is loaded. Not sure one needs to very PE/COFF signature or bzImage will be re-signed using IMA and one needs to call into IMA. I think here also we will have to first lock down file in memory, make sure nobody can open file for writes, and then do signature verification. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoting Vivek Goyal (vgoyal@redhat.com): ... > Giving CAP_MODIFY_KERNEL to processess upon signature verification > will simplify things a bit. > > Only thing is that signature verification alone is not sufficient. We > also need to make sure after signature verification executable can > not be modified in memory in any way. So that means atleast couple of > things. Also what about context? If I construct a mounts namespace a certain way, can I trick this executable into loading an old singed bzImage that I had laying around? ISTM the only sane thing to do, if you're going down this road, is to have CAP_MODIFIY_KERNEL pulled from bounding set for everyone except a getty started by init on ttyS0. Then log in on serial to update. Or run a damon with CAP_MODIFIY_KERNEL which listens to a init_net_ns netlink socket for very basic instructions, like "find and install latest signed bzImage in /boot". Then you can at least trust that /boot for that daemon is not faked. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote: > Quoting Vivek Goyal (vgoyal@redhat.com): > ... > > Giving CAP_MODIFY_KERNEL to processess upon signature verification > > will simplify things a bit. > > > > Only thing is that signature verification alone is not sufficient. We > > also need to make sure after signature verification executable can > > not be modified in memory in any way. So that means atleast couple of > > things. > > Also what about context? If I construct a mounts namespace a certain > way, can I trick this executable into loading an old singed bzImage that > I had laying around? We were thinking that /sbin/kexec will need to verify bzImage signature before loading it. Key for verification is in kernel so idea was to take kernel's help in verifying signature. Not sure how exactly the interface should look like. - I was thinking may be process can mmap() the bzImage with MAP_LOCKED. We can create additional flag say MAP_VERIFY_SIG_POST, which tries to verify signature/integrity of mapped region of file after mapping and locking pages and mmap() fails if signature verification fails. There have been suggestions about creating new system call altogether. > > ISTM the only sane thing to do, if you're going down this road, > is to have CAP_MODIFIY_KERNEL pulled from bounding set for everyone > except a getty started by init on ttyS0. Then log in on serial > to update. Or run a damon with CAP_MODIFIY_KERNEL which listens > to a init_net_ns netlink socket for very basic instructions, like > "find and install latest signed bzImage in /boot". Then you can > at least trust that /boot for that daemon is not faked. daemon does not have the key and can't verify signature of signed bzImage. Even if it had the key, it can't trust the crypto code for signature verification as none of that is signed. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoting Vivek Goyal (vgoyal@redhat.com): > On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote: > > Quoting Vivek Goyal (vgoyal@redhat.com): > > ... > > > Giving CAP_MODIFY_KERNEL to processess upon signature verification > > > will simplify things a bit. > > > > > > Only thing is that signature verification alone is not sufficient. We > > > also need to make sure after signature verification executable can > > > not be modified in memory in any way. So that means atleast couple of > > > things. > > > > Also what about context? If I construct a mounts namespace a certain > > way, can I trick this executable into loading an old singed bzImage that > > I had laying around? > > We were thinking that /sbin/kexec will need to verify bzImage signature > before loading it. > > Key for verification is in kernel so idea was to take kernel's help > in verifying signature. > > Not sure how exactly the interface should look like. > > - I was thinking may be process can mmap() the bzImage with MAP_LOCKED. > We can create additional flag say MAP_VERIFY_SIG_POST, which tries > to verify signature/integrity of mapped region of file after mapping and > locking pages and mmap() fails if signature verification fails. > > There have been suggestions about creating new system call altogether. > > > > > ISTM the only sane thing to do, if you're going down this road, > > is to have CAP_MODIFIY_KERNEL pulled from bounding set for everyone > > except a getty started by init on ttyS0. Then log in on serial > > to update. Or run a damon with CAP_MODIFIY_KERNEL which listens > > to a init_net_ns netlink socket for very basic instructions, like > > "find and install latest signed bzImage in /boot". Then you can > > at least trust that /boot for that daemon is not faked. > > daemon does not have the key and can't verify signature of signed > bzImage. Even if it had the key, it can't trust the crypto code for > signature verification as none of that is signed. I'm not saying not to use the kernel to verify the signature. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 21, 2013 at 10:58:23AM -0500, Serge E. Hallyn wrote: > Quoting Vivek Goyal (vgoyal@redhat.com): > > On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote: > > > Quoting Vivek Goyal (vgoyal@redhat.com): > > > ... > > > > Giving CAP_MODIFY_KERNEL to processess upon signature verification > > > > will simplify things a bit. > > > > > > > > Only thing is that signature verification alone is not sufficient. We > > > > also need to make sure after signature verification executable can > > > > not be modified in memory in any way. So that means atleast couple of > > > > things. > > > > > > Also what about context? If I construct a mounts namespace a certain > > > way, can I trick this executable into loading an old singed bzImage that > > > I had laying around? > > > > We were thinking that /sbin/kexec will need to verify bzImage signature > > before loading it. > > > > Key for verification is in kernel so idea was to take kernel's help > > in verifying signature. > > > > Not sure how exactly the interface should look like. > > > > - I was thinking may be process can mmap() the bzImage with MAP_LOCKED. > > We can create additional flag say MAP_VERIFY_SIG_POST, which tries > > to verify signature/integrity of mapped region of file after mapping and > > locking pages and mmap() fails if signature verification fails. > > > > There have been suggestions about creating new system call altogether. > > > > > > > > ISTM the only sane thing to do, if you're going down this road, > > > is to have CAP_MODIFIY_KERNEL pulled from bounding set for everyone > > > except a getty started by init on ttyS0. Then log in on serial > > > to update. Or run a damon with CAP_MODIFIY_KERNEL which listens > > > to a init_net_ns netlink socket for very basic instructions, like > > > "find and install latest signed bzImage in /boot". Then you can > > > at least trust that /boot for that daemon is not faked. > > > > daemon does not have the key and can't verify signature of signed > > bzImage. Even if it had the key, it can't trust the crypto code for > > signature verification as none of that is signed. > > I'm not saying not to use the kernel to verify the signature. Ok. So why can't /sbin/kexec can do the verification of bzImage with kernel's help. Due to crafted /boot/ it might load old signed bzImage, but it can't load unsigned/untrusted code on secureboot system at ring 0. I am hoping I did not miss your point entirely. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoting Vivek Goyal (vgoyal@redhat.com): > On Thu, Mar 21, 2013 at 10:58:23AM -0500, Serge E. Hallyn wrote: > > Quoting Vivek Goyal (vgoyal@redhat.com): > > > On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote: > > > > Quoting Vivek Goyal (vgoyal@redhat.com): > > > > ... > > > > > Giving CAP_MODIFY_KERNEL to processess upon signature verification > > > > > will simplify things a bit. > > > > > > > > > > Only thing is that signature verification alone is not sufficient. We > > > > > also need to make sure after signature verification executable can > > > > > not be modified in memory in any way. So that means atleast couple of > > > > > things. > > > > > > > > Also what about context? If I construct a mounts namespace a certain > > > > way, can I trick this executable into loading an old singed bzImage that > > > > I had laying around? > > > > > > We were thinking that /sbin/kexec will need to verify bzImage signature > > > before loading it. > > > > > > Key for verification is in kernel so idea was to take kernel's help > > > in verifying signature. > > > > > > Not sure how exactly the interface should look like. > > > > > > - I was thinking may be process can mmap() the bzImage with MAP_LOCKED. > > > We can create additional flag say MAP_VERIFY_SIG_POST, which tries > > > to verify signature/integrity of mapped region of file after mapping and > > > locking pages and mmap() fails if signature verification fails. > > > > > > There have been suggestions about creating new system call altogether. > > > > > > > > > > > ISTM the only sane thing to do, if you're going down this road, > > > > is to have CAP_MODIFIY_KERNEL pulled from bounding set for everyone > > > > except a getty started by init on ttyS0. Then log in on serial > > > > to update. Or run a damon with CAP_MODIFIY_KERNEL which listens > > > > to a init_net_ns netlink socket for very basic instructions, like > > > > "find and install latest signed bzImage in /boot". Then you can > > > > at least trust that /boot for that daemon is not faked. > > > > > > daemon does not have the key and can't verify signature of signed > > > bzImage. Even if it had the key, it can't trust the crypto code for > > > signature verification as none of that is signed. > > > > I'm not saying not to use the kernel to verify the signature. > > Ok. So why can't /sbin/kexec can do the verification of bzImage with > kernel's help. Due to crafted /boot/ it might load old signed bzImage, > but it can't load unsigned/untrusted code on secureboot system at ring 0. > > I am hoping I did not miss your point entirely. No, you didn't. If replay attacks are not a concern then that bit doesn't matter. But if^Wwhen there is a vulnerability in a signed kernel, and a user has a copy of bzImage sitting around, signed kexec alone does not suffice (and I'm assuming revocation is not going into the kernel?). It seems to me if replay attacks are ignored, this is all for theater... The other concern is analogous, just more general - seems like I may very well be able to find a way to corrupt kexec or even corrupt the kernel with a bad environment. So I'm just saying that in general it doesn't seem worth having a special list of capabilities that only signed executables can have, without doing something about the environment. And that the solution to that seems like what we can already do today (with a bounding set and init-launched services). All of this is probably premature though. IIUC the first thing you are after is a way to record on the file the fact that it is a verified-signature binary, and that's what CAP_SIGNED meant right? I agree we need something like that, but using a capability is not right. You can add a field to the binprm or file or f_cred, or even add a field to the capability struct, meaningful only on files, to show it was signed - but not taint the list of capabilities with something that is not a capability. I haven't looked closer to see which would be the best way (my hunch would be binprm), will be happy to come up with a proposal when I have time, but I don't want to slow you down :) -serge -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 21, 2013 at 11:19:52AM -0500, Serge E. Hallyn wrote: [..] > > I am hoping I did not miss your point entirely. > > No, you didn't. If replay attacks are not a concern then that bit > doesn't matter. But if^Wwhen there is a vulnerability in a signed kernel, > and a user has a copy of bzImage sitting around, signed kexec alone does > not suffice (and I'm assuming revocation is not going into the kernel?). > It seems to me if replay attacks are ignored, this is all for theater... > As matthew mentioned, revocation list is in kernel. So old vulnerable kernels should fail signature verification. > The other concern is analogous, just more general - seems like I may very > well be able to find a way to corrupt kexec or even corrupt the kernel with > a bad environment. > > So I'm just saying that in general it doesn't seem worth having a special > list of capabilities that only signed executables can have, without doing > something about the environment. Agreed that only being signed is part of the problem. Environment is important too. And running signed binaries memory locked is I think one part of controlling the environment. But there might be other things too which I am blissfully unaware of. Right now there were few things we were considering for controlling the environemnt. - Build /sbin/kexec statically and sign only statically linked exeutables. - Run executables memory locked - Unsigned binary can not ptrace() signed one. > And that the solution to that seems like > what we can already do today (with a bounding set and init-launched > services). Frankly speaking I did not understand this part. For secureboot issue we don't trust root and don't trust init. I am assuming any restricted environment setup will have to be done by a trusted entity. > > All of this is probably premature though. IIUC the first thing you are > after is a way to record on the file the fact that it is a verified-signature > binary, and that's what CAP_SIGNED meant right? Yes, that was the first thing. How to reliably sign and verify signature of a executable. Also make sure executable code/data can not modified in memory later by anything untrusted. > I agree we need something > like that, but using a capability is not right. You can add a field to > the binprm or file or f_cred, or even add a field to the capability struct, > meaningful only on files, to show it was signed - but not taint the list of > capabilities with something that is not a capability. Ok, I will look into other options too. Agreed being signed is not a capability. But being signed along with other attributes should allow to get one a capability (CAP_MODIFY_KERNEL in this case). I am not sure why nobody likes that idea. But that's fine, I will go with advice of subject matter experts. > I haven't looked > closer to see which would be the best way (my hunch would be binprm), will > be happy to come up with a proposal when I have time, but I don't want to slow > you down :) Any suggetions are greatly appreciated whenever time permits. In the mean time I will atleast write more code and post it for RFC and hopefully there will be some consensus on how to solve kexec issue. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h index ba478fa..7109e650 100644 --- a/include/uapi/linux/capability.h +++ b/include/uapi/linux/capability.h @@ -343,7 +343,11 @@ struct vfs_cap_data { #define CAP_BLOCK_SUSPEND 36 -#define CAP_LAST_CAP CAP_BLOCK_SUSPEND +/* Allow things that trivially permit root to modify the running kernel */ + +#define CAP_COMPROMISE_KERNEL 37 + +#define CAP_LAST_CAP CAP_COMPROMISE_KERNEL #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
Caring about protecting the kernel from UID 0 was previously relatively uninteresting, since an attacker could simply modify the kernel, a module or an earlier part of the boot chain in order to insert new code. However, there are now a range of widely-deployed mechanisms for ensuring the authenticity of the early boot process and kernel. The addition of module signing makes most of these attacks infeasible. This means we can return our focus to the kernel. There's currently a number of kernel interfaces that permit privileged userspace to modify the running kernel. These are currently protected by CAP_SYS_RAWIO, but unfortunately the semantics of this capability are poorly defined and it now covers a large superset of the desired behaviour. This patch introduces CAP_COMPROMISE_KERNEL. Holding this capability indicates that a process is empowered to perform tasks that may result in modification of the running kernel. While aimed at handling the specific use-case of Secure Boot, it is generalisable to any other environment where permitting userspace to modify the kernel is undesirable. Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> --- include/uapi/linux/capability.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)