Can't use new users?
sds at tycho.nsa.gov
Fri Sep 2 19:05:26 UTC 2005
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 at 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 at dumont ~]# ssh nagios at localhost
> nagios at localhost's password:
> Last login: Fri Sep 2 11:40:25 2005 from dumont
> -bash: /etc/profile: Permission denied
> [root at 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.
National Security Agency
More information about the fedora-selinux-list