Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > Serge Hallyn <serge.hallyn@xxxxxxxxxx> writes: > > > Quoting Daniel P. Berrange (berrange@xxxxxxxxxx): > >> IIUC, currently, in order to be able to invoke setns() the calling > >> process is required to have CAP_SYS_ADMIN capability. Alternatively > >> with user namespaces, access is allowed if the process' effective > >> uid matches the uid of the owner of the namespace. > >> > >> I have a scenario though that isn't dealt with by those rules. I have > >> a container that was spawned by uid == 0, and I have an unprivileged > >> process uid != 0 in the initial namespace that I wish to allow to enter > >> the namespaces associated with the container. > >> > >> With the CAP_SYS_ADMIN rule on setns(), it seems that the unprivileged > >> process will need to execute some setuid binary in order to gain the > >> CAP_SYS_ADMIN capability required to call setns(). > >> > >> Of course you can't call setns() without first obtaining a file > >> descriptor corresponding to the /proc/$CONTAINERPID/ns/XXXX namespace > >> you wish to join. This appears to require elevated privileges too. > >> > >> Is it not sufficient to rely on the permissions on the /proc/$PID/ns/XXX > >> file to control access to a namespace, and thus allow setns() without > >> a CAP_SYS_ADMIN check ? ie setns() is basically useless unless you > >> already have sufficient privileges to get a file descriptor for the > >> namespace, so why does setns need an additional privilege check beyond > >> that done at time of open() on the proc file. > >> > >> In my scenario this would allow for a privileged daemon to open the > >> /proc/$PID/ns/XXX file, and then pass the file descriptor back to the > >> unprivileged process using SCM_RIGHTS, which could then invoke setns(). > >> This kind of privilege separation is perferrable to requiring the > >> unprivileged process to run some kind of setuid program to gain the > >> CAP_SYS_ADMIN capability. > >> > >> Regards, > >> Daniel > > > > Hey Daniel, > > > > it's possible that as things settle down we can find ways to relax this, > > but note that this behavior was very specifically added by the commit > > below. Very unfortunate that this is a feature regression over the > > CONFIG_USER_NS=n case :( > > No this is not a feature regression over the CONFIG_USER_NS=n case. The > patch was a setns bug fix. The situation Daniel wants to use is > exploitable. > > Allowing an unprivileged user to call setns allows confusing suid root > processes. > > It is completely possible for Daniels situation to work of the > unprivileged user calls setns first. That is allowed. Oh, hm. I thought that in the thread leading up to this email, the original reporter said that in a kernel with CONFIG_USER_NS=n, an unprivileged user could setns(fd) to an fd sent by a privileged process, whereas the same situation with CONFIG_USER_NS=y was not allowed. I probably misunderstood. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
