Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.
  • OpenSSH_5.8p1, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
  • selinux-policy-2.4.6-338.el5
  • pam-0.99.6.2-12.el5

SELinux is running in permissive mode:

# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          disabled
Policy version:                 21
Policy from config file:        targeted

Whenever I login via ssh, /var/log/secure complain that:

sshd[4957]: Accepted publickey for quanta from 192.168.3.40 port 55822 ssh2
sshd[4957]: pam_unix(sshd:session): session opened for user quanta by (uid=0)
sshd[4957]: error: ssh_selinux_setup_pty: security_compute_relabel: Invalid argument

Google point me to this thread on the Fedora forum:

Possibly the easiest way (though longest) is to create the file /.autorelabel and reboot.

but I wonder that is there any other way to get rid of this without rebooting?

The security context of quanta:

$ id -Z
system_u:system_r:unconfined_t:SystemLow-SystemHigh

The mapping between Linux user and user_u:

$ sudo /usr/sbin/semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               user_u                    s0                       
root                      root                      SystemLow-SystemHigh   

SELinux users:

$ sudo /usr/sbin/semanage user -l

                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

root            user       s0         SystemLow-SystemHigh           system_r sysadm_r user_r
system_u        user       s0         SystemLow-SystemHigh           system_r
user_u          user       s0         SystemLow-SystemHigh           system_r sysadm_r user_r

The security context that sshd is running as:

$ ps -eZ | grep sshd
system_u:system_r:unconfined_t:SystemLow-SystemHigh 9509 ? 00:02:11 sshd
system_u:system_r:unconfined_t:SystemLow-SystemHigh 18319 ? 00:00:00 sshd
system_u:system_r:unconfined_t:SystemLow-SystemHigh 18321 ? 00:00:00 sshd

PAM configuration for sshd:

#%PAM-1.0
auth       include      system-auth
account    required     pam_nologin.so
#account        required    pam_access.so
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    required     pam_loginuid.so

What I already tried and didn't help:

# yum reinstall selinux-policy-targeted
# restorecon -R -v /etc/selinux/
# restorecon -R -v /home/

/var/log/audit/audit.log:

type=USER_AUTH msg=audit(1362372405.835:28361028): user pid=14332 uid=0 auid=503 subj=system_u:system_r:unconfined_t:s0-s0:c0.c1023 msg='op=pubkey_auth rport=50939 acct="quanta" exe="/usr/sbin/sshd" (hostname=?, addr=192.168.3.40, terminal=? res=success)'


UPDATE Mon Mar 4 21:20:49 ICT 2013

Reply to Michael Hampton:

Keep in mind that the reason for the reboot is that changing the security contexts affects running services, so at a minimum you should restart the affected services (i.e. restart sshd).

root     10244     1  0 17:18 ?        00:00:00 /usr/sbin/sshd

/var/log/secure

Mar 4 17:18:48 hostname sshd[10308]: error: ssh_selinux_setup_pty: security_compute_relabel: Invalid argument


UPDATE Tue Mar 5 21:54:00 ICT 2013

Can you provide the output of ls -lZ /dev/pts /dev/ptmx?

# ls -lZ /dev/pts/ /dev/ptmx 
crw-rw-rw-. 1 root tty  system_u:object_r:ptmx_t   5, 2 Mar  5 21:54 /dev/ptmx

/dev/pts/:
total 0
crw--w----. 1 quanta tty system_u:object_r:devpts_t 136, 0 Mar  5 21:54 0
crw--w----. 1 dieppv tty system_u:object_r:devpts_t 136, 1 Feb 26 17:08 1
crw--w----. 1 dieppv tty system_u:object_r:devpts_t 136, 2 Feb 25 17:53 2

UPDATE Wed Mar 6 10:57:11 ICT 2013

I have compiled the openssh-5.8p1, then copied the configuration files (/etc/ssh/ and /etc/pam.d/sshd), and started on a different port.

What surprised me is /var/log/secure doesn't complain when I try to login:

sshd[5061]: Server listening on 192.168.6.142 port 2317.
sshd[5139]: Accepted publickey for quanta from 192.168.3.40 port 54384 ssh2
sshd[5139]: pam_unix(sshd:session): session opened for user quanta by (uid=0)

The security context of the new /usr/local/sbin/sshd daemon is the same as the old (/usr/sbin/sshd):

ps -efZ | grep /usr/local/sbin/sshd

system_u:system_r:unconfined_t:SystemLow-SystemHigh root 5061 1  0 10:56 ? 00:00:00 /usr/local/sbin/sshd
system_u:system_r:unconfined_t:SystemLow-SystemHigh root 7850 3104  0 11:06 pts/3 00:00:00 grep /usr/local/sbin/sshd

Do you have any ideas?


UPDATE Wed Mar 6 15:36:39 ICT 2013

Make sure you compile it with --with-selinux, its not done by default.

OpenSSH has been configured with the following options:
                     User binaries: /usr/local//bin
                   System binaries: /usr/local//sbin
               Configuration files: /etc/openssh
                   Askpass program: /usr/local//libexec/ssh-askpass
                      Manual pages: /usr/local//share/man/manX
                          PID file: /var/run
  Privilege separation chroot path: /var/empty
            sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local//bin
                    Manpage format: doc
                       PAM support: yes
                   OSF SIA support: no
                 KerberosV support: no
                   SELinux support: yes
                 Smartcard support: 
                     S/KEY support: no
              TCP Wrappers support: no
              MD5 password support: yes
                   libedit support: no
  Solaris process contract support: no
           Solaris project support: no
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: yes
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY

              Host: i686-pc-linux-gnu
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -fno-strict-aliasing -fno-builtin-memset -fstack-protector-all -std=gnu99 
Preprocessor flags: 
      Linker flags:  -fstack-protector-all
         Libraries: -lresolv -lcrypto -ldl -lutil -lz -lnsl  -lcrypt
         +for sshd:  -lpam -lselinux
          +for ssh:  -lselinux

