Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Arjan van de Ven
> > 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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Dave Jones
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Pavel Machek
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Pavel Machek
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Bodo Eggert
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Bodo Eggert
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Pavel Machek
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Pavel Machek
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Dave Jones
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Arjan van de Ven
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Olaf Kirch
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Valdis . Kletnieks
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Andreas Gruenbacher
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Adrian Bunk
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Indan Zupancic
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Adrian Bunk
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Roman Zippel
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Valdis . Kletnieks
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Valdis . Kletnieks
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 >

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread David Lang
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Roman Zippel
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread David Howells
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Roman Zippel
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Roman Zippel
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread David Howells
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Roman Zippel
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread David Lang
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Valdis . Kletnieks
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Valdis . Kletnieks
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Roman Zippel
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Adrian Bunk
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Indan Zupancic
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Adrian Bunk
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Andreas Gruenbacher
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Valdis . Kletnieks
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Olaf Kirch
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Dave Jones
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Andreas Gruenbacher
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)

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Dave Jones
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,

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Andreas Gruenbacher
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Dave Jones
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,

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Andrew Morton
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Michael Halcrow
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread David Howells
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Michael Halcrow
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread David Howells
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).

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Linus Torvalds
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

[PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread David Howells
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

[PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread David Howells
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Linus Torvalds
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread David Howells
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).

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Michael Halcrow
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread David Howells
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Michael Halcrow
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Andrew Morton
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Dave Jones
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Andreas Gruenbacher
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Dave Jones
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

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Andreas Gruenbacher
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)

Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Dave Jones
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