linux-kernel - Re: mmap_min_addr and your local LSM (ok, just SELinux)

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: <f73f7ab80907272028y3b9451b4s4997308b6d9ec79a@mail.gmail.com>
Date:	Mon, 27 Jul 2009 23:28:09 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	James Morris <jmorris@...ei.org>,
	James Carter <jwcart2@...ho.nsa.gov>,
	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
	Stephen Smalley <sds@...ho.nsa.gov>, spender@...ecurity.net,
	Daniel J Walsh <dwalsh@...hat.com>, cl@...ux-foundation.org,
	Arjan van de Ven <arjan@...radead.org>, kees@...flux.net,
	Chad Sellers <csellers@...sys.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	mingo@...e.hu
Subject: Re: mmap_min_addr and your local LSM (ok, just SELinux)

On Mon, Jul 27, 2009 at 20:19, Alan Cox<alan@...rguk.ukuu.org.uk> wrote:
> A dumb question perhaps, but while addling my brain over the tty layer I
> was wondering if for the specific case of jump through NULL (which seems
> to be the most common but by no means only problem case that gets
> exploited) is there any reason we can't set a default breakpoint for
> executing 0 and fix that up as a trap in the kernel ?
>
> Even user code that needs zero page mapped such as BIOS hackery doesn't
> actually jump through zero often if ever, and would be a userspace not a
> kernel space trap source so could be fixed up.
>
> Just a random "I've been staring at code too long today" thought ?

Alternatively, since such emulation code is almost certainly not
performance sensitive, perhaps it's possible to go the kmemcheck-style
route?  We could probably "allow" userspace mappings of pages below
mmap_min_addr for unprivileged processes by trapping and
single-stepping the appropriate memory access instructions.

Every time anything tries to access that memory it would trigger a
fault; if the code is in kernel space we BUG() and dump a nastygram to
dmesg.  For anything else, we either temporarily map the page and
single-step or simply emulate the instruction.  Sure, it might be slow
as hell... but the unprivileged use-cases seem to be few and
far-between.

Cheers,
Kyle Moffett
--
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/