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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7e0fb38c0906030922u3af8c2abi8a2cfdcd66151a5a@mail.gmail.com>
Date:	Wed, 3 Jun 2009 12:22:16 -0400
From:	Eric Paris <eparis@...isplace.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	"Larry H." <research@...reption.com>, linux-mm@...ck.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	pageexec@...email.hu
Subject: Re: Security fix for remapping of page 0 (was [PATCH] Change 
	ZERO_SIZE_PTR to point at unmapped space)

On Wed, Jun 3, 2009 at 11:38 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
>
> On Wed, 3 Jun 2009, Christoph Lameter wrote:
>
>> On Wed, 3 Jun 2009, Linus Torvalds wrote:
>>
>> > The point being that we do need to support mmap at zero. Not necessarily
>> > universally, but it can't be some fixed "we don't allow that".
>>
>> Hmmm... Depend on some capability? CAP_SYS_PTRACE may be something
>> remotely related?
>
> But as mentioned several times, we do have the system-wide setting in
> 'mmap_min_addr' (that then can be overridden by CAP_SYS_RAWIO, so in that
> sense a capability already exists).
>
> It defaults to 64kB in at least the x86 defconfig files, but to 0 in the
> Kconfig defaults. Also, for some reason it has a "depends on SECURITY",
> which means that if you just default to the old-style unix security you'll
> lose it.
>
> So there are several ways to disable it by mistake. I don't know what
> distros do.

Fedora has it on.

As I recall the only need for CONFIG_SECURITY is for the ability to
override the check.

I think I could probably pretty cleanly change it to use
CAP_SYS_RAWIO/SELinux permissions if CONFIG_SECURITY and just allow it
for uid=0 in the non-security case?  Deny it for everyone in the
non-security case and make them change the /proc tunable if they need
it?

-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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