Univention Bugzilla – Bug 39700
univention-system-activation: On non-master systems, root ssh restrictions are not removed
Last modified: 2016-03-18 15:22:47 CET
Scenario: Joining a Univention App as a Slave into an existing UCS Domain, where a valid license has been installed Expected behaviour: Login as root via ssh is possible Error: Received disconnect from <ip>: 2: Too many authentication failures for root The reason is, that univention-system-activation is installed, which sets various UCR variables to deny login/su for root. These settings are not undone if a license is present on the master. These settings get reset when a license is uploaded, in the 'stop' part of scripts/univention-system-activation. But that part of the script is never executed, because a valid license is found, and u-system-activation is never started on the slave. I think we should expand the script and the appliance hook [1] to undo all changes if a license is present. [1] usr/lib/univention-system-setup/appliance-hooks.d/96_enable_system_activation
Workaround: Login as Administrator via ssh, 'su -' to become root, then execute the 'ucr unset' and 'ucr set' commands from the 'elif [ "$ACTION" = "stop" ]' block.
In addition to this, it would be helpful to... (a) disable for the appliance scenario the option to join a slave later on. (b) assert that the UCS domain has already been activated before executing the join process that.
Created attachment 7455 [details] univention-system-setup.patch WIP changes for univention-system-setup
Created attachment 7456 [details] univention-system-activation.patch WIP changes univention-system-activation
Root restrictions are now lifted correctly. Proposal from comment 7 has been implemented. UCS4.1-1: r67548: Ensure system activation page is only shown on DC master Package: univention-system-activation Version: 1.0.1-3.51.201602181635 r67547: Check for activated UCS license when joining an App Appliance Package: univention-system-setup Version: 9.0.4-2.946.201602181623
Could you please remove the following lines from the postinst file: > if [ ! -e /var/univention-join/joined ]; then > /usr/sbin/univention-system-activation restrict-root > fi ... the check for the joined file is since Bug 40046 obsolete and it seems more sensible to me to let the appliance generation script call univention-system-activation restrict-root.
UCS4.1-1: r67873: removed setting up of root restrictions from postinst file Package: univention-system-activation Version: 1.0.1-4.52.201603031445
Created attachment 7534 [details] Patch for help text Looks good! Could you please update the help text of the script? This does not contain the new actions. Find attached a proposal.
UCS4.1-1: r68093: Changed help text r68095: YAML Package: univention-system-activation Version: 1.0.1-4.52.201603031445
As we now have appliances that already are in a joined state, it is possible to ssh to the machine as Administrator and to call "sudo bash" in order to gain root rights. The easiest thing would be to set auth/sudo=no. It is then still possible to ssh as Administrator, this could be disabled via setting the following variables to "no": auth/gdm/group/Administrators auth/gdm/group/Domain Admins auth/gdm/user/root auth/kdm/group/Administrators auth/kdm/group/Domain Admins auth/kdm/user/root auth/login/group/Administrators auth/login/group/Domain Admins auth/login/user/root auth/other/group/Administrators auth/other/group/Domain Admins auth/other/user/root auth/sshd/group/Administrators auth/sshd/group/Domain Admins auth/sshd/user/root
Please change (2x): "App Appliance could not be joined because the license on the DC Master is not activated." → "{appApplianceName} Appliance could not be joined because the UCS license ..."
UCS4.1-1: r68115: more restrictions like auth/sudo=no Package: univention-system-activation Version: 1.0.1-6.54.201603151810 r68118: Call the appliance by its name Package: univention-system-setup Version: 9.0.4-6.951.201603151835
r68119: YAML
Created attachment 7536 [details] Patch for setting UCR variables via global array As discussed, "_" != " " in my tests: ---------- 8< ---------- root@ucs-1234:~# ucr set "auth/ftp/group/Domain_Admins=no" Create auth/ftp/group/Domain_Admins File: /etc/security/access-ftp.conf root@ucs-1234:~# ucr search auth/ftp.*Domain auth/ftp/group/Domain Admins: yes auth/ftp/group/Domain_Admins: no ---------- 8< ---------- Attached a proposition to set UCR variables via a global array (I also removed the debug line).
I observed that I received fairly often the following traceback: ---------- 8< ---------- Traceback (most recent call last): File "<stdin>", line 22, in <module> IOError: [Errno 2] No such file or directory: '/var/cache/univention-system-setup/profile' ---------- 8< ---------- This comes from the UCR template file usr/share/univention-system-activation/www/entries.json, there is no check for the existence of the profile file. Could you please add a check for this, as well?
UCS4.1-1: r68137: * use array for ucr parameters * catch IOError in entries.json ucr template Package: univention-system-activation Version: 1.0.1-7.55.201603161203
r68138: YAML
A little typo :) ... ---------- 8< ---------- root@ucs-3513:~# ucr search --brief auth/sudo auth/sudo: yes string auth/sudo: no ---------- 8< ---------- And please set auth/<type>/restrict, as well, otherwise SSH is not restricted.
UCS4.1-1: r68141: * more restrictions, make sure auth/$service/restrict=yes is set, typo fixed Package: univention-system-activation Version: 1.0.1-8.56.201603161322 r68142: YAML
Another observation, instead of setting auth.* UCR variables to default values manually, I would opt for reconfiguring the univention-pam package, i.e.: > dpkg -l univention-pam > /dev/null 2>&1 && dpkg-reconfigure univention-pam
UCS4.1-1: r68143: reconfigure pam instead of setting UCR values manually to default values Package: univention-system-activation Version: 1.0.1-9.57.201603161421 r68144: YAML
Created attachment 7539 [details] Patch for correct call in postrm See the attached patch... the call in the prerm is not correct and could be replaced with an appropriate call in prerm (+ a check that dpkg is not running).
UCS4.1-1: r68147: Fix for prerm & postrm Package: univention-system-activation Version: 1.0.1-10.58.201603161614 r68148: YAML
Looks good now :) !
<http://errata.software-univention.de/ucs/4.1/135.html> <http://errata.software-univention.de/ucs/4.1/136.html>