When compiling selinux-small-2003011510-r3 two problems arise. The most serious is that newrole isn't compiled with USE_PAM and isn't installed set UID root. This prevents newrole from functioning when in enforcing mode. The other error is this, seen during an ebuild: /usr/sbin/ebuild.sh: line 43: cd: /var/tmp/portage/selinux-small-2003011510-r3/work/policy: No such file or directory It's a path problem in the ebuild.
Created attachment 11569 [details, diff] Patch to selinux-small-2003011510-r3 Patch to -r3 to fix problems.
Created attachment 11571 [details] Proposed -r4 ebuild file. This is the patched (and proposed) new -r4 ebuild.
And I immediately found another thing I should have fixed... New attachments in a sec.
Created attachment 11574 [details, diff] Corrected Patch to selinux-small-2003011510-r3 Try #2... This adds a /etc/pam.d/newrole configuration file, based on /etc/pam.d/su.
Created attachment 11575 [details] Corrected Proposed -r4 ebuild file.
Ok, so this doesn't quite work yet either... It now gives me: newrole: incorrect password for {user} even though the user is permitted to transition to the specified role. Work in progress... :)
I think I need more sleep. Found same problem with run_init. QUESTION- Do we want to use pam or direct /etc/shadow access with these utils?
I just put -r4 in cvs to fix another bug. I removed this part: # fix up policy makefile cd ${WORKDIR}/policy sed -e 's:/usr/lib/selinux:/usr/flask:' < Makefile > Makefile.new mv -f Makefile.new Makefile It was needed when there was policy in selinux-small. All of the policy has been moved to selinux-base-policy, and I just forgot to remove this.
stupid bugzilla comments... anyway, I'll look at the PAM stuff further.
Oh, that could sound bad; it should have said "MY stupid bugzilla comments.."
Chris, here are the avc denied messages from today: May 6 08:24:20 selinux avc: denied { read write } for pid=1997 exe=/usr/bin/newrole path=/pts/1 dev=00:06 ino=905 scontext=suser:user_r:newrole_t tcontext=suser:object_r:devpts_t tclass=chr_file May 6 08:24:20 selinux avc: denied { getattr } for pid=1997 exe=/usr/bin/newrole path=/pts/1 dev=00:06 ino=905 scontext=suser:user_r:newrole_t tcontext=suser:object_r:devpts_t tclass=chr_file May 6 08:24:20 selinux avc: denied { read write } for pid=1997 exe=/usr/bin/newrole path=/tty dev=00:06 ino=15 scontext=suser:user_r:newrole_t tcontext=system_u:object_r:devtty_t tclass=chr_file May 6 08:24:20 selinux avc: denied { ioctl } for pid=1997 exe=/usr/bin/newrole path=/tty dev=00:06 ino=15 scontext=suser:user_r:newrole_t tcontext=system_u:object_r:devtty_t tclass=chr_file May 6 08:24:20 selinux avc: denied { getattr } for pid=1997 exe=/usr/bin/newrole path=/tty dev=00:06 ino=15 scontext=suser:user_r:newrole_t tcontext=system_u:object_r:devtty_t tclass=chr_file May 6 08:24:21 selinux avc: denied { ioctl } for pid=1997 exe=/usr/bin/newrole path=/pts/1 dev=00:06 ino=905 scontext=suser:user_r:newrole_t tcontext=suser:object_r:devpts_t tclass=chr_file May 6 08:24:21 selinux avc: denied { relabelfrom } for pid=1997 exe=/usr/bin/newrole path=/pts/1 dev=00:06 ino=905 scontext=suser:user_r:newrole_t tcontext=suser:object_r:devpts_t tclass=chr_file May 6 08:24:21 selinux avc: denied { relabelto } for pid=1997 exe=/usr/bin/newrole path=/pts/1 dev=00:06 ino=905 scontext=suser:user_r:newrole_t tcontext=suser:object_r:devpts_t tclass=chr_file suser is a user that has privilege to change to sysadm_r/sysadm_t. I didn't see any entries from unix_chkpwd (from IRC) that you saw...
Created attachment 11589 [details] AVC Violations from Today. AVC Violations from today. This may not be very useful as the system was rebooted today without a labeled filesystem. However, the stuff from after 11:00am should be OK.
Created attachment 11590 [details] Violations specific to newrole I finally got something that I can point directly to newrole.
Ok, I'm well aware of the /dev/pts/* denials. It's something I've been trying to track down for a while. I'm waiting to hear from the NSA/selinux mail list to see what they have to say about it.
Well, got word from the NSA. It turns out that there are some problems with devfs and selinux in 2.4. The devpts filesystem in 2.4 is patched to work with selinux. Devfs in 2.4 also handles devpts, but isnt patched to work with selinux. So, the solution is to mount devpts on top of devfs. Devpts needs to be compiled in along with devfs. Under Filesystems: [*] /dev file system support (EXPERIMENTAL) [ ] Automatically mount at boot [ ] Debug devfs [*] /dev/pts file system for Unix98 PTYs Then add devpts to /etc/fstab: none /dev/pts devpts gid=5,mode=620 0 0 I'm still observing a few denials, but now there are significantly fewer. This sounds like a hackish solution, but in 2.5, the devpts handling in devfs has been removed, so in 2.5/2.6, devpts will have to be mounted on top of devfs anyway.
Ok, the primary problem behind this was the incorrect labelling of /usr/sbin/unix_chkpwd (in addition to the devpts problem). I'm going to be committing a new selinux-small and selinux-base-policy soon, to make run_init and newrole use PAM, and have unix_chkpwd be labelled correctly.
Ok, re-compiling the kernel with DEVPTS support.. News at 6.
I just committed a new upstream version: selinux-small-2003040709 (~x86, etc). It also has the PAM fixes.
Unmounting /dev/pts helped for a little while (as Chris noticed) but didn't solve the problem entirely. E.g. right now I can't emerge nvim due to the same message.
selinux-small-2003040709 takes care of the problem properly. See bug #21315 for the problem in comment #19.
