From: sds@tycho.nsa.gov (Stephen Smalley) Date: Fri, 05 Oct 2012 12:59:02 -0400 Subject: [refpolicy] Non root users fail to login after switch to latest kernel In-Reply-To: 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> Message-ID: <1349456342.16023.58.camel@moss-pluto.epoch.ncsc.mil> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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. -- Stephen Smalley National Security Agency