Quoting chris hyser (chris.hyser@xxxxxxxxxx): > On 11/06/2017 10:23 PM, Serge E. Hallyn wrote: > >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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
