linux-kernel - Re: [PATCH 1/2] VM/SELinux: require CAP_SYS_RAWIO for all mmap

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: <20090721170909.6182230c@lxorguk.ukuu.org.uk>
Date:	Tue, 21 Jul 2009 17:09:09 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
	linux-security-module@...r.kernel.org, sds@...ho.nsa.gov,
	jmorris@...ei.org, spender@...ecurity.net, dwalsh@...hat.com,
	cl@...ux-foundation.org, arjan@...radead.org, kyle@...artin.ca,
	cpardy@...hat.com, arnd@...db.de
Subject: Re: [PATCH 1/2] VM/SELinux: require CAP_SYS_RAWIO for all mmap_zero
 operations

> This just seemed reasonable, since the Kconfig default is 4096 that's
> what most people have anyway right?

Yes - its rather inadequate when there are multi-page objects floating
around to exploit (remember you only need writes through data pointers for
exploits not executable code)

> runcon -t wine_t [my exploit]
> win.
> 
> So now I have to stop allowing unconfined_t to specifically run things
> as wine_t.  Easy enough to get around
> 
> chcon -t wine_exec_t [my exploit]
> win.
> 
> Well crap, now I have to stop letting unconfined_t label things
> wine_exec_t.  Easy enough to get around if you can load it as an rpm
> (ok, this step is probably harder)

If I can load it as an rpm then I'm the superuser and I already won so
that case isn't too bad really is it ?

So far you've described in SELinux the equivalent of

"user must not be able to chown and setuid their files to someone else"

which was hardly news in 1970 ;)

> and hell, how do I know I can't just get wine some windows program to
> get win to map the page for me?

Mathematical absolutes don't work here. How do you know 4K is enough, 64K
is enough - you never do that either. You can only make it a lot harder.

> unconfined is such a monstrosity it's too hard to get a handle on.  Make
> everyone log in as user_t (man semanage) and you will be better (but I
> haven't proven it is safe...)

Ok.

> and you still could.  Just set mmap_min_addr = 0 and you get SELinux
> protection for confined domains.  I'll gladly add an selinux tunable if
> people like it so SELinux users who don't want to enforce the uid=0 rule
> can do exactly everything they can do today.
> 
> Someone on this list has to know a wine guru.  Seems to me there has to
> be a way that we can give wine CAP_SYS_RAWIO just long enough to map the
> page so non-SELinux users aren't left in the lurch they are today.

I did look - but wine doesn't simply wrap itself around an application,
run it and die. The wine execution model is rather more complicated and
the need to map page zero can thus pop up later on. Some of the other
users you can do this with, and most of the other ones like LRMI of
course are CAP_SYS_RAWIO *anyway* as the main user of this stuff is vm86
bios execution.

It's a really ugly problem that almost begs for better hardware
facilities (such as the multiple independent address spaces in some
processors)

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