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
13 matches
Mail list logo
