From: sds@tycho.nsa.gov (Stephen Smalley) Date: Fri, 05 Oct 2012 12:24:52 -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> Message-ID: <1349454292.16023.51.camel@moss-pluto.epoch.ncsc.mil> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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. -- Stephen Smalley National Security Agency