From: snijsure@grid-net.com (Subodh Nijsure) Date: Fri, 5 Oct 2012 16:57:17 +0000 Subject: [refpolicy] Non root users fail to login after switch to latest kernel In-Reply-To: <1349455583.16023.56.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> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com >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. I will take this thread to linux-security and attach my kernel config file. Thanks. -Subodh