Quoting chris hyser (chris.hyser-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org):

On 11/06/2017 10:23 PM, Serge E. Hallyn wrote:

quoted

I think I definately prefer what I mentioned in the email to Boris.
Basically a "permanent capability bounding set".  The normal bounding
set gets reset to a full set on every new user_ns creation.  In this
proposal, it would instead be set to the calling task's permanent
capability set, which starts (at boot) full, and which privileged
tasks can pull capabilities out of.

Actually, this may solve a similar problem I've been looking at. The
idea was basically at strategic points in the kernel (possibly LSM
hook sites, still evaluating, and probably syscall entry) validate
that a task has not "magically" acquired capabilities that it or
parent specifically said it cannot have and then take some action
like say killing it immediately. Using your terms, basically make
the "permanent capability set" a write-once privilege escalation
defense. To handle the 0-day threat, perhaps make it writable but
only with more "restrictive" values.

Would the existing capability bounding set not suffice for that?

The 'permanent' bounding set turns out to not be a good fit for
the problem being discussed in this thread, but please feel free
to start a new thread if you want to discuss your use case.