public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov,
	linux-security-module@vger.kernel.org, sds@tycho.nsa.gov,
	jmorris@namei.org, spender@grsecurity.net, dwalsh@redhat.com,
	cl@linux-foundation.org, arjan@infradead.org, kyle@mcmartin.ca,
	cpardy@redhat.com, arnd@arndb.de
Subject: Re: [PATCH 1/2] VM/SELinux: require CAP_SYS_RAWIO for all mmap_zero operations
Date: Tue, 21 Jul 2009 11:57:13 -0400	[thread overview]
Message-ID: <1248191833.2654.320.camel@localhost> (raw)
In-Reply-To: <20090721163813.0cb5d7ab@lxorguk.ukuu.org.uk>

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.


  reply	other threads:[~2009-07-21 15:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-21 14:41 [PATCH 1/2] VM/SELinux: require CAP_SYS_RAWIO for all mmap_zero operations Eric Paris
2009-07-21 14:42 ` [PATCH 2/2] SELinux: selinux_file_mmap always enforce mapping the 0 page Eric Paris
2009-07-21 15:04 ` [PATCH 1/2] VM/SELinux: require CAP_SYS_RAWIO for all mmap_zero operations Alan Cox
2009-07-21 15:18   ` Eric Paris
2009-07-21 15:38     ` Alan Cox
2009-07-21 15:57       ` Eric Paris [this message]
2009-07-21 16:09         ` Alan Cox
2009-07-21 16:23           ` Eric Paris
2009-07-21 16:30             ` Alan Cox
2009-07-29 15:06       ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1248191833.2654.320.camel@localhost \
    --to=eparis@redhat.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=arnd@arndb.de \
    --cc=cl@linux-foundation.org \
    --cc=cpardy@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=jmorris@namei.org \
    --cc=kyle@mcmartin.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=spender@grsecurity.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox