enable null pointer hardening by default

[Eric Paris]

I'd like to see the fedora kernel enable the null pointer hardening work
I did upstream by default.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif...

Upstream refused to turn it on as it is known to break non-root users of
dosemu and they felt very strongly that not one user could break.  It
can be easily disabled with an entry in sysctl.conf for any such users.
Certainly turning this on is something we would want to release note in
F9 (which I don't know the process to do)

This must not be applied to F8 until at least after the rebase to 2.6.24
as the 2.6.23 implementation of my hardening work is known buggy and
causes unneeded issues.

Would anyone have a problem carrying this patch in fedora?  This would
be a forever fedora'ism.

---

security/security.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/security/security.c b/security/security.c
index 0e1f1f1..61787bb 100644
--- a/security/security.c
+++ b/security/security.c
@@ -23,7 +23,7 @@ extern struct security_operations dummy_security_ops;
 extern void security_fixup_ops(struct security_operations *ops);

struct security_operations *security_ops;	/* Initialized to NULL */
-unsigned long mmap_min_addr;		/* 0 means no protection */
+unsigned long mmap_min_addr = 65536;		/* protect first 64k */

static inline int verify(struct security_operations *ops)
 {

[Eric Sandeen]

Eric Paris wrote:
> I'd like to see the fedora kernel enable the null pointer hardening work
> I did upstream by default.
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif...
>
> Upstream refused to turn it on as it is known to break non-root users of
> dosemu and they felt very strongly that not one user could break.  It
> can be easily disabled with an entry in sysctl.conf for any such users.
> Certainly turning this on is something we would want to release note in
> F9 (which I don't know the process to do)
>
> This must not be applied to F8 until at least after the rebase to 2.6.24
> as the 2.6.23 implementation of my hardening work is known buggy and
> causes unneeded issues.
>
> Would anyone have a problem carrying this patch in fedora?  This would
> be a forever fedora'ism.

Couldn't this default value be a kernel config option?
(CONFIG_DEFAULT_MMAP_MIN_ADDR) or something less verbose...

-Eric
> security/security.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/security/security.c b/security/security.c
> index 0e1f1f1..61787bb 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -23,7 +23,7 @@ extern struct security_operations dummy_security_ops;
>  extern void security_fixup_ops(struct security_operations *ops);
>
> struct security_operations *security_ops;	/* Initialized to NULL */
> -unsigned long mmap_min_addr;		/* 0 means no protection */
> +unsigned long mmap_min_addr = 65536;		/* protect first 64k */
>
> static inline int verify(struct security_operations *ops)
>  {
>
> Fedora-kernel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-kernel-list

[Eric Paris]

On Thu, 2007-12-13 at 10:07 -0600, Eric Sandeen wrote:
> Eric Paris wrote:
> > I'd like to see the fedora kernel enable the null pointer hardening work
> > I did upstream by default.
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif...
> >
> > Upstream refused to turn it on as it is known to break non-root users of
> > dosemu and they felt very strongly that not one user could break.  It
> > can be easily disabled with an entry in sysctl.conf for any such users.
> > Certainly turning this on is something we would want to release note in
> > F9 (which I don't know the process to do)
> >
> > This must not be applied to F8 until at least after the rebase to 2.6.24
> > as the 2.6.23 implementation of my hardening work is known buggy and
> > causes unneeded issues.
> >
> > Would anyone have a problem carrying this patch in fedora?  This would
> > be a forever fedora'ism.
>
> Couldn't this default value be a kernel config option?
> (CONFIG_DEFAULT_MMAP_MIN_ADDR) or something less verbose...

Sounds like a better idea to me.  I'll push something like that
upstream.  And when you see it in a distro near you, lets turn it on!

-Eric

[Kyle McMartin]

Hi Eric,

On Thu, Dec 13, 2007 at 10:58:38AM -0500, Eric Paris wrote:
> Would anyone have a problem carrying this patch in fedora?  This would
> be a forever fedora'ism.

Wouldn't it be better to just use sysctl in an init script to turn it on
during boot (or, optionally, not.) as opposed to carrying a patch
perpetually?

regards,
    Kyle

[Eric Paris]

On Thu, 2007-12-13 at 11:28 -0500, Kyle McMartin wrote:
> Hi Eric,
>
> On Thu, Dec 13, 2007 at 10:58:38AM -0500, Eric Paris wrote:
> > Would anyone have a problem carrying this patch in fedora?  This would
> > be a forever fedora'ism.
>
> Wouldn't it be better to just use sysctl in an init script to turn it on
> during boot (or, optionally, not.) as opposed to carrying a patch
> perpetually?

I actually talked to the sysctl.conf owner first who said "if it is a
good default for everyone turn it on in the kernel"

which i tended to agree with.  But I like Eric's way of enabling it
better, especially since now every distro will have to choose to
enable/disable rather than just having it ignorable.

-Eric

[Kyle McMartin]

On Thu, Dec 13, 2007 at 11:31:30AM -0500, Eric Paris wrote:
> I actually talked to the sysctl.conf owner first who said "if it is a
> good default for everyone turn it on in the kernel"

Ah, I meant in a regular init script and using /etc/sysconfig/security
or something.
> which i tended to agree with.  But I like Eric's way of enabling it
> better, especially since now every distro will have to choose to
> enable/disable rather than just having it ignorable.

Yeah, config option upstream is definitely the sanest way forward. :)

cheers, Kyle

[Eric Sandeen]

Eric Paris wrote:
> On Thu, 2007-12-13 at 11:28 -0500, Kyle McMartin wrote:
> > Hi Eric,
> >
> > On Thu, Dec 13, 2007 at 10:58:38AM -0500, Eric Paris wrote:
> > > Would anyone have a problem carrying this patch in fedora?  This would
> > > be a forever fedora'ism.
> >
> > Wouldn't it be better to just use sysctl in an init script to turn it on
> > during boot (or, optionally, not.) as opposed to carrying a patch
> > perpetually?
>
> I actually talked to the sysctl.conf owner first who said "if it is a
> good default for everyone turn it on in the kernel"
>
> which i tended to agree with.  But I like Eric's way of enabling it
> better, especially since now every distro will have to choose to
> enable/disable rather than just having it ignorable.

Having a sysctl to change it post-boot if desired may also still make
sense, though?  I guess it's sort of analogous to how selinux can be
KConfig'd in certain ways, and later modified runtime.

-Eric

[Eric Paris]

On Thu, 2007-12-13 at 11:03 -0600, Eric Sandeen wrote:
> Eric Paris wrote:
> > On Thu, 2007-12-13 at 11:28 -0500, Kyle McMartin wrote:
> > > Hi Eric,
> > >
> > > On Thu, Dec 13, 2007 at 10:58:38AM -0500, Eric Paris wrote:
> > > > Would anyone have a problem carrying this patch in fedora?  This would
> > > > be a forever fedora'ism.
> > >
> > > Wouldn't it be better to just use sysctl in an init script to turn it on
> > > during boot (or, optionally, not.) as opposed to carrying a patch
> > > perpetually?
> >
> > I actually talked to the sysctl.conf owner first who said "if it is a
> > good default for everyone turn it on in the kernel"
> >
> > which i tended to agree with.  But I like Eric's way of enabling it
> > better, especially since now every distro will have to choose to
> > enable/disable rather than just having it ignorable.
>
> Having a sysctl to change it post-boot if desired may also still make
> sense, though?  I guess it's sort of analogous to how selinux can be
> KConfig'd in certain ways, and later modified runtime.

Absolutely the sysctl is always going to be there (it already
is /proc/sys/vm/mmap_min_addr).

-Eric

[David Woodhouse]

On Thu, 2007-12-13 at 10:58 -0500, Eric Paris wrote:
> -unsigned long mmap_min_addr;		/* 0 means no protection */
> +unsigned long mmap_min_addr = 65536;		/* protect first 64k */

64kB would be 64000. If you mean 65536, it's 64KiB.

[Conrad Meyer]

Quoth David Woodhouse:
> On Thu, 2007-12-13 at 10:58 -0500, Eric Paris wrote:
> > -unsigned long mmap_min_addr;		/* 0 means no protection */
> > +unsigned long mmap_min_addr = 65536;		/* protect first 64k */
>
> 64kB would be 64000. If you mean 65536, it's 64KiB.

KiB don't exist. If you mean 65536, it's 64 kiB. :P

[Josh Boyer]

On Sat, 22 Dec 2007 03:55:49 -0800
Konrad Meyer  wrote:
> Quoth David Woodhouse:
> > On Thu, 2007-12-13 at 10:58 -0500, Eric Paris wrote:
> > > -unsigned long mmap_min_addr;		/* 0 means no protection */
> > > +unsigned long mmap_min_addr = 65536;		/* protect first 64k */
> >
> > 64kB would be 64000. If you mean 65536, it's 64KiB.
>
> KiB don't exist. If you mean 65536, it's 64 kiB. :P

No, it's KiB.

http://www.iec.ch/zone/si/si_bytes.htm

And now that we're all done being pedantic, let's get back to fixing
bugs and stuff.

josh

[Pete Zaitcev]

On Sat, 22 Dec 2007 10:00:34 +0000, David Woodhouse  wrote:
> On Thu, 2007-12-13 at 10:58 -0500, Eric Paris wrote:
> > -unsigned long mmap_min_addr;		/* 0 means no protection */
> > +unsigned long mmap_min_addr = 65536;		/* protect first 64k */
>
> 64kB would be 64000. If you mean 65536, it's 64KiB.

Not in my code.

Frankly, there are few dumber things than kibibits in computing.

-- Pete