Created attachment 1212184 [details] Workign root via monitor console Description of problem: If logged in via sshd, root can not access some files, that do not have o+r or belong too root: [root@c1 ~]# cat /etc/shadow cat: /etc/shadow: Keine Berechtigung [root@c1 ~]# ls -la /var/log/exim/ ls: Öffnen von Verzeichnis /var/log/exim/ nicht möglich: Keine Berechtigung [root@c1 ~]# id uid=0(root) gid=0(root) Gruppen=0(root) [root@c1 ~]# BUT, if logged in via a Konsole, root is root and can access those files. A screenshot of such a login is attached. Version-Release number of selected component (if applicable): openssh-server-7.2p2-6.fc23.i686 How reproducible: 100% on all systems that have installed that package. Actual results: no root functionality. Root is threated as any other normal user account. Expected results: beeing root again. Additional info: Oct 19 14:03:16 INFO Upgraded: openssh-7.2p2-6.fc23.i686 Oct 19 14:03:20 INFO Upgraded: openssh-server-7.2p2-6.fc23.i686 Oct 19 14:03:20 INFO Upgraded: openssh-clients-7.2p2-6.fc23.i686 Oct 19 14:03:20 INFO Cleanup: openssh-clients-7.2p2-3.fc23.i686 Oct 19 14:03:20 INFO Cleanup: openssh-server-7.2p2-3.fc23.i686 Oct 19 14:03:25 INFO Cleanup: openssh-7.2p2-3.fc23.i686
Is SELinux enabled? Can you provide the output of 'id -Z' ?
SELinux is disabled. [root@s113 ~]# id -Z id: --context (-Z) funktioniert nur auf einem Kernel mit SELinux Rebooting did not help.
The problem is unfixable from inside an openssh session: [root@eve ~]$ scp openssh-* root@c1:/root/ scp: /root//openssh-7.2p2-3.fc23.i686.rpm: Permission denied scp: /root//openssh-clients-7.2p2-3.fc23.i686.rpm: Permission denied scp: /root//openssh-server-7.2p2-3.fc23.i686.rpm: Permission denied AND: [root@c1 tmp]# rpm -U --force /tmp/openssh-*rpm Fehler: Entpacken des Archivs fehlgeschlagen bei Datei /usr/bin/ssh-keygen;58078ddf: cpio: open Fehler: openssh-7.2p2-3.fc23.i686: installieren fehlgeschlagen Fehler: Entpacken des Archivs fehlgeschlagen bei Datei /usr/bin/scp;58078ddf: cpio: open Fehler: openssh-clients-7.2p2-3.fc23.i686: installieren fehlgeschlagen Fehler: openssh-clients-7.2p2-6.fc23.i686: löschen übersprungen Fehler: openssh-7.2p2-6.fc23.i686: löschen übersprungen [root@c1 tmp]# exit I had to login via monitor console and downgrade it via rpm -U --force after downloading the openssh RPMs from Koji.
Sources: http://marius.bloggt-in-braunschweig.de/2016/10/20/update-fedora-openssh-alarm-nicht-updaten-auf-7-2p2-6/ https://marius.bloggt-in-braunschweig.de/2016/10/19/fedora-openssh-alarm-nicht-updaten-auf-7-2p2-6/ Working Downgrade methodes : 1. Download the previouse version of the three updates packages from : http://koji.fedoraproject.org/koji/buildinfo?buildID=756836 best to /tmp/ on the server you need to regain controll over. I suggest version 7.2p2-3 . 2. as defective root user do : -- CHANGE THE TIME before your execute it -- echo "41 10 * * * root /usr/bin/rpm -U --force /tmp/openssh*rpm > /tmp/log; rm -f /etc/cron.d/onetime" > /etc/cron.d/onetime 3. logoff and wait for it to happen 4. login again.. done
Just tested the same on Fedora 25 and Fedora 23, but I can not reproduce it. SELinux is disabled in the configuration files (/etc/selinux/config), I rebooted and I am connecting to the root all the time, but I still can read all the files. Do you have some special configuration in your sshd_config (chroot?)? The behavior looks like related to the capabilities. Do you notice any difference between the output of capsh --print on both logins?
Yes, chroot is enabled, but not for root. -------------------------------- Protocol 2 SyslogFacility AUTHPRIV PasswordAuthentication yes ChallengeResponseAuthentication no LogLevel info GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes UsePrivilegeSeparation yes PermitRootLogin without-password AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL X11Forwarding no Subsystem sftp /usr/libexec/openssh/sftp-server ChrootDirectory /opt/root/ Match user root ChrootDirectory /
Capabilities and Groupinfos are gone ( as expected :) ) NONE WORKING: [root@XXX ~]# capsh --print Current: = Bounding set = Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) uid=0(root) gid=0(root) groups= WORKING: [root@XXXX ~]# capsh --print Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,37+ep Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,37 Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
Thank you for the additional information. > Match user root > ChrootDirectory / This is wrong. You should use "ChrootDirectory none" to avoid chroot. Because otherwise the chroot operation is executed on the / . This should be noop, but evidently is not. I will investigate why does it behave this way. It never came to my mind to do chroot on / (and not sure if we want to support it).
changing it would not be a problem, but if i remember correctly, there was a problem with "none" as option. Ich will check it out.
Yes, it was a problem prior openssh-7.2p1, but it resolved upstream [1] and works in your openssh version. [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2486
with "none" as chrootdirectory - capabilities and groups are back - access is back Seems to work. I hope "they" do not expect, that production server configfiles get changed due to a small entry in an unkown bugtracker :D For my part, i will just roll out a new sshd_config, problem solved.
Well ... it was in openssh release notes [1], obviously. But I understand that the people in production are not able to follow all the release notes of all software. Thank you for the help with investigation. Do not close this bug, because it is obviously bug that we drop root capabilities. We should not certainly do that for a UID=0 regardless the chroot option. Once I will test the patch, I will issue the updates. [1] http://www.openssh.com/txt/release-7.2
Created attachment 1213736 [details] proposed dist git patch
openssh-7.3p1-5.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6d0ee59e4e
openssh-7.3p1-5.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-6d0ee59e4e
openssh-7.3p1-6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6d0ee59e4e
openssh-7.2p2-14.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-48f5186dfb
openssh-7.3p1-6.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-6d0ee59e4e
openssh-7.2p2-14.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-48f5186dfb
openssh-7.2p2-14.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
openssh-7.3p1-6.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.