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?
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
James B. Byrne mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
Just heads up everybody, there is new security patch of openssl: https://www.openssl.org/news/ 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 at centos.org [mailto:centos-bounces at 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: https://www.openssl.org/news/ 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 at 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 at kicp.uchicago.edu>:> Just heads up everybody, > > there is new security patch of openssl: > > https://www.openssl.org/news/ > > 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos >