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(a)redhat.com> 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