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=commitdiff;h=ed0321895182ffb6ecf210e066d87911b270d587
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 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=commitdiff;h=ed0321895182ffb6ecf210e066d87911b270d587 > > 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 > Fedora-kernel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list
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=commitdiff;h=ed0321895182ffb6ecf210e066d87911b270d587 > > > > 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
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
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
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 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
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
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. -- dwmw2
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 -- Konrad Meyer <konrad@tylerc.org>
On Sat, 22 Dec 2007 03:55:49 -0800 Konrad Meyer <konrad@tylerc.org> 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. :PNo, 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
On Sat, 22 Dec 2007 10:00:34 +0000, David Woodhouse <dwmw2@infradead.org> 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