On Nov 20, 2014 7:16 AM, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> wrote: > > Josh Triplett <josh@xxxxxxxxxxxxxxxx> writes: > > > Analogous to the supplementary GID list, the supplementary UID list > > provides a set of additional user credentials that a process can act as. > > A process with CAP_SETUID can set its UID list arbitrarily; a process > > without CAP_SETUID can only reduce its UID list. > > > > This allows each user to have a set of UIDs that they can then use to > > further sandbox individual child processes without first escalating to > > root to change UIDs. For instance, a PAM module could give each user a > > block of UIDs to work with. > > A couple of quick comments on this patch. > > 1) user namespaces already allow you to do this. I thought you could only map your fsuid. Can you set fsuid to a supplementary group? > > 2) After having looked at the group case I am afraid this intersects in > an unfortunate way with user namespaces. > > 3) This intersects in a very unfortunate way with setresuid. > Applications that today know they are dropping all privileges > won't be dropping all privielges with this change. Which sounds like > a recipe for a security exploit to me. > > Eric > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
