CentOS-6.6
We have sshd chroot working, mostly, for a particular groupid. However, we have two things that remain u/s, no doubt due to some omission on my part.
Basically, we would like our users to be able to tunnel their https over the ssh connection to this server and be able to do X11 forwarding as well. At the moment both work when the user connects without chroot and neither works if they are chroot, even when the chroot directory is the actual system /.
The Match statements are:
Match Group wheel AllowTcpForwarding yes ChrootDirectory / PermitOpen any X11Forwarding yes X11UseLocalhost no
Match Group !wheel,sftp ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no
There are SELinux issues:
/var/log/messages
Jul 9 09:22:43 inet02 setroubleshoot: SELinux is preventing /usr/sbin/sshd from create access on the udp_socket . For complete SELinux messages. run sealert -l 91eae747-73dc-43d8-8af9-0601e726f233
Jul 9 09:22:43 inet02 setroubleshoot: SELinux is preventing /usr/sbin/sshd from create access on the tcp_socket . For complete SELinux messages. run sealert -l c5d4049e-cffb-4cfb-a243-135c7b297e8b
Jul 9 09:22:44 inet02 setroubleshoot: SELinux is preventing /usr/sbin/sshd from open access on the chr_file 5. For complete SELinux messages. run sealert -l d77a3254-8aba-4a13-bd78-0bcf14e67035
/var/log/secure
Jul 9 09:22:34 inet02 sshd[17681]: error: socket: Permission denied
Jul 9 09:22:34 inet02 sshd[17684]: error: /dev/pts/5: Permission denied
# grep sshd /var/log/audit/audit.log | audit2allow
#============= chroot_user_t ==============
#!!!! This avc is allowed in the current policy allow chroot_user_t admin_home_t:dir search;
#!!!! This avc is allowed in the current policy allow chroot_user_t net_conf_t:file read; allow chroot_user_t self:netlink_route_socket create; allow chroot_user_t self:tcp_socket create; allow chroot_user_t self:udp_socket create; allow chroot_user_t user_devpts_t:chr_file open; allow chroot_user_t user_home_t:chr_file { read write };
#!!!! This avc is allowed in the current policy allow chroot_user_t xauth_exec_t:file getattr;
#============= xauth_t ============== allow xauth_t chroot_user_t:process sigchld;
# getsebool -a | grep ssh
allow_ssh_keysign --> off fenced_can_ssh --> off ssh_chroot_full_access --> on ssh_chroot_manage_apache_content --> off ssh_chroot_rw_homedirs --> on ssh_sysadm_login --> off
These are definitely involved with the X11 forwarding issue because if I use: setenforce Permissive then gvim works for a chrooted session. However, when setenforce Enforcing is set then gvim fails with: 'E233: cannot open display'.
I have not tried the https tunnelling without SELinux but I suspect that the problem is similar if not identical.
Do I generate a custom policy or are there some other SSH/SELinux settings that I am missing?
Just heads up everybody,
there is new security patch of openssl:
so we can expect patched openssl from upstream vendor shortly.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
To wit:
OpenSSL Security Advisory [9 Jul 2015] =======================================
Alternative chains certificate forgery (CVE-2015-1793) ======================================================
Severity: High
During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate.
This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.
This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.
OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p
This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project.
Note ====
As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade.
References ==========
URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt
Note: the online version of the advisory may be updated with additional details over time.
For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Valeri Galtsev Sent: Thursday, July 09, 2015 8:53 AM To: CentOS mailing list Subject: [CentOS] Openssl security patch
Just heads up everybody,
there is new security patch of openssl:
so we can expect patched openssl from upstream vendor shortly.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 09.07.2015 16:03, Robert Wolfe wrote:
To wit:
OpenSSL Security Advisory [9 Jul 2015]
Alternative chains certificate forgery (CVE-2015-1793)
Severity: High
During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate.
This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.
This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.
OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p
This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project.
Note
As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade.
References
URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt
Note: the online version of the advisory may be updated with additional details over time.
For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Valeri Galtsev Sent: Thursday, July 09, 2015 8:53 AM To: CentOS mailing list Subject: [CentOS] Openssl security patch
Just heads up everybody,
there is new security patch of openssl:
so we can expect patched openssl from upstream vendor shortly.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
And according to Redhat (BZ#1238619):
Not vulnerable. This issue does not affect any version of the OpenSSL package as shipped with Red Hat Enterprise Linux 4, 5, 6 and 7, JBoss Enterprise Application Platform 6, and JBoss Enterprise Web Server 1 and 2 because they did not include support for alternative certificate chains.
Yep, saw that.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Patrick Hurrelmann Sent: Thursday, July 09, 2015 9:09 AM To: centos@centos.org Subject: Re: [CentOS] Openssl security patch
[...]
And according to Redhat (BZ#1238619):
Not vulnerable. This issue does not affect any version of the OpenSSL package as shipped with Red Hat Enterprise Linux 4, 5, 6 and 7, JBoss Enterprise Application Platform 6, and JBoss Enterprise Web Server 1 and 2 because they did not include support for alternative certificate chains.
-- Lobster SCM GmbH, Hindenburgstraße 15, D-82343 Pöcking HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Not affected: https://access.redhat.com/solutions/1523323
-- Eero
2015-07-09 16:52 GMT+03:00 Valeri Galtsev galtsev@kicp.uchicago.edu:
Just heads up everybody,
there is new security patch of openssl:
so we can expect patched openssl from upstream vendor shortly.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Eero Volotinen -
James B. Byrne -
Patrick Hurrelmann -
Robert Wolfe -
Valeri Galtsev