/var/log/secure when login to port 22 (/usr/sbin/sshd):

sshd[27339]: Accepted publickey for quanta from 192.168.3.40 port 50560 ssh2 
sshd[27339]: pam_unix(sshd:session): session opened for user quanta by (uid=0) 
sshd[27339]: error: ssh_selinux_setup_pty: security_compute_relabel: Invalid argument
sshd[28025]: Received disconnect from 192.168.3.40: 11: disconnected by user
sshd[28022]: pam_unix(sshd:session): session closed for user quanta 

/var/log/secure when login to port 2317 (/usr/local/sbin/sshd):

sshd[27705]: Accepted publickey for quanta from 192.168.3.40 port 34175 ssh2 
sshd[27705]: pam_unix(sshd:session): session opened for user quanta by (uid=0)
sshd[27707]: Received disconnect from 192.168.3.40: 11: disconnected by user 
sshd[27705]: pam_unix(sshd:session): session closed for user quanta 

and here're the log to prove that it enters the ssh_selinux_setup_pty:

sshd[4023]: debug1: SELinux support enabled
sshd[4023]: debug3: ssh_selinux_setup_pty: setting TTY context on /dev/pts/3
sshd[4023]: debug3: ssh_selinux_setup_pty: User context is user_u:system_r:unconfined_t, target tty is
 system_u:object_r:devpts_t
sshd[4023]: debug3: ssh_selinux_setup_pty: done
share|improve this question
    
Check for a file /etc/pam.d/sshd.rpmnew with unapplied changes. –  Michael Hampton Mar 4 '13 at 5:09
    
No, it doesn't exist. –  quanta Mar 4 '13 at 5:15
    
What version of sshd is running on the host? –  Matthew Ife Mar 5 '13 at 1:46
    
@MIfe: OpenSSH_5.8p1, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 –  quanta Mar 5 '13 at 2:31
1  
Make sure you compile it with --with-selinux, its not done by default. –  Matthew Ife Mar 6 '13 at 7:36

2 Answers 2

At first I wrote a relatively complex answer which really only applied to EL6, but then somethings come up I find pretty strange in your circumstance.

The error message:

ssh_selinux_setup_pty: security_compute_relabel: Invalid argument

Is very odd. The reason I say this is because on EL5, with the latest release of SSHD, that error message is impossible. Its not in the source. Anywhere. I grepped the entire source tree and the redhat patches for "ssh_selinux_setup_pty". Its not there.

It does, however appear on Fedora 18.

This leads me to think that the version of SSHD you are running is not the version it should be and it has been replaced. Either by yourself or by someone else.

Update 1

SSHD at the critical section that does not work performs something akin to this (with python); I'm trusting the selinux contexts being used within sshd are as you mentioned.

from selinux import *

sec_class = string_to_security_class("chr_file")

print security_compute_relabel("system_u:object_r:unconfined_t", \
             "system_u:object_r:initrc_devpts_t", sec_class)

This should return:

[ 0, some_context_stuff ]

You need to run this using the same context as sshd. The "initrc_devpts_t" is definitely right. The other context is the referenced user context which you provided.

Your code in sshd currently gets -1 which spits out that error. That would happen if the user context (argument 1) being generated in sshd is incorrect.

If you can get this python to not produce -1 in the first element of the tuple, then the only thing I can suggest would be to modify the sshd source to add an extra debug line in that function to find out what really the context turns out to be and turn on debug3 logging in sshds config.

In openbsd-compat/port-linux.c: ssh_selinux_setup_pty

    if (getfilecon(tty, &old_tty_ctx) == -1) {
            error("%s: getfilecon: %s", __func__, strerror(errno));
            goto out;
    }

    +debug3("%s: User context is %s, target tty is %s", __func__, user_ctx, old_tty_ctx);

    if (security_compute_relabel(user_ctx, old_tty_ctx,
        SECCLASS_CHR_FILE, &new_tty_ctx) != 0) {
            error("%s: security_compute_relabel: %s",
                __func__, strerror(errno));
            goto out;
    }
share|improve this answer
    
After adding an extra debug line, recompiled and started on a different port, the odd thing is /var/log/secure doesn't complain when logging to new port. See my updated question above. –  quanta Mar 6 '13 at 4:12

The /.autorelabel file just causes the startup scripts to run restorecon -r -v / at boot time, and then reboot again. (Actually it runs some invocation of fixfiles that prints lots of dots, but since that's just a frontend to restorecon I don't care...)

You could just run this yourself without rebooting, and that's generally my first step when trying to diagnose a weird SELinux issue. Keep in mind that the reason for the reboot is that changing the security contexts affects running services, so at a minimum you should restart the affected services (i.e. restart sshd).

If this does solve the problem, then somewhere in the output you'll see a changed security context which was the cause and resolution of the issue. Most likely it is not in /home or /etc/selinux.

share|improve this answer
    
This doesn't help. See my updated. –  quanta Mar 4 '13 at 14:22
    
You did relabel, right? –  Michael Hampton Mar 4 '13 at 20:51
    
Yes, I had relabeled complete filesystem (restorecon -rv /) and nothing change. –  quanta Mar 5 '13 at 2:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.