So last night I installed FC3, added Fedora Extras, and did a yum update. Now I can't use any new users. Behold:
[root@dumont ~]# adduser nagios [root@dumont ~]# su - nagios Your default context is user_u:system_r:unconfined_t.
Do you want to choose a different one? [n] could not open session
/var/log/messages has this to say about it:
Sep 2 17:34:21 dumont su[6229]: Warning! Could not relabel /dev/pts/4 with user_u:object_r:devpts_t, not relabeling.Operation not permitted
Something doesn't seem quite right, but I'm not sure what I'm missing. Here's are the selinux packages I've got installed:
selinux-policy-targeted-1.17.30-3.16 libselinux-1.19.1-8 libselinux-devel-1.19.1-8
On Fri, 2005-09-02 at 10:37 -0700, Ben wrote:
So last night I installed FC3, added Fedora Extras, and did a yum update. Now I can't use any new users. Behold:
[root@dumont ~]# adduser nagios [root@dumont ~]# su - nagios Your default context is user_u:system_r:unconfined_t.
Do you want to choose a different one? [n] could not open session
/var/log/messages has this to say about it:
Sep 2 17:34:21 dumont su[6229]: Warning! Could not relabel /dev/pts/4 with user_u:object_r:devpts_t, not relabeling.Operation not permitted
Something doesn't seem quite right, but I'm not sure what I'm missing. Here's are the selinux packages I've got installed:
selinux-policy-targeted-1.17.30-3.16 libselinux-1.19.1-8 libselinux-devel-1.19.1-8
What is your kernel?
2.6.12-1.1376_FC3
Stephen Smalley wrote:
On Fri, 2005-09-02 at 10:37 -0700, Ben wrote:
So last night I installed FC3, added Fedora Extras, and did a yum update. Now I can't use any new users. Behold:
[root@dumont ~]# adduser nagios [root@dumont ~]# su - nagios Your default context is user_u:system_r:unconfined_t.
Do you want to choose a different one? [n] could not open session
/var/log/messages has this to say about it:
Sep 2 17:34:21 dumont su[6229]: Warning! Could not relabel /dev/pts/4 with user_u:object_r:devpts_t, not relabeling.Operation not permitted
Something doesn't seem quite right, but I'm not sure what I'm missing. Here's are the selinux packages I've got installed:
selinux-policy-targeted-1.17.30-3.16 libselinux-1.19.1-8 libselinux-devel-1.19.1-8
What is your kernel?
On Fri, 2005-09-02 at 10:37 -0700, Ben wrote:
So last night I installed FC3, added Fedora Extras, and did a yum update. Now I can't use any new users. Behold:
[root@dumont ~]# adduser nagios [root@dumont ~]# su - nagios Your default context is user_u:system_r:unconfined_t.
Do you want to choose a different one? [n] could not open session
/var/log/messages has this to say about it:
Sep 2 17:34:21 dumont su[6229]: Warning! Could not relabel /dev/pts/4 with user_u:object_r:devpts_t, not relabeling.Operation not permitted
Something doesn't seem quite right, but I'm not sure what I'm missing. Here's are the selinux packages I've got installed:
Hmmm...no avc messages in /var/log/messages prior to the warning?
Is it repeatable after /usr/sbin/setenforce 0?
Huh, setenforce 0 seems to have no effect. I see this when I run it:
Sep 2 11:15:45 dumont kernel: audit(1125684945.038:24): avc: granted { setenforce } for pid=6453 comm="setenforce" scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security
.... but everthing remains broken the same way.
Stephen Smalley wrote:
On Fri, 2005-09-02 at 10:37 -0700, Ben wrote:
So last night I installed FC3, added Fedora Extras, and did a yum update. Now I can't use any new users. Behold:
[root@dumont ~]# adduser nagios [root@dumont ~]# su - nagios Your default context is user_u:system_r:unconfined_t.
Do you want to choose a different one? [n] could not open session
/var/log/messages has this to say about it:
Sep 2 17:34:21 dumont su[6229]: Warning! Could not relabel /dev/pts/4 with user_u:object_r:devpts_t, not relabeling.Operation not permitted
Something doesn't seem quite right, but I'm not sure what I'm missing. Here's are the selinux packages I've got installed:
Hmmm...no avc messages in /var/log/messages prior to the warning?
Is it repeatable after /usr/sbin/setenforce 0?
On Fri, 2005-09-02 at 11:18 -0700, Ben wrote:
Huh, setenforce 0 seems to have no effect. I see this when I run it:
Sep 2 11:15:45 dumont kernel: audit(1125684945.038:24): avc: granted { setenforce } for pid=6453 comm="setenforce" scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security
.... but everthing remains broken the same way.
That message just shows you that permission was granted to switch enforcing mode, so /usr/sbin/getenforce should now show that you are now in Permissive mode, i.e. SELinux will only log permissions that would be denied by policy but not actually enforce the denial. If it is still broken, then the SELinux kernel permission checks are unlikely to be the cause.
Not sure it will work on FC3, but try enabling syscall auditing: /sbin/auditctl -e 1 And then try again.
Stephen Smalley wrote:
That message just shows you that permission was granted to switch enforcing mode, so /usr/sbin/getenforce should now show that you are now in Permissive mode, i.e. SELinux will only log permissions that would be denied by policy but not actually enforce the denial. If it is still broken, then the SELinux kernel permission checks are unlikely to be the cause.
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
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?
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...
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@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.
On Fri, 2005-09-02 at 10:37 -0700, Ben wrote:
So last night I installed FC3, added Fedora Extras, and did a yum update. Now I can't use any new users. Behold:
BTW, not that it matters for the purposes of tracking down this issue, but any reason why you are using FC3 rather than FC4?
Yeah, I'm trying to stay away from the bleeding edge for my file server. :)
Stephen Smalley wrote:
On Fri, 2005-09-02 at 10:37 -0700, Ben wrote:
So last night I installed FC3, added Fedora Extras, and did a yum update. Now I can't use any new users. Behold:
BTW, not that it matters for the purposes of tracking down this issue, but any reason why you are using FC3 rather than FC4?
selinux@lists.fedoraproject.org