Note: I am digest subscriber so if you could copy me directly on any reply to the list I would appreciate it very much.
I sent this to the OpenSSH list (secureshell@securityfocus.com) yesterday and received no response so I am asking here in hopes that someone else has run across this problem on CentOS.
We have encountered a situation that requires sftp access to one of our server by an outside agency. This will be used for a data push application only and we need to secure our server from trespass via this access. After a modest amount of research we decided that the best answer was to use a more recent version of OpenSSH (5.3p1)that supports chroot as a configurable option.
I obtained the software from the openssh.org website and built it using the libedit packages from the CentOS testing repo. These were the option used:
./configure --prefix=/opt --with-libedit --with-md5-passwords --with-pam --with-selinux --with-tcp-wrappers
The new server software works fine for regular ssh/sftp users. However, when logging on as a member of the chroot group we obtain this error:
ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: security_getenforce() failed
I have found reports of this exact error via Google in several places dating back to 2006, but these all seem to devolve into either: this has been fixed in version x.y.z on distribution Q, where x.y.z is less than 5.3 and Q is not CentOS. Or, the selinux filesystem has to be mounted inside the chroot directory.
Since I assume the former is never going to happen for CentOS, at least not in time to do me any good, I am looking for an explanation of what the latter means and how it is accomplished. Our current SELinux status on that host is:
# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 21 Policy from config file: targeted
Our chroot directory path is:
/var/data/sshchroot
The questions are:
1. Is it possible to mount the selinux filesystem twice on the same host having different roots?
2. If so, then how is this accomplished?
3. If not, then is there anything else that I can do, besides disabling selinux support in the sshd daemon, to get this to work?
Sincerely,
James B. Byrne wrote:
Note: I am digest subscriber so if you could copy me directly on any reply to the list I would appreciate it very much.
<snip>
After a modest amount of research we decided that the best answer was to use a more recent version of OpenSSH (5.3p1)that supports chroot as a configurable option.
I've not tested it, but I believe the chroot stuff was backported some while ago:
# rpm -q --changelog openssh | more * Tue Dec 01 2009 Jan F. Chadima jchadima@redhat.com - 4.3p2-40 - close error file descriptor before running external subsystem (#537348)
* Tue Sep 15 2009 Jan F. Chadima jchadima@redhat.com - 4.3p2-36.2 - minimize chroot patch to be compatible with upstream (#522141)
* Tue Jun 23 2009 Jan F. Chadima jchadima@redhat.com - 4.3p2-36 - tiny change in chroot sftp capability into openssh-server solve ls speed problem (#440240)
* Tue May 26 2009 Jan F. Chadima jchadima@redhat.com - 4.3p2-35 - workaround to plaintext recovery attack against CBC ciphers CVE-2008-5161 (#502230)
* Fri May 15 2009 Tomas Mraz tmraz@redhat.com - 4.3p2-34 - disable protocol 1 in the FIPS mode
* Thu Apr 30 2009 Jan F. Chadima jchadima@redhat.com - 4.3p2-33 - fix scp hangup on exit (#454812) - call integrity checks only on binaries which are part of the OpenSSH FIPS modules
* Mon Apr 20 2009 Tomas Mraz tmraz@redhat.com - 4.3p2-32 - log if FIPS mode is initialized (#492363) - check the integrity of the binaries in the FIPS mode (#467268)
* Wed Apr 08 2009 Jan F. Chadima jchadima@redhat.com - 4.3p2-31 - fix ssh hangup on exit (#454812)
* Fri Mar 27 2009 Jan F. Chadima jchadima@redhat.com - 4.3p2-30 - add chroot sftp capability into openssh-server (#440240)
On Wed, February 3, 2010 09:48, Ned Slider wrote:
James B. Byrne wrote:
Note: I am digest subscriber so if you could copy me directly on any reply to the list I would appreciate it very much.
<snip>
After a modest amount of research we decided that the best answer was to use a more recent version of OpenSSH (5.3p1)that supports chroot as a configurable option.
I've not tested it, but I believe the chroot stuff was backported some while ago:
Thank you very much for the information for I was not aware of this.
Unfortunately, having tested the CentOS stock sshd server I discover that this back-port is very similar to that of the sftponly hack of several years ago. It is not the configurable chroot of OpenSSH-5.3. To begin with, it very much appears from the documentation as if this is an all or nothing setting; if it is on then all ssh users are chrooted. Further, to use this feature with interactive sessions one must copy all of the requisite system utilities into directories under the chroot directory.
(For an interactive session this requires at least a shell, typically sh(1), and basic /dev nodes such as null(4), zero(4), stdin(4), stdout(4), stderr(4), arandom(4) and tty(4) devices.)
This is not a viable alternative since the system is remotely managed.
So, I am left still seeking answers to my original questions.
1. Is it possible to mount the selinux filesystem twice on the same host having different roots?
2. If so, then how is this accomplished?
3. If not, then is there anything else that I can do, besides disabling selinux support in the sshd daemon, to get OpenSSH-5.3 chroot to work with SELinux?
On Wed, 2010-02-03 at 10:26 -0500, James B. Byrne wrote:
<snip>
So, I am left still seeking answers to my original questions.
- Is it possible to mount the selinux filesystem twice on the same
host having different roots?
Mount --bind *before* the chroot environment is entered should do the trick. AFAIK, there is no problem leaving it mounted this way as part of your system start-up. Depending on permissions, it might be exposed to other *ftp* users, so take care on that part of it.
- If so, then how is this accomplished?
man mount and look for the bind option
<snip>
HTH
On Wed, Feb 3, 2010 at 9:26 AM, James B. Byrne byrnejb@harte-lyne.cawrote:
On Wed, February 3, 2010 09:48, Ned Slider wrote:
James B. Byrne wrote:
Note: I am digest subscriber so if you could copy me directly on any reply to the list I would appreciate it very much.
<snip>
After a modest amount of research we decided that the best answer was to use a more recent version of OpenSSH (5.3p1)that supports chroot as a configurable option.
I've not tested it, but I believe the chroot stuff was backported some while ago:
Thank you very much for the information for I was not aware of this.
Unfortunately, having tested the CentOS stock sshd server I discover that this back-port is very similar to that of the sftponly hack of several years ago. It is not the configurable chroot of OpenSSH-5.3. To begin with, it very much appears from the documentation as if this is an all or nothing setting; if it is on then all ssh users are chrooted. Further, to use this feature with interactive sessions one must copy all of the requisite system utilities into directories under the chroot directory.
(For an interactive session this requires at least a shell, typically sh(1), and basic /dev nodes such as null(4), zero(4), stdin(4), stdout(4), stderr(4), arandom(4) and tty(4) devices.)
This is not a viable alternative since the system is remotely managed.
You mention two problems: 1. "all or nothing setting" 2. "copy all of the requisite system utilities"
As for #1, you could run two separate SSH daemons (using different ports), so that only 1 has the chroot option. Here's a discussion about how to run two separate SSH daemons: http://www.DaleDellutri.com/prog.html
As for #2, I don't understand how the fact that the system is remotely managed makes copying the files "not a viable alternative". Do you not have root access to the server? (I'm not criticising, I simply don't understand.)
So, I am left still seeking answers to my original questions.
- Is it possible to mount the selinux filesystem twice on the same
host having different roots?
If so, then how is this accomplished?
If not, then is there anything else that I can do, besides
disabling selinux support in the sshd daemon, to get OpenSSH-5.3 chroot to work with SELinux?
I am also interested in the answers to these questions.
On Wed, 2010-02-03 at 14:48 +0000, Ned Slider wrote:
James B. Byrne wrote:
Note: I am digest subscriber so if you could copy me directly on any reply to the list I would appreciate it very much.
<snip>
After a modest amount of research we decided that the best answer was to use a more recent version of OpenSSH (5.3p1)that supports chroot as a configurable option.
I've not tested it, but I believe the chroot stuff was backported some while ago:
<snip>
I was requested to perform this same "feature". I used rssh available at http://www.pizzashack.org/rssh/
-- Les Ault VCP, RHCE Linux Systems Administrator, Office of Information Technology Computing Systems Services: Technical Services and Research
The University of Tennessee 135C5 Kingston Pike Building 2309 Kingston Pike Knoxville, TN 37996
Instead, might the use of SCP (instead of sftp subsystem) and a limited shell be able to achieve your goal? I found this when googling for "limited shell": http://lshell.ghantoos.org/ Look at the "Use case". There's also rbash, but on first glance lshell looks quite promising.
Kai
James B. Byrne wrote:
<snip>
The new server software works fine for regular ssh/sftp users. However, when logging on as a member of the chroot group we obtain this error:
ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: security_getenforce() failed
<snip>
# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 21 Policy from config file: targeted
What happens if you enable SELinux, i.e, set it to enforcing? Do you still see the same error message above?
On Wed, February 3, 2010 12:02, Ned Slider wrote:
What happens if you enable SELinux, i.e, set it to enforcing? Do you still see the same error message above?
I have rebuilt the thing without SELinux support and all seems to be working now. Since, other than the sftp user, there are only administrative users that log into the target host via ssh this seems an acceptable approach. I am contemplating running the 5.3p1 version as a separate instance listening on a separate port instead of replacing the CentOS version.
Thanks,
Just for the reference if you want to keep SELINUX enabled and create a new instance of sshd (with the stock CentOS 5.4 sshd) with sftp only you can do the following:
-create a copy of /etc/ssh/sshd_config e.g. cp /etc/ssh/sshd_config /etc/ssh/sftpd_config
-chage /add the following lines in sftpd_config Port 1234 ChrootDirectory %h Subsystem sftp internal-sftp AllowUsers externaluser
-let SELINUX know that port 1234 (or whatever you put in your sftpd_config) is of type ssh_port_t
semanage port -a -t ssh_port_t -p tcp -n 1234
-make sure that the sftp user's home directory respects the requirements of ChrootDirectory sshd_config directive : This path, and all its components, must be root-owned directories that are not writable by any other user or group. For file transfer sessions using “sftp”, no additional configuration of the environment is necessary if the in-process sftp server is used chown root /home/externaluser chmod g-w /home/externaluser
-create a directory in which externaluser will be able to write mkdir /home/externaluser/upload chown externaluser /home/externaluser/upload
- create a copy of /etc/init.d/sshd init script cp /etc/init.d/sshd /etc/init.d/sftpd - modify it to reflect the sftpd_config config file and a new pid file - make it start automatically chkconfig sftpd --add sftp
Radu
On Thu, February 4, 2010 05:28, Radu Radutiu wrote:
Just for the reference if you want to keep SELINUX enabled and create a new instance of sshd (with the stock CentOS 5.4 sshd) with sftp only you can do the following:
-create a copy of /etc/ssh/sshd_config e.g. cp /etc/ssh/sshd_config /etc/ssh/sftpd_config
-chage /add the following lines in sftpd_config Port 1234 ChrootDirectory %h Subsystem sftp internal-sftp AllowUsers externaluser
-let SELINUX know that port 1234 (or whatever you put in your sftpd_config) is of type ssh_port_t
semanage port -a -t ssh_port_t -p tcp -n 1234
-make sure that the sftp user's home directory respects the requirements of ChrootDirectory sshd_config directive : This path, and all its components, must be root-owned directories that are not writable by any other user or group. For file transfer sessions using âsftpâ, no additional configuration of the environment is necessary if the in-process sftp server is used chown root /home/externaluser chmod g-w /home/externaluser
-create a directory in which externaluser will be able to write mkdir /home/externaluser/upload chown externaluser /home/externaluser/upload
- create a copy of /etc/init.d/sshd init script
cp /etc/init.d/sshd /etc/init.d/sftpd
- modify it to reflect the sftpd_config config file and a new pid
file
- make it start automatically
chkconfig sftpd --add sftp
Radu
Thank you for that. I did much the same as you suggest but, in the end, decided to just run the 5.3 sshd instead. I have set SELinix to enforcing on that host and sshd seems to work as expected. I cannot tell what the --with-selinux compiler switch is meant to do.
-
Dale Dellutri -
James B. Byrne -
Kai Schaetzl -
Les Ault -
Ned Slider -
Radu Radutiu -
William L. Maltby