Message-Id: <1248191833.2654.320.camel@localhost>
Date:	Tue, 21 Jul 2009 11:57:13 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
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

On Tue, 2009-07-21 at 16:38 +0100, Alan Cox wrote:
> > turns it off for the whole system when you install WINE.  This patch
> > doesn't change that fact.  All it does is add that requirement to
> > SELinux systems that already exists on non-selinux systems.
> 
> Prior to this an SELinux system could implement sensible security. 

Sadly, it couldn't reasonably  :(

> > > Am I missing something here, this "solution" sounds completely brain
> > > dead ?
> > 
> > Well, with patch 2/2 you still get your SELinux protections (only for 1
> > page) even if you disable it for the whole system.  So in the end, you
> > have better protection than you have today with this series....
> 
> We know one page isn't sufficient. That has been seen from some exploit
> cases.

Yet another tunable is easy, and what I mentioned yesterday, i'd
probably put it in /selinux since it would be an selinux only thing.
This just seemed reasonable, since the Kconfig default is 4096 that's
what most people have anyway right?

> So this looks to me like a regression in features, that makes the system
> less secure and doesn't solve anything at all.
> 
> Whereas if you just set the default SELinux user confinement to allow
> everything but mapping low pages you wouldn't actually need to mess up
> the kernel ?

Herein lies the problem.  It sounds easy to do, but isn't.  Sure I can
remove mmap_zero from unconfined_t (and actually it should be that way
in rawhide by default by now) but like I said, it's not even a speed
bump to be that broad.  

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)

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

Finding all of the contortions that an unconfined user can do is nearly
impossible.  It's one of the reasons a lot of selinux people argued
against the unconfined domain to begin with.  There are some analysis
tools used in high security environments to prove security goals but
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...)

> Currently I have low page protection and I don't have to run wine as
> CAP_SYS_RAWIO (which comes in the "sucidial ideas") category. I consider
> the loss of that ability a regression.

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.

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