On Fri, Sep 28, 2018 at 1:43 AM James Morris <jmorris@xxxxxxxxx> wrote: > On Thu, 27 Sep 2018, Schaufler, Casey wrote: > > > > On 9/27/2018 2:45 PM, James Morris wrote: > > > > > On Wed, 26 Sep 2018, Casey Schaufler wrote: > > > > > > > > > >> + /* > > > > >> + * Namespace checks. Considered safe if: > > > > >> + * cgroup namespace is the same > > > > >> + * User namespace is the same > > > > >> + * PID namespace is the same > > > > >> + */ > > > > >> + if (current->nsproxy) > > > > >> + ccgn = current->nsproxy->cgroup_ns; > > > > >> + if (p->nsproxy) > > > > >> + pcgn = p->nsproxy->cgroup_ns; > > > > >> + if (ccgn != pcgn) > > > > >> + return -EACCES; > > > > >> + if (current->cred->user_ns != p->cred->user_ns) > > > > >> + return -EACCES; > > > > >> + if (task_active_pid_ns(current) != task_active_pid_ns(p)) > > > > >> + return -EACCES; > > > > >> + return 0; > > > > > I really don't like the idea of hard-coding namespace security semantics > > > > > in an LSM. Also, I'm not sure if these semantics make any sense. > > > > > > > > Checks on namespaces where explicitly requested. > > > > > > By whom and what is the rationale? > > > > The rationale is to protect containers. Since those closest thing > > there is to a definition of containers is "uses namespaces" that > > becomes the focus. Separating them out does not make too much > > sense as I would expect someone concerned with one to be concerned > > with all. > > A lot of people will not be using user namespaces due to security > concerns, Ugh. > so with this hard-coded logic, you are saying this case is > 'safe' in a sidechannel context. > > Which hints at the deeper issue that containers are a userland > abstraction. Protection of containers needs to be defined by userland > policy. Or just compare mount namespaces additionally/instead. I think that containers will always use those, because AFAIK nobody uses chroot() for containers, given that the kernel makes absolutely no security guarantees about chroot(). _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
