[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160712214226.GF3661@uranus.lan>
Date: Wed, 13 Jul 2016 00:42:26 +0300
From: Cyrill Gorcunov <gorcunov@...il.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>,
peterz@...radead.org, mingo@...hat.com, mhocko@...e.com,
keescook@...omium.org, linux-kernel@...r.kernel.org,
mguzik@...hat.com, bsegall@...gle.com, john.stultz@...aro.org,
oleg@...hat.com, matthltc@...ibm.com, akpm@...ux-foundation.org,
luto@...capital.net, vbabka@...e.cz, xemul@...tuozzo.com
Subject: Re: [PATCH] prctl: remove one-shot limitation for changing exe link
On Tue, Jul 12, 2016 at 08:29:33PM +0300, Cyrill Gorcunov wrote:
> On Tue, Jul 12, 2016 at 11:52:09AM -0500, Eric W. Biederman wrote:
> > >
> > > Persistent exe-link doesn't guarantee anything if you have rights to ptrace
> > > task and inject own code into (from security POV). So lets rip it out.
> > >
> > > Acked-by: Cyrill Gorcunov <gorcunov@...nvz.org>
> >
> > I believe the original concern was someone injecting a code into a
> > process and playing silly buggers with the exe link. Someone who does
> > not have ptrace capability.
>
> If you manage to inject code into a process, that's all, you're
> compromised, preventing changing exe-link several times wont help
> much I fear. Current limit -- one may change it once, Stas' patch
> simply removes this limitation. The ability to change it only _once_
> may be suitable for some kind of monitor daemon I guess but this
> monitor should detect any change in exe-link state and notify
> node's admin, otherwise it's simply useless.
>
> > It is completely not ok to change this until someone goes back to the
> > original conversation and looks at the original threat model, and
> > refutes it.
Btw, if the persistency of exe link is _that_ important (in which I'm
really doubting) we always can use some of sysctl flag on host which
would control it [by default it might be turned off but for those
who really rely on exelink status, for some reason, the sysctl might
be set up and prevent any exelink modification].
Powered by blists - more mailing lists