From: sds@tycho.nsa.gov (Stephen Smalley) Date: Fri, 05 Oct 2012 13:07:19 -0400 Subject: [refpolicy] Non root users fail to login after switch to latest kernel In-Reply-To: <1349456342.16023.58.camel@moss-pluto.epoch.ncsc.mil> References: ,<1349445114.16023.33.camel@moss-pluto.epoch.ncsc.mil> <1349454292.16023.51.camel@moss-pluto.epoch.ncsc.mil> ,<1349455583.16023.56.camel@moss-pluto.epoch.ncsc.mil> <1349456342.16023.58.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <1349456839.16023.60.camel@moss-pluto.epoch.ncsc.mil> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Fri, 2012-10-05 at 12:59 -0400, Stephen Smalley wrote: > On Fri, 2012-10-05 at 16:57 +0000, Subodh Nijsure wrote: > > >On Fri, 2012-10-05 at 12:24 -0400, Stephen Smalley wrote: > > >> On Fri, 2012-10-05 at 15:17 +0000, Subodh Nijsure wrote: > > >> > On Fri, 2012-10-05 at 03:34 +0000, Subodh Nijsure wrote: > > >> > >> Hello, > > >> > >> > > >> > >> We have been running SELinux on our embedded platform for almost 18 months. > > >> > >> We have been using kernel revision - 2.6.31. Since our platform only has 64MB > > >> > >> memory we decided roll out our own policy. > > >> > >> > > >> > >> Recently we have upgrade our linux kernel to version 3.5-rc4 again with our > > >> > >> policy every thing is working, except one thing, login for any user other > > >> > >> than root doesn't work. > > >> > >> > > >> > >> Login at console works if I apply change shown below to commoncap.c, which not > > >> > >> exactly correct. > > >> > >> > > >> > >> ------------------- > > >> > >> diff --git a/security/commoncap.c b/security/commoncap.c > > >> > >> index 6dbae46..074cd74 100644 > > >> > >> --- a/security/commoncap.c > > >> > >> +++ b/security/commoncap.c > > >> > >> @@ -83,7 +83,7 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns, > > >> > >> > > >> > >> /* Do we have the necessary capabilities? */ > > >> > >> if (targ_ns == cred->user_ns) > > >> > >> - return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM; > > >> > >> + return cap_raised(cred->cap_effective, cap) ? 0 : 0; > > >> > >> > > >> > >> /* Have we tried all of the parent namespaces? */ > > >> > >> if (targ_ns == &init_user_ns) > > >> > >> ------------------- > > >> > >> > > >> > >> So it looks like the users definition is missing some capabilities? > > >> > >> I don't even see any avc messages. > > >> > > > >> > >Unless you are using them, I'd recommend disabling user namespaces in > > >> > >your kernel. They are marked as experimental. This has nothing to do > > >> > >with SELinux. CONFIG_USER_NS=n > > >> > > > >> > Actually CONFIG_USER_NS is not set in the kernel configuration and its off by default. > > >> > Also I have verified that it is not defined by adding a check in kernel source file (#ifdef CONFIG_USER_NS / #error "CONFIG_USER_NS_DEFINED")... > > >> > > > >> > So CONFIG_USER_NS=y doesn't appear to be issue? > > >> > > > >> > It appears that if USER_NS is not defined then the kernel uses the init_user_ns should I be assigning capabilities to "initrc" user in my policy? > > >> > > > >> > Should I move this question to linux-security instead of selinux? > > >> > > >> Can you confirm that it happens even if SELinux is permissive? > > >> Because your patch has nothing to do with SELinux. > > >> If it happens even with SELinux in permissive, then yes, I'd take it to > > >> linux-security-module. > > > > > >Also, you should check whether it happens with an actual released > > >kernel, not just an -rc kernel. 3.5.5 or 3.6 > > > > > Indeed I get same behavior even if SELINUX is in permissive mode. > > > > I will try do run things with older kernels, it may take me some time to figure this out, platform (ARM MX28) depends on some of the latest device-tree stuff to run. > > 3.5.5 or 3.6.0 (both available from kernel.org) are newer than 3.5-rc4 > (a release candidate for 3.5, before 3.5.0 was released), so you > shouldn't have a problem testing them. Also, it would help to know exactly what called cap_capable() and with what arguments when it failed. Maybe call dump_stack() from cap_capable() in the EPERM case? -- Stephen Smalley National Security Agency