>
> 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
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 f
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 root
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(
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 a
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 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 E
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 a
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 s
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
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 all
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 p
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 r
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 le
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 mod
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 ad
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 advan
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 actuall
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) ma
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
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, an
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 bef
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 in
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 th
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 jus
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 hav
29 matches
Mail list logo
