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-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
