lkml.org 
[lkml]   [2015]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [capabilities] Allow normal inheritance for a configurable set of capabilities
Quoting Andy Lutomirski (luto@amacapital.net):
> On Mon, Feb 2, 2015 at 9:12 AM, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
> > A key concept behind posix capabilities is that the privilege comes from
> > both the person and the file being executed. As you say below basically
> > anything can be executed by the program so that is completely violated.
> >
> > Still, it's not that different from mmapping some arbitrary code and
> > jumping into it whlie retaining caps.
> >
> > If we were to support such a feature, I'm thinking I'd prefer we do
> > it somewhat analogously to the capability bounding set. Perhaps add a
> > ambient_inh_caps set or something. Empty by default. To add caps to it you
> > must have the cap in your permitted set already. (Ok to do in a user
> > namespace). Then at exec,
> >
> > pP' = (X & fP) | (pI & fI) | (pI & pA)
> >
> > pA being your ambient_inh set
> >
> > Not saying this is a good idea necessarily, but worth thinking about.
>
> This isn't obviously a bad formulation. We could control pA using some syscall.

My first thought was prctl (since we have PR_CAPBSET_DROP)

> Another formulation would be a single per-user-ns or
> inherited-per-process bit that sets fI to the full set regardless of
> file caps. Dealing with the file effective bit will be an added
> complication, as will dealing with setuid binaries.
>
> How many of you will be at LSF/MM? This might be a decent topic.

I'm not scheduled to be there.


\
 
 \ /
  Last update: 2015-02-02 19:21    [W:0.114 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site