>
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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,
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
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,
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
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
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
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
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).
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
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
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
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
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).
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
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
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
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
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
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
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
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)
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
60 matches
Mail list logo