Message-ID: <20090414213934.GB17986@us.ibm.com>
Date:	Tue, 14 Apr 2009 16:39:34 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Oren Laadan <orenl@...columbia.edu>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	akpm@...ux-foundation.org, containers@...ts.linux-foundation.org,
	xemul@...allels.com, mingo@...e.hu, hch@...radead.org,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/30] C/R OpenVZ/Virtuozzo style

Quoting Alexey Dobriyan (adobriyan@...il.com):
> > >>> * not having CAP_SYS_ADMIN on restart(2)
> > >> Surely you have read already on the containers mailing list that
> > >> for the *time being* we attempt to get as far as possible without
> > >> requiring root privileges, to identify security hot-spots.
> > > 
> > > More or less everything is hotspot.
> > 
> > Going back to my example of a subtree above: what sort of security
> > issues you would have here, assuming all restart operations go via
> > the usual security checks just like syscalls, and we take special
> > care about values we allow as input, e.g. cpu debug registers etc ?
> 
> This is like asking if everything goes through correct security checks
> how will you screw something up. Everything won't go via usual security
> checks.

(Everything which doesn't go through usual security checks gets special
security checks...)

You are asking an administrator to give users setuid-root programs when
they wouldn't otherwise need it.  So now not only is there potential of
security holes in kernel code which was written under the assumption
that 'hey you have privilege when you run this so are trusted'.  You
also have more people running probably even less-vetted userspace code
with privilege.

> Just for giggles, writing exploit for localhost hole becomes easier --
> you very effectively turn off all randomization kernel does because VMA
> boundaries comes from disk.

Hmm, interesting point.

But again you're going on a naive assumption that if restart requires
privilege, only trusted users will use it.  Rather, in the real world,
I claim that unprivileged users will be given more privilege than they
need.

> > BTW, the checks for cpu registers and other values for sanity is
> > needed anyway to ensure that the kernel freak out if wrong input
> > is fed (maliciously or by mistake).
> 
> Out of head, mucking with registers of setuid program is no-no.
> As well as mucking with dirty data of setuid program.

No argument there, no idea why you bring this up.

> Capabilities will come from disk.

Sure.

> Many EPERM checks are suspect.

No idea what you're saying.

> do_arch_prctl(ARCH_SET_GS) has TASK_SIZE check, do you?

We don't support x86_64 yet :)

> > >> And surely you have read there the observation that for the general
> > >> case root privileges will probably be inevitable.
> > >>
> > >> And surely you don't seriously think that adding this check changes
> > >> the "design"...
> > > 
> > > This is not about design now, this is about if you allow restart(2) for
> > > everyone, you open kernel to very very high number of holes of all
> > > types. I wrote about it in reply to your code.
> > > 
> > 
> > And there are many examples where this is not the case. The current
> > patchset (v14-rc3), for example, to the best of my knowledge, does
> > not have such issues (well, need to add checks for validity of regs
> > but there is a FIXME comment :)
> 
> And such an obvious issue like segmentt RPL is fixed? :-)

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