On Fri, 2005-09-02 at 11:50 -0700, Ben wrote: > getenforce does indeed show Permissive after running setenforce 0, so at > least that's working as expected. I can see how this seems like it would > make it unlikely to be a SELinux problem at this point, but then how > come I still see this when trying to su? > > Warning! Could not relabel /dev/pts/3 with user_u:object_r:devpts_t, > not relabeling.Operation not permitted The implication is that su (via pam_selinux) is hitting a Linux DAC permission denial when attempting to relabel (setxattr) the pty. I do seem to recall an issue where su was changing its fsuid prior to invoking pam_open_session, thereby preventing the pam_selinux module from relabeling the pty if going from root to non-root. Looking at the history of the coreutils-pam.patch in the public Fedora CVS tree, I see: date: 2004/12/06 15:51:03; author: twaugh; state: Exp; lines: +4 -9 * Mon Dec 6 2004 Tim Waugh <twaugh@xxxxxxxxxx> 5.2.1-34 - Don't set fs uid until after pam_open_session (bug #77791).. So an obvious question is whether this fix made its way back into FC3. > Interestingly, if I try to ssh in, instead of su, I get this: > > [root@dumont ~]# ssh nagios@localhost > nagios@localhost's password: > Last login: Fri Sep 2 11:40:25 2005 from dumont > -bash: /etc/profile: Permission denied > > > [root@dumont nagios]# ls -alZ > drwx------ nagios nagios root:object_r:user_home_dir_t . > drwxr-xr-x root root system_u:object_r:home_root_t .. > -rw------- nagios nagios user_u:object_r:user_home_t .bash_history > -rw-r--r-- nagios nagios root:object_r:user_home_t .bash_logout > -rw-r--r-- nagios nagios root:object_r:user_home_t .bash_profile > -rw-r--r-- nagios nagios root:object_r:user_home_t .bashrc > -rw-r--r-- nagios nagios root:object_r:user_home_t .emacs > -rw-r--r-- nagios nagios root:object_r:user_home_t .gtkrc > -rw-r--r-- nagios nagios root:object_r:user_home_t .zshrc > > .... so it still seems like SELinux is hurting me, even though it's set > to be in permissive mode? If permissive, SELinux shouldn't be denying any system calls. DAC denials are still possible of course. > >Not sure it will work on FC3, but try enabling syscall auditing: > > /sbin/auditctl -e 1 > >And then try again. > > > > > This didn't seem to have any impact I could see... Yes, it looks like the auditctl shipped in FC3 is non-functional. Pity. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
