[an error occurred while processing this directive]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

[an error occurred while processing this directive]

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1181078927.3978.42.camel@localhost.localdomain>
Date:	Tue, 05 Jun 2007 17:28:47 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Alan Cox <alan@...hat.com>
Cc:	James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	selinux@...ho.nsa.gov, drepper@...hat.com, roland@...hat.com,
	arjan@...radead.org, mingo@...e.hu, viro@...iv.linux.org.uk,
	chrisw@...hat.com, sds@...ho.nsa.gov, sgrubb@...hat.com
Subject: Re: [PATCH] Protection for exploiting null dereference using mmap

On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
> On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
> > This should be an unsigned long.
> > 
> > I wonder if the default should be for this value to be zero (i.e. preserve 
> > existing behavior).  It could break binaries, albeit potentially insecure 
> 
> Agreed - DOSemu type apps and lrmi need to map at zero for vm86

While I understand, there are a few users who will have problems with
this default are we really better to not provide this defense in depth
for the majority of users and let those with problems turn it off rather
than provide no defense by default?  I could even provide a different
default for SELinux and non-SELinux if anyone saw value in that?  But if
others think that off default is  best I'll send another patch shortly
with the unsigned long fix and the default set to 0.  My hope is then
that distros will figure out to turn this on.

-Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/