Re: [PATCH 0/6] MODSIGN: Kernel module signing
> > The restricted dev/mem patches we've had in Fedora for a while > do the right thing, but they're a bit crufty (in part due to > drivers/char/mem.c being a bit of a mess before we even start > patching it). I've had "clean these up for upstream" on my > todo for a while. I might get around to it one of these days. the real thing is that /dev/mem is too many things for too many people. Fundamentally it has 3 components 1) ram-but-not-kernel data: basically BIOS datastructures 2) kernel visible ram: user/kernel data, this has all the nasty cache coherency issues. This is also a "debug only" use, and "rootkit only" sometimes ;) 3) MMIO space: this really should not be used anymore, sysfs provides a MUCH better interface and it also breaks if you have enforcing IOMMU's in the system... it can't really work since the kernel doesn't get told which device is being accessed unless we split this up (well the third is split already) it's going to remain a big mess. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thu, Feb 15, 2007 at 10:13:04PM +, Pavel Machek wrote: > Hi! > > > Now, this is not a complete solution by any means: the core kernel is not > > protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least > > controls) one relatively simple attack vector. > > Could we fix the /dev/*mem holes, first? They are already used by > malicious modules (aka rootkits...). Or can selinux already provide > /dev/*mem protection with no way for admin to turn it off? There are some valid uses for peeking through /dev/mem. Things like dmidecode for example. So you don't want to disable it completely in a lot of cases, but have fine-grained access to specific parts of the file. I'm not sure SELinux can do this. Maybe the MLS stuff helps here (though I'm far from an expert on this, so I could be talking out of my rear). The restricted dev/mem patches we've had in Fedora for a while do the right thing, but they're a bit crufty (in part due to drivers/char/mem.c being a bit of a mess before we even start patching it). I've had "clean these up for upstream" on my todo for a while. I might get around to it one of these days. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hi! > > well, the situation for external modules is no worse than usual. > > They still work, they just aren't signed. Which from a distributor point > > of view, is actually a nice thing, as they stick out like a sore thumb > > in oops reports with (U) markers :) > > I agree, that's really what should happen. We solve this by marking modules > as > supported, partner supported, or unsupported, but in an "insecure" way, so > partners and users could try to fake the support status of a module and/or > remove status flags from Oopses, and cryptography wouldn't save us. We could > try to sign Oopses which I guess you guys are doing. This whole issue hasn't I do not think any ammount of crypto can determine that I loaded unsupported module, then edited oops. (TPM hw module may be able to do that, not sure). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hi! > Now, this is not a complete solution by any means: the core kernel is not > protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least > controls) one relatively simple attack vector. Could we fix the /dev/*mem holes, first? They are already used by malicious modules (aka rootkits...). Or can selinux already provide /dev/*mem protection with no way for admin to turn it off? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Roman Zippel <[EMAIL PROTECTED]> wrote: > On Thu, 15 Feb 2007, David Howells wrote: >> > This is really the weak point - it offers no advantage over an equivalent >> > implementation in user space (e.g. in the module tools). So why has to be >> > done in the kernel? >> >> Because the init_module() system call is the common point of module >> submission >> to the kernel, not any particular userspace program. There is no requirement >> for userspace to load a module by invoking a module tools program or library, >> and so userspace can bypass the checks entirely by just calling >> init_module(). >> Assume for a moment that you can't trust userspace... (Obviously, if you >> can't trust the kernel then you're already stuffed.) > > All the security stuff in the kernel should provide the necessary means to > restrict this system call. Hardening a system should include deeper layers, too. >> It is possible to protect /dev/mem and /dev/kmem or make them unavailable and >> it is possible to protect the kernel's memory whilst it is running (provided >> you don't have nommu or broken hardware and you don't let userspace concoct >> any DMA request it likes) which mostly closes those other vectors I >> mentioned. >> This isn't something I intended to look at with this patch. Those are >> separate holes. > > Exactly and as long as there are these holes, these patches are only > kernel bloat. Off cause there are other ways to expose the kernel, but they can be plugged, too, one by one. You wouldn't leave your door open just because your window is open, while leaving the window open because the door is open. > The simple verification can also be done in userspace and You may verify in userspace, but you can't use the result. OTOH, having 1000 lines of code to verify a module _is_ bloat for this task. Remove a 0 and it should be plenty (not counting the help text). > module signing offers no real security. It offers security against a class of attacks. > What real value do these patches provide, that can't be reached via other > means? It provides an extra layer of security: If an exploit allows execution of insmod(userstring), it can't compromise kernel internals. > Who else than distributions would be interested in this? How large is the userbase _not_ using a distribution? And are they unable to unselect [X] Signes modules support? > Pretty > much any use you initially mentioned can be done in simpler ways, e.g. > anyone afraid of modules simply disables module loading completely. That would work if there was no need for modules. Unfortunately some people are doomed with external modules, or not experienced enough to customize their system. Those could benefit from a sysctl(?) saying "unsigned_modules = taint|disallow". -- Whenever you have plenty of ammo, you never miss. Whenever you are low on ammo, you can't hit the broad side of a barn. Friß, Spammer: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Roman Zippel [EMAIL PROTECTED] wrote: On Thu, 15 Feb 2007, David Howells wrote: This is really the weak point - it offers no advantage over an equivalent implementation in user space (e.g. in the module tools). So why has to be done in the kernel? Because the init_module() system call is the common point of module submission to the kernel, not any particular userspace program. There is no requirement for userspace to load a module by invoking a module tools program or library, and so userspace can bypass the checks entirely by just calling init_module(). Assume for a moment that you can't trust userspace... (Obviously, if you can't trust the kernel then you're already stuffed.) All the security stuff in the kernel should provide the necessary means to restrict this system call. Hardening a system should include deeper layers, too. It is possible to protect /dev/mem and /dev/kmem or make them unavailable and it is possible to protect the kernel's memory whilst it is running (provided you don't have nommu or broken hardware and you don't let userspace concoct any DMA request it likes) which mostly closes those other vectors I mentioned. This isn't something I intended to look at with this patch. Those are separate holes. Exactly and as long as there are these holes, these patches are only kernel bloat. Off cause there are other ways to expose the kernel, but they can be plugged, too, one by one. You wouldn't leave your door open just because your window is open, while leaving the window open because the door is open. The simple verification can also be done in userspace and You may verify in userspace, but you can't use the result. OTOH, having 1000 lines of code to verify a module _is_ bloat for this task. Remove a 0 and it should be plenty (not counting the help text). module signing offers no real security. It offers security against a class of attacks. What real value do these patches provide, that can't be reached via other means? It provides an extra layer of security: If an exploit allows execution of insmod(userstring), it can't compromise kernel internals. Who else than distributions would be interested in this? How large is the userbase _not_ using a distribution? And are they unable to unselect [X] Signes modules support? Pretty much any use you initially mentioned can be done in simpler ways, e.g. anyone afraid of modules simply disables module loading completely. That would work if there was no need for modules. Unfortunately some people are doomed with external modules, or not experienced enough to customize their system. Those could benefit from a sysctl(?) saying unsigned_modules = taint|disallow. -- Whenever you have plenty of ammo, you never miss. Whenever you are low on ammo, you can't hit the broad side of a barn. Friß, Spammer: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hi! Now, this is not a complete solution by any means: the core kernel is not protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least controls) one relatively simple attack vector. Could we fix the /dev/*mem holes, first? They are already used by malicious modules (aka rootkits...). Or can selinux already provide /dev/*mem protection with no way for admin to turn it off? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hi! well, the situation for external modules is no worse than usual. They still work, they just aren't signed. Which from a distributor point of view, is actually a nice thing, as they stick out like a sore thumb in oops reports with (U) markers :) I agree, that's really what should happen. We solve this by marking modules as supported, partner supported, or unsupported, but in an insecure way, so partners and users could try to fake the support status of a module and/or remove status flags from Oopses, and cryptography wouldn't save us. We could try to sign Oopses which I guess you guys are doing. This whole issue hasn't I do not think any ammount of crypto can determine that I loaded unsupported module, then edited oops. (TPM hw module may be able to do that, not sure). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thu, Feb 15, 2007 at 10:13:04PM +, Pavel Machek wrote: Hi! Now, this is not a complete solution by any means: the core kernel is not protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least controls) one relatively simple attack vector. Could we fix the /dev/*mem holes, first? They are already used by malicious modules (aka rootkits...). Or can selinux already provide /dev/*mem protection with no way for admin to turn it off? There are some valid uses for peeking through /dev/mem. Things like dmidecode for example. So you don't want to disable it completely in a lot of cases, but have fine-grained access to specific parts of the file. I'm not sure SELinux can do this. Maybe the MLS stuff helps here (though I'm far from an expert on this, so I could be talking out of my rear). The restricted dev/mem patches we've had in Fedora for a while do the right thing, but they're a bit crufty (in part due to drivers/char/mem.c being a bit of a mess before we even start patching it). I've had clean these up for upstream on my todo for a while. I might get around to it one of these days. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
The restricted dev/mem patches we've had in Fedora for a while do the right thing, but they're a bit crufty (in part due to drivers/char/mem.c being a bit of a mess before we even start patching it). I've had clean these up for upstream on my todo for a while. I might get around to it one of these days. the real thing is that /dev/mem is too many things for too many people. Fundamentally it has 3 components 1) ram-but-not-kernel data: basically BIOS datastructures 2) kernel visible ram: user/kernel data, this has all the nasty cache coherency issues. This is also a debug only use, and rootkit only sometimes ;) 3) MMIO space: this really should not be used anymore, sysfs provides a MUCH better interface and it also breaks if you have enforcing IOMMU's in the system... it can't really work since the kernel doesn't get told which device is being accessed unless we split this up (well the third is split already) it's going to remain a big mess. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thursday 15 February 2007 12:34, [EMAIL PROTECTED] wrote: > On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said: > > I agree, that's really what should happen. We solve this by marking > > modules as supported, partner supported, or unsupported, but in an > > "insecure" way, so partners and users could try to fake the support > > status of a module and/or remove status flags from Oopses, and > > cryptography wouldn't save us. > > Where cryptography *can* save you is that a partner or user can't fake a > 'Suse Supported' signature without access to the Suse private key. The user has control over the running kernel, and given enough time and clue, can circumvent any protection mechanism the vendor comes up with. And that's a good thing IMO, unless you believe in "trusted computing" and all those Bigbrotherisms some agencies want to put in your machines. So the user is running a system in some state that may or may not resemble what the vendor shipped. When the machine crashes, the user is free to munge the oops until it looks like a valid one. Someone mentioned in this context that you can sign the oops - but to do that you need a private key. And the whole point of this exercise is that the user does not have access to that key. So as far as support is concerned, you're back in square one. You cannot tell a "genuine" oops produced on a supported kernel from a doctored one produced on Joe Doe's Garage Kernel. Olaf -- Olaf Kirch| Anyone who has had to work with X.509 has probably [EMAIL PROTECTED] | experienced what can best be described as --+ ISO water torture. -- Peter Gutmann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thu, 15 Feb 2007 22:32:40 +0100, Adrian Bunk said: > There are different opinions whether the "complete source code" of the > GPLv2 includes in such cases public keys, making it questionable whether > your example will survive at court in all jurisdictions. It's no less shaky than the whole EXPORT_SYMBOL_GPL-as-enforcement crock. :) > E.g. remember that gpl-violations.org has already successfully enforced > the publication of public keys for "firmware only loads signed kernels" > cases by threatening companies to otherwise take legal actions in > Germany. A court order for the publication of *public* keys? :) I think you meant "private keys" in both paragraphs above. And it's probably a non-issue the way Red Hat implemented it - they included a document on "How to generate your own public/private key pair", which invokes commands that create a bitstring that you can then use to sign the entire applicable part of the kernel tree. The fact that it's not the *same* bitstring as they used is (IMHO) legally about as relevant as the fact that they compiled the tree with one release of GCC, included instructions on how to compile it, and I don't get a bitwise identical binary if I compile it with a different GCC release. Yes, you're still screwed if you only build *part* of the kernel tree and expect it to work - modules you sign won't load into their kernel, and vice versa. But that's the same problem as the old 2.4 "You didn't do a make clean between rebuilds and you bugged out because different parts of the tree were built with different GCC releases". As distributed, you *can* build a working kernel from the pieces and instructions provided. pgpiSVLsNemH0.pgp Description: PGP signature
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thursday 15 February 2007 12:34, [EMAIL PROTECTED] wrote: > On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said: > > I agree, that's really what should happen. We solve this by marking > > modules as supported, partner supported, or unsupported, but in an > > "insecure" way, so partners and users could try to fake the support > > status of a module and/or remove status flags from Oopses, and > > cryptography wouldn't save us. > > Where cryptography *can* save you is that a partner or user can't fake a > 'Suse Supported' signature without access to the Suse private key. No question about that. We actually already get this from rpm signatures. What would module signatures buy us? The kernel could then reliably determine that an unsigned module was loaded. But people could still fake their Oopses, or overwite the flags which indicate that a module's signature didn't match, so we still wouldn't reliably get at that information. Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thu, Feb 15, 2007 at 03:55:41PM -0500, [EMAIL PROTECTED] wrote:
> On Wed, 14 Feb 2007 23:13:45 EST, Dave Jones said:
> > One argument in its favour is aparently Red Hat isn't the only vendor
> > with something like this. I've not investigated it, but I hear rumours
> > that suse has something similar. Having everyone using the same code
> > would be a win for obvious reasons.
>
> Another argument in its favor is that it actually allows the kernel to
> implement *real* checking of module licenses and trumps all the proposals
> to deal with MODULE_LICENSE("GPL\0Haha!"). A vendor (or user) that wants
> to be *sure* that only *really really* GPL modules are loaded can simply
> refuse to load unsigned modules - and then refuse to sign a module until
> after they had themselves visited the source's website, verified that the
> source code was available under GPL, and so on.
>
> Remember - the GPL is about the availability of the source. And at modprobe
> time, the source isn't available. So you're left with two options:
>
> 1) Trust the binary to not lie to you about its license.
> 2) Ask a trusted 3rd party (usually, the person/distro that built the kernel)
> whether they've verified the claim that it's really GPL.
There are different opinions whether the "complete source code" of the
GPLv2 includes in such cases public keys, making it questionable whether
your example will survive at court in all jurisdictions.
E.g. remember that gpl-violations.org has already successfully enforced
the publication of public keys for "firmware only loads signed kernels"
cases by threatening companies to otherwise take legal actions in
Germany.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hello, On Wed, February 14, 2007 20:40, David Howells wrote: > Linus Torvalds <[EMAIL PROTECTED]> wrote: > >> > (1) A cut-down MPI library derived from GPG with error handling added. >> >> Do we really need to add this? > > I presume you mean the MPI library specifically? If so, then yes. It's > necessary to do DSA signature verification (or RSA for that matter). > >> Wouldn't it be much nicer to just teach people to use one of the existing >> signature things that we need for _other_ cases anyway, and already have >> merged? > > Existing signature things? I know not of such beasts, nor can I see them > offhand. The question is if using DSA/RSA is the right choice for something like this. I think that the symmetrically encrypted hash output as signature would provide the same amount of security. The only additional requirement is that the key can't be read by userspace. But if they can reach the kernel binary, they can modify it too. Same for the bootloader, where you'd want the key and initial checking anyway. Else this whole thing could be done in user space as Roman Zippel said... The ELF section stuff seems like unnecessary bloat too. Can't you use/extend modinfo, or kernel symbols? With the above changes the code should shrink to only a few hundred new lines of code, instead of thousands, and signature checking will be much faster too. Greetings, Indan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 07:09:38PM +, David Howells wrote: >... > There are several reasons why these patches are useful, amongst which are: >... > (4) to allow other support providers to do likewise, or at least to _detect_ > the fact that unsupported modules are loaded; > > (5) to allow the detection of modules replaced by a second-order distro or a > preloaded Linux purveyor. >... Who might have rebuilt the whole kernel using a new signature. Or a bug reporter might have edited out the parts containing the information that unsupported code was loaded. Or the unsupported module itself might have removed all traces of having been loaded from the kernel. For printing nvidia(U), you could simply add some marker similar to MODULE_LICENSE() that gets added to supported modules during "official" builds and gets checked when loading a module. That's 10k LOC less and the same level of security... > David cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hi, On Thu, 15 Feb 2007, David Lang wrote: > this issue, and these holes keep comeing up in discussions, why can't these > holes be closed? I seem to remember seeing patches that would remove /dev/kmem > being sent to the list, but they weren't accepted into the kernel (and I seem > to remember people being against the concept of removeing them, not against > techincal details of the patches. but this was many years ago) 1. It depends on the ratio of added code and its usefulness. I must assume the first patch didn't even make it to the kernel due to its size, so I think it's not unreasonable to explore the alternatives. 2. There are many ways to load an unauthorized module, thus you have to prevent any modification of the kernel not just in memory but also on disk. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, 14 Feb 2007 23:13:45 EST, Dave Jones said:
> One argument in its favour is aparently Red Hat isn't the only vendor
> with something like this. I've not investigated it, but I hear rumours
> that suse has something similar. Having everyone using the same code
> would be a win for obvious reasons.
Another argument in its favor is that it actually allows the kernel to
implement *real* checking of module licenses and trumps all the proposals
to deal with MODULE_LICENSE("GPL\0Haha!"). A vendor (or user) that wants
to be *sure* that only *really really* GPL modules are loaded can simply
refuse to load unsigned modules - and then refuse to sign a module until
after they had themselves visited the source's website, verified that the
source code was available under GPL, and so on.
Remember - the GPL is about the availability of the source. And at modprobe
time, the source isn't available. So you're left with two options:
1) Trust the binary to not lie to you about its license.
2) Ask a trusted 3rd party (usually, the person/distro that built the kernel)
whether they've verified the claim that it's really GPL.
pgpMC8UK2H3xc.pgp
Description: PGP signature
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said: > I agree, that's really what should happen. We solve this by marking modules as > supported, partner supported, or unsupported, but in an "insecure" way, so > partners and users could try to fake the support status of a module and/or > remove status flags from Oopses, and cryptography wouldn't save us. Where cryptography *can* save you is that a partner or user can't fake a 'Suse Supported' signature without access to the Suse private key. pgpv9aSScJwDV.pgp Description: PGP signature
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thu, 15 Feb 2007, Roman Zippel wrote: On Thu, 15 Feb 2007, David Howells wrote: It is possible to protect /dev/mem and /dev/kmem or make them unavailable and it is possible to protect the kernel's memory whilst it is running (provided you don't have nommu or broken hardware and you don't let userspace concoct any DMA request it likes) which mostly closes those other vectors I mentioned. This isn't something I intended to look at with this patch. Those are separate holes. Exactly and as long as there are these holes, these patches are only kernel bloat. The simple verification can also be done in userspace and module signing offers no real security. What real value do these patches provide, that can't be reached via other means? Who else than distributions would be interested in this? Pretty much any use you initially mentioned can be done in simpler ways, e.g. anyone afraid of modules simply disables module loading completely. this issue, and these holes keep comeing up in discussions, why can't these holes be closed? I seem to remember seeing patches that would remove /dev/kmem being sent to the list, but they weren't accepted into the kernel (and I seem to remember people being against the concept of removeing them, not against techincal details of the patches. but this was many years ago) at one point I remember hearing that X required raw /dev/kmem, but for servers you don't need/want X anyway, so this is a useful option even if X doesn't get fixed. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hi, On Thu, 15 Feb 2007, David Howells wrote: > > This is really the weak point - it offers no advantage over an equivalent > > implementation in user space (e.g. in the module tools). So why has to be > > done in the kernel? > > Because the init_module() system call is the common point of module submission > to the kernel, not any particular userspace program. There is no requirement > for userspace to load a module by invoking a module tools program or library, > and so userspace can bypass the checks entirely by just calling init_module(). > Assume for a moment that you can't trust userspace... (Obviously, if you > can't > trust the kernel then you're already stuffed.) All the security stuff in the kernel should provide the necessary means to restrict this system call. > It is possible to protect /dev/mem and /dev/kmem or make them unavailable and > it is possible to protect the kernel's memory whilst it is running (provided > you don't have nommu or broken hardware and you don't let userspace concoct > any > DMA request it likes) which mostly closes those other vectors I mentioned. > This isn't something I intended to look at with this patch. Those are > separate > holes. Exactly and as long as there are these holes, these patches are only kernel bloat. The simple verification can also be done in userspace and module signing offers no real security. What real value do these patches provide, that can't be reached via other means? Who else than distributions would be interested in this? Pretty much any use you initially mentioned can be done in simpler ways, e.g. anyone afraid of modules simply disables module loading completely. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Roman Zippel <[EMAIL PROTECTED]> wrote: > > Now, this is not a complete solution by any means: the core kernel is not > > protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least > > controls) one relatively simple attack vector. > > This is really the weak point - it offers no advantage over an equivalent > implementation in user space (e.g. in the module tools). So why has to be > done in the kernel? Because the init_module() system call is the common point of module submission to the kernel, not any particular userspace program. There is no requirement for userspace to load a module by invoking a module tools program or library, and so userspace can bypass the checks entirely by just calling init_module(). Assume for a moment that you can't trust userspace... (Obviously, if you can't trust the kernel then you're already stuffed.) It is possible to protect /dev/mem and /dev/kmem or make them unavailable and it is possible to protect the kernel's memory whilst it is running (provided you don't have nommu or broken hardware and you don't let userspace concoct any DMA request it likes) which mostly closes those other vectors I mentioned. This isn't something I intended to look at with this patch. Those are separate holes. Making the core kernel load image inaccessible or immutable to root is not something I can provide a generic solution for and security checking the core kernel load image has to be done at an earlier layer as you can't rely on something guaranteeing its own integrity because if someone can alter that something, then they can bypass the self-checking too... However, modules permits arbitrary modification of the running kernel to be attempted. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hi, On Wed, 14 Feb 2007, David Howells wrote: > Now, this is not a complete solution by any means: the core kernel is not > protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least > controls) one relatively simple attack vector. This is really the weak point - it offers no advantage over an equivalent implementation in user space (e.g. in the module tools). So why has to be done in the kernel? bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hi, On Wed, 14 Feb 2007, David Howells wrote: Now, this is not a complete solution by any means: the core kernel is not protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least controls) one relatively simple attack vector. This is really the weak point - it offers no advantage over an equivalent implementation in user space (e.g. in the module tools). So why has to be done in the kernel? bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Roman Zippel [EMAIL PROTECTED] wrote: Now, this is not a complete solution by any means: the core kernel is not protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least controls) one relatively simple attack vector. This is really the weak point - it offers no advantage over an equivalent implementation in user space (e.g. in the module tools). So why has to be done in the kernel? Because the init_module() system call is the common point of module submission to the kernel, not any particular userspace program. There is no requirement for userspace to load a module by invoking a module tools program or library, and so userspace can bypass the checks entirely by just calling init_module(). Assume for a moment that you can't trust userspace... (Obviously, if you can't trust the kernel then you're already stuffed.) It is possible to protect /dev/mem and /dev/kmem or make them unavailable and it is possible to protect the kernel's memory whilst it is running (provided you don't have nommu or broken hardware and you don't let userspace concoct any DMA request it likes) which mostly closes those other vectors I mentioned. This isn't something I intended to look at with this patch. Those are separate holes. Making the core kernel load image inaccessible or immutable to root is not something I can provide a generic solution for and security checking the core kernel load image has to be done at an earlier layer as you can't rely on something guaranteeing its own integrity because if someone can alter that something, then they can bypass the self-checking too... However, modules permits arbitrary modification of the running kernel to be attempted. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hi, On Thu, 15 Feb 2007, David Howells wrote: This is really the weak point - it offers no advantage over an equivalent implementation in user space (e.g. in the module tools). So why has to be done in the kernel? Because the init_module() system call is the common point of module submission to the kernel, not any particular userspace program. There is no requirement for userspace to load a module by invoking a module tools program or library, and so userspace can bypass the checks entirely by just calling init_module(). Assume for a moment that you can't trust userspace... (Obviously, if you can't trust the kernel then you're already stuffed.) All the security stuff in the kernel should provide the necessary means to restrict this system call. It is possible to protect /dev/mem and /dev/kmem or make them unavailable and it is possible to protect the kernel's memory whilst it is running (provided you don't have nommu or broken hardware and you don't let userspace concoct any DMA request it likes) which mostly closes those other vectors I mentioned. This isn't something I intended to look at with this patch. Those are separate holes. Exactly and as long as there are these holes, these patches are only kernel bloat. The simple verification can also be done in userspace and module signing offers no real security. What real value do these patches provide, that can't be reached via other means? Who else than distributions would be interested in this? Pretty much any use you initially mentioned can be done in simpler ways, e.g. anyone afraid of modules simply disables module loading completely. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thu, 15 Feb 2007, Roman Zippel wrote: On Thu, 15 Feb 2007, David Howells wrote: It is possible to protect /dev/mem and /dev/kmem or make them unavailable and it is possible to protect the kernel's memory whilst it is running (provided you don't have nommu or broken hardware and you don't let userspace concoct any DMA request it likes) which mostly closes those other vectors I mentioned. This isn't something I intended to look at with this patch. Those are separate holes. Exactly and as long as there are these holes, these patches are only kernel bloat. The simple verification can also be done in userspace and module signing offers no real security. What real value do these patches provide, that can't be reached via other means? Who else than distributions would be interested in this? Pretty much any use you initially mentioned can be done in simpler ways, e.g. anyone afraid of modules simply disables module loading completely. this issue, and these holes keep comeing up in discussions, why can't these holes be closed? I seem to remember seeing patches that would remove /dev/kmem being sent to the list, but they weren't accepted into the kernel (and I seem to remember people being against the concept of removeing them, not against techincal details of the patches. but this was many years ago) at one point I remember hearing that X required raw /dev/kmem, but for servers you don't need/want X anyway, so this is a useful option even if X doesn't get fixed. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said: I agree, that's really what should happen. We solve this by marking modules as supported, partner supported, or unsupported, but in an insecure way, so partners and users could try to fake the support status of a module and/or remove status flags from Oopses, and cryptography wouldn't save us. Where cryptography *can* save you is that a partner or user can't fake a 'Suse Supported' signature without access to the Suse private key. pgpv9aSScJwDV.pgp Description: PGP signature
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, 14 Feb 2007 23:13:45 EST, Dave Jones said: One argument in its favour is aparently Red Hat isn't the only vendor with something like this. I've not investigated it, but I hear rumours that suse has something similar. Having everyone using the same code would be a win for obvious reasons. Another argument in its favor is that it actually allows the kernel to implement *real* checking of module licenses and trumps all the proposals to deal with MODULE_LICENSE(GPL\0Haha!). A vendor (or user) that wants to be *sure* that only *really really* GPL modules are loaded can simply refuse to load unsigned modules - and then refuse to sign a module until after they had themselves visited the source's website, verified that the source code was available under GPL, and so on. Remember - the GPL is about the availability of the source. And at modprobe time, the source isn't available. So you're left with two options: 1) Trust the binary to not lie to you about its license. 2) Ask a trusted 3rd party (usually, the person/distro that built the kernel) whether they've verified the claim that it's really GPL. pgpMC8UK2H3xc.pgp Description: PGP signature
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hi, On Thu, 15 Feb 2007, David Lang wrote: this issue, and these holes keep comeing up in discussions, why can't these holes be closed? I seem to remember seeing patches that would remove /dev/kmem being sent to the list, but they weren't accepted into the kernel (and I seem to remember people being against the concept of removeing them, not against techincal details of the patches. but this was many years ago) 1. It depends on the ratio of added code and its usefulness. I must assume the first patch didn't even make it to the kernel due to its size, so I think it's not unreasonable to explore the alternatives. 2. There are many ways to load an unauthorized module, thus you have to prevent any modification of the kernel not just in memory but also on disk. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 07:09:38PM +, David Howells wrote: ... There are several reasons why these patches are useful, amongst which are: ... (4) to allow other support providers to do likewise, or at least to _detect_ the fact that unsupported modules are loaded; (5) to allow the detection of modules replaced by a second-order distro or a preloaded Linux purveyor. ... Who might have rebuilt the whole kernel using a new signature. Or a bug reporter might have edited out the parts containing the information that unsupported code was loaded. Or the unsupported module itself might have removed all traces of having been loaded from the kernel. For printing nvidia(U), you could simply add some marker similar to MODULE_LICENSE() that gets added to supported modules during official builds and gets checked when loading a module. That's 10k LOC less and the same level of security... David cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Hello, On Wed, February 14, 2007 20:40, David Howells wrote: Linus Torvalds [EMAIL PROTECTED] wrote: (1) A cut-down MPI library derived from GPG with error handling added. Do we really need to add this? I presume you mean the MPI library specifically? If so, then yes. It's necessary to do DSA signature verification (or RSA for that matter). Wouldn't it be much nicer to just teach people to use one of the existing signature things that we need for _other_ cases anyway, and already have merged? Existing signature things? I know not of such beasts, nor can I see them offhand. The question is if using DSA/RSA is the right choice for something like this. I think that the symmetrically encrypted hash output as signature would provide the same amount of security. The only additional requirement is that the key can't be read by userspace. But if they can reach the kernel binary, they can modify it too. Same for the bootloader, where you'd want the key and initial checking anyway. Else this whole thing could be done in user space as Roman Zippel said... The ELF section stuff seems like unnecessary bloat too. Can't you use/extend modinfo, or kernel symbols? With the above changes the code should shrink to only a few hundred new lines of code, instead of thousands, and signature checking will be much faster too. Greetings, Indan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thu, Feb 15, 2007 at 03:55:41PM -0500, [EMAIL PROTECTED] wrote: On Wed, 14 Feb 2007 23:13:45 EST, Dave Jones said: One argument in its favour is aparently Red Hat isn't the only vendor with something like this. I've not investigated it, but I hear rumours that suse has something similar. Having everyone using the same code would be a win for obvious reasons. Another argument in its favor is that it actually allows the kernel to implement *real* checking of module licenses and trumps all the proposals to deal with MODULE_LICENSE(GPL\0Haha!). A vendor (or user) that wants to be *sure* that only *really really* GPL modules are loaded can simply refuse to load unsigned modules - and then refuse to sign a module until after they had themselves visited the source's website, verified that the source code was available under GPL, and so on. Remember - the GPL is about the availability of the source. And at modprobe time, the source isn't available. So you're left with two options: 1) Trust the binary to not lie to you about its license. 2) Ask a trusted 3rd party (usually, the person/distro that built the kernel) whether they've verified the claim that it's really GPL. There are different opinions whether the complete source code of the GPLv2 includes in such cases public keys, making it questionable whether your example will survive at court in all jurisdictions. E.g. remember that gpl-violations.org has already successfully enforced the publication of public keys for firmware only loads signed kernels cases by threatening companies to otherwise take legal actions in Germany. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thursday 15 February 2007 12:34, [EMAIL PROTECTED] wrote: On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said: I agree, that's really what should happen. We solve this by marking modules as supported, partner supported, or unsupported, but in an insecure way, so partners and users could try to fake the support status of a module and/or remove status flags from Oopses, and cryptography wouldn't save us. Where cryptography *can* save you is that a partner or user can't fake a 'Suse Supported' signature without access to the Suse private key. No question about that. We actually already get this from rpm signatures. What would module signatures buy us? The kernel could then reliably determine that an unsigned module was loaded. But people could still fake their Oopses, or overwite the flags which indicate that a module's signature didn't match, so we still wouldn't reliably get at that information. Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thu, 15 Feb 2007 22:32:40 +0100, Adrian Bunk said: There are different opinions whether the complete source code of the GPLv2 includes in such cases public keys, making it questionable whether your example will survive at court in all jurisdictions. It's no less shaky than the whole EXPORT_SYMBOL_GPL-as-enforcement crock. :) E.g. remember that gpl-violations.org has already successfully enforced the publication of public keys for firmware only loads signed kernels cases by threatening companies to otherwise take legal actions in Germany. A court order for the publication of *public* keys? :) I think you meant private keys in both paragraphs above. And it's probably a non-issue the way Red Hat implemented it - they included a document on How to generate your own public/private key pair, which invokes commands that create a bitstring that you can then use to sign the entire applicable part of the kernel tree. The fact that it's not the *same* bitstring as they used is (IMHO) legally about as relevant as the fact that they compiled the tree with one release of GCC, included instructions on how to compile it, and I don't get a bitwise identical binary if I compile it with a different GCC release. Yes, you're still screwed if you only build *part* of the kernel tree and expect it to work - modules you sign won't load into their kernel, and vice versa. But that's the same problem as the old 2.4 You didn't do a make clean between rebuilds and you bugged out because different parts of the tree were built with different GCC releases. As distributed, you *can* build a working kernel from the pieces and instructions provided. pgpiSVLsNemH0.pgp Description: PGP signature
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thursday 15 February 2007 12:34, [EMAIL PROTECTED] wrote: On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said: I agree, that's really what should happen. We solve this by marking modules as supported, partner supported, or unsupported, but in an insecure way, so partners and users could try to fake the support status of a module and/or remove status flags from Oopses, and cryptography wouldn't save us. Where cryptography *can* save you is that a partner or user can't fake a 'Suse Supported' signature without access to the Suse private key. The user has control over the running kernel, and given enough time and clue, can circumvent any protection mechanism the vendor comes up with. And that's a good thing IMO, unless you believe in trusted computing and all those Bigbrotherisms some agencies want to put in your machines. So the user is running a system in some state that may or may not resemble what the vendor shipped. When the machine crashes, the user is free to munge the oops until it looks like a valid one. Someone mentioned in this context that you can sign the oops - but to do that you need a private key. And the whole point of this exercise is that the user does not have access to that key. So as far as support is concerned, you're back in square one. You cannot tell a genuine oops produced on a supported kernel from a doctored one produced on Joe Doe's Garage Kernel. Olaf -- Olaf Kirch| Anyone who has had to work with X.509 has probably [EMAIL PROTECTED] | experienced what can best be described as --+ ISO water torture. -- Peter Gutmann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 10:14:53PM -0800, Andreas Gruenbacher wrote: > On Wednesday 14 February 2007 21:45, Dave Jones wrote: > > well, the situation for external modules is no worse than usual. > > They still work, they just aren't signed. Which from a distributor point > > of view, is actually a nice thing, as they stick out like a sore thumb > > in oops reports with (U) markers :) > > I agree, that's really what should happen. We solve this by marking modules > as > supported, partner supported, or unsupported, but in an "insecure" way, so > partners and users could try to fake the support status of a module and/or > remove status flags from Oopses, and cryptography wouldn't save us. We could > try to sign Oopses which I guess you guys are doing. This whole issue hasn't > been a serious problem in the past though, and we generally try to trust > users not to play games on us. For the most part it works out. I've had users file oopses where they've editted out Tainted: P, and left in nvidia(U) for example :-) Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wednesday 14 February 2007 21:45, Dave Jones wrote: > well, the situation for external modules is no worse than usual. > They still work, they just aren't signed. Which from a distributor point > of view, is actually a nice thing, as they stick out like a sore thumb > in oops reports with (U) markers :) I agree, that's really what should happen. We solve this by marking modules as supported, partner supported, or unsupported, but in an "insecure" way, so partners and users could try to fake the support status of a module and/or remove status flags from Oopses, and cryptography wouldn't save us. We could try to sign Oopses which I guess you guys are doing. This whole issue hasn't been a serious problem in the past though, and we generally try to trust users not to play games on us. In the end, it all seems to boils down to a difference in philosophy. Thanks, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 09:35:40PM -0800, Andreas Gruenbacher wrote: > On Wednesday 14 February 2007 20:13, Dave Jones wrote: > > I've not investigated it, but I hear rumours that suse has something > > similar. > > Actually, no. We don't belive that module signing adds significant value, ok, then I was misinformed. > and it also doesn't work well with external modules. well, the situation for external modules is no worse than usual. They still work, they just aren't signed. Which from a distributor point of view, is actually a nice thing, as they stick out like a sore thumb in oops reports with (U) markers :) > (The external modules we really care about are GPL ones; it gives us a way > to update drivers without pushing out entirely new kernels.) external modules still compile, and run just fine. The signed modules code doesn't prevent loading of them unless the user decides to do so with a special boot option (which is no different really than say, reducing the cap-bound sysctl to prevent module loading). Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wednesday 14 February 2007 20:13, Dave Jones wrote: > I've not investigated it, but I hear rumours that suse has something > similar. Actually, no. We don't belive that module signing adds significant value, and it also doesn't work well with external modules. (The external modules we really care about are GPL ones; it gives us a way to update drivers without pushing out entirely new kernels.) Cheers, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 07:41:12PM -0800, Andrew Morton wrote: > 77 files changed, 9681 insertions(+), 10 deletions(-) > > just to be able to sign modules. > > Normally I'd collapse writhing in laughter, but.. > > > These patches have been in use by RHEL and Fedora kernels for years, and so > > have been thoroughly tested. > > so I guess there's an argument for merging them so we can send them back to > you guys. But there's also an argument to declare all this gunk a > vendor-only thing. How much pain would that cause? it needs rediffing pretty much every time the cryptoapi changes. On a good month that means once per point release, otherwise... One argument in its favour is aparently Red Hat isn't the only vendor with something like this. I've not investigated it, but I hear rumours that suse has something similar. Having everyone using the same code would be a win for obvious reasons. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, 14 Feb 2007 19:09:38 + David Howells <[EMAIL PROTECTED]> wrote: > These patches provide a GPG-based kernel module signing facility. Their use > is > not fully automated within the confines of the kernel build process because it > needs provision of keys from outside of the kernel before the kernel can be > compiled. > > The patches are: > > (1) A cut-down MPI library derived from GPG with error handling added. > > (2) Permit hash algorithms to hash kernel data defined by a virtual address > and a length rather than trying to use scattergather lists (which require > struct page pointers to be determined). > > (3) Add extra information to the per-arch ELF headers to more fully describe > the format of the ELF metadata. > > (4) Add module verification capabilities, including ELF metadata > verification. > > (5) Add a generic DSA signature checker. Given a SHA1 hash of the data to be > verified and a binary blob holding a GPG signature stream, this verifies > the signature using a built-in ring of public keys. > > (6) Add a module signature checker that applies signature checking to modules > on module load, checking the signature against the ring of public keys > compiled into the kernel. Grand total: 77 files changed, 9681 insertions(+), 10 deletions(-) just to be able to sign modules. Normally I'd collapse writhing in laughter, but.. > These patches have been in use by RHEL and Fedora kernels for years, and so > have been thoroughly tested. so I guess there's an argument for merging them so we can send them back to you guys. But there's also an argument to declare all this gunk a vendor-only thing. How much pain would that cause? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 09:59:37PM +, David Howells wrote: > Michael Halcrow <[EMAIL PROTECTED]> wrote: > > > Right now, eCryptfs just delegates its modular exponentiation > > operations to a userspace daemon. If RSA ever finds its way into the > > kernel, I might tweak eCryptfs to use that instead for some of the > > public key operations. > > Am I right in thinking that RSA uses many of the same MPI lib bits > as DSA? I would imagine so. Assuming we aren't having to hassle with key generation (eCryptfs takes care of that in userspace), then RSA is, more or less, a^b mod c (mpi_mulpowm() and friends). Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Michael Halcrow <[EMAIL PROTECTED]> wrote: > Right now, eCryptfs just delegates its modular exponentiation > operations to a userspace daemon. If RSA ever finds its way into the > kernel, I might tweak eCryptfs to use that instead for some of the > public key operations. Am I right in thinking that RSA uses many of the same MPI lib bits as DSA? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 07:40:57PM +, David Howells wrote: > Hashing, yes; encryption, yes; signature checking: no from what I > can see. > > It's possible that I can share code with eCryptFS, though at first > sight that doesn't seem to overlap with what I want to do. Right now, eCryptfs just delegates its modular exponentiation operations to a userspace daemon. If RSA ever finds its way into the kernel, I might tweak eCryptfs to use that instead for some of the public key operations. Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Linus Torvalds <[EMAIL PROTECTED]> wrote: > > (1) A cut-down MPI library derived from GPG with error handling added. > > Do we really need to add this? I presume you mean the MPI library specifically? If so, then yes. It's necessary to do DSA signature verification (or RSA for that matter). > Wouldn't it be much nicer to just teach people to use one of the existing > signature things that we need for _other_ cases anyway, and already have > merged? Existing signature things? I know not of such beasts, nor can I see them offhand. > (Of course, it's possible that none of the current crypto supports any > signature checking at all - I didn't actually look. In which case my > argument is pointless). Hashing, yes; encryption, yes; signature checking: no from what I can see. It's possible that I can share code with eCryptFS, though at first sight that doesn't seem to overlap with what I want to do. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, 14 Feb 2007, David Howells wrote: > > (1) A cut-down MPI library derived from GPG with error handling added. Do we really need to add this? Wouldn't it be much nicer to just teach people to use one of the existing signature things that we need for _other_ cases anyway, and already have merged? (Of course, it's possible that none of the current crypto supports any signature checking at all - I didn't actually look. In which case my argument is pointless). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, 14 Feb 2007, David Howells wrote: (1) A cut-down MPI library derived from GPG with error handling added. Do we really need to add this? Wouldn't it be much nicer to just teach people to use one of the existing signature things that we need for _other_ cases anyway, and already have merged? (Of course, it's possible that none of the current crypto supports any signature checking at all - I didn't actually look. In which case my argument is pointless). Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Linus Torvalds [EMAIL PROTECTED] wrote: (1) A cut-down MPI library derived from GPG with error handling added. Do we really need to add this? I presume you mean the MPI library specifically? If so, then yes. It's necessary to do DSA signature verification (or RSA for that matter). Wouldn't it be much nicer to just teach people to use one of the existing signature things that we need for _other_ cases anyway, and already have merged? Existing signature things? I know not of such beasts, nor can I see them offhand. (Of course, it's possible that none of the current crypto supports any signature checking at all - I didn't actually look. In which case my argument is pointless). Hashing, yes; encryption, yes; signature checking: no from what I can see. It's possible that I can share code with eCryptFS, though at first sight that doesn't seem to overlap with what I want to do. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 07:40:57PM +, David Howells wrote: Hashing, yes; encryption, yes; signature checking: no from what I can see. It's possible that I can share code with eCryptFS, though at first sight that doesn't seem to overlap with what I want to do. Right now, eCryptfs just delegates its modular exponentiation operations to a userspace daemon. If RSA ever finds its way into the kernel, I might tweak eCryptfs to use that instead for some of the public key operations. Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
Michael Halcrow [EMAIL PROTECTED] wrote: Right now, eCryptfs just delegates its modular exponentiation operations to a userspace daemon. If RSA ever finds its way into the kernel, I might tweak eCryptfs to use that instead for some of the public key operations. Am I right in thinking that RSA uses many of the same MPI lib bits as DSA? David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 09:59:37PM +, David Howells wrote: Michael Halcrow [EMAIL PROTECTED] wrote: Right now, eCryptfs just delegates its modular exponentiation operations to a userspace daemon. If RSA ever finds its way into the kernel, I might tweak eCryptfs to use that instead for some of the public key operations. Am I right in thinking that RSA uses many of the same MPI lib bits as DSA? I would imagine so. Assuming we aren't having to hassle with key generation (eCryptfs takes care of that in userspace), then RSA is, more or less, a^b mod c (mpi_mulpowm() and friends). Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, 14 Feb 2007 19:09:38 + David Howells [EMAIL PROTECTED] wrote: These patches provide a GPG-based kernel module signing facility. Their use is not fully automated within the confines of the kernel build process because it needs provision of keys from outside of the kernel before the kernel can be compiled. The patches are: (1) A cut-down MPI library derived from GPG with error handling added. (2) Permit hash algorithms to hash kernel data defined by a virtual address and a length rather than trying to use scattergather lists (which require struct page pointers to be determined). (3) Add extra information to the per-arch ELF headers to more fully describe the format of the ELF metadata. (4) Add module verification capabilities, including ELF metadata verification. (5) Add a generic DSA signature checker. Given a SHA1 hash of the data to be verified and a binary blob holding a GPG signature stream, this verifies the signature using a built-in ring of public keys. (6) Add a module signature checker that applies signature checking to modules on module load, checking the signature against the ring of public keys compiled into the kernel. Grand total: 77 files changed, 9681 insertions(+), 10 deletions(-) just to be able to sign modules. Normally I'd collapse writhing in laughter, but.. These patches have been in use by RHEL and Fedora kernels for years, and so have been thoroughly tested. so I guess there's an argument for merging them so we can send them back to you guys. But there's also an argument to declare all this gunk a vendor-only thing. How much pain would that cause? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 07:41:12PM -0800, Andrew Morton wrote: 77 files changed, 9681 insertions(+), 10 deletions(-) just to be able to sign modules. Normally I'd collapse writhing in laughter, but.. These patches have been in use by RHEL and Fedora kernels for years, and so have been thoroughly tested. so I guess there's an argument for merging them so we can send them back to you guys. But there's also an argument to declare all this gunk a vendor-only thing. How much pain would that cause? it needs rediffing pretty much every time the cryptoapi changes. On a good month that means once per point release, otherwise... One argument in its favour is aparently Red Hat isn't the only vendor with something like this. I've not investigated it, but I hear rumours that suse has something similar. Having everyone using the same code would be a win for obvious reasons. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wednesday 14 February 2007 20:13, Dave Jones wrote: I've not investigated it, but I hear rumours that suse has something similar. Actually, no. We don't belive that module signing adds significant value, and it also doesn't work well with external modules. (The external modules we really care about are GPL ones; it gives us a way to update drivers without pushing out entirely new kernels.) Cheers, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 09:35:40PM -0800, Andreas Gruenbacher wrote: On Wednesday 14 February 2007 20:13, Dave Jones wrote: I've not investigated it, but I hear rumours that suse has something similar. Actually, no. We don't belive that module signing adds significant value, ok, then I was misinformed. and it also doesn't work well with external modules. well, the situation for external modules is no worse than usual. They still work, they just aren't signed. Which from a distributor point of view, is actually a nice thing, as they stick out like a sore thumb in oops reports with (U) markers :) (The external modules we really care about are GPL ones; it gives us a way to update drivers without pushing out entirely new kernels.) external modules still compile, and run just fine. The signed modules code doesn't prevent loading of them unless the user decides to do so with a special boot option (which is no different really than say, reducing the cap-bound sysctl to prevent module loading). Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wednesday 14 February 2007 21:45, Dave Jones wrote: well, the situation for external modules is no worse than usual. They still work, they just aren't signed. Which from a distributor point of view, is actually a nice thing, as they stick out like a sore thumb in oops reports with (U) markers :) I agree, that's really what should happen. We solve this by marking modules as supported, partner supported, or unsupported, but in an insecure way, so partners and users could try to fake the support status of a module and/or remove status flags from Oopses, and cryptography wouldn't save us. We could try to sign Oopses which I guess you guys are doing. This whole issue hasn't been a serious problem in the past though, and we generally try to trust users not to play games on us. In the end, it all seems to boils down to a difference in philosophy. Thanks, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 10:14:53PM -0800, Andreas Gruenbacher wrote: On Wednesday 14 February 2007 21:45, Dave Jones wrote: well, the situation for external modules is no worse than usual. They still work, they just aren't signed. Which from a distributor point of view, is actually a nice thing, as they stick out like a sore thumb in oops reports with (U) markers :) I agree, that's really what should happen. We solve this by marking modules as supported, partner supported, or unsupported, but in an insecure way, so partners and users could try to fake the support status of a module and/or remove status flags from Oopses, and cryptography wouldn't save us. We could try to sign Oopses which I guess you guys are doing. This whole issue hasn't been a serious problem in the past though, and we generally try to trust users not to play games on us. For the most part it works out. I've had users file oopses where they've editted out Tainted: P, and left in nvidia(U) for example :-) Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
