Quoting Andy Lutomirski ([email protected]): > On Mon, Feb 2, 2015 at 9:12 AM, Serge Hallyn <[email protected]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
