Bug 39700 - univention-system-activation: On non-master systems, root ssh restrictions are not removed
univention-system-activation: On non-master systems, root ssh restrictions ar...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: General
UCS 4.0
Other Linux
: P5 normal (vote)
: UCS 4.1-1-errata
Assigned To: Jürn Brodersen
Alexander Kläser
:
Depends on:
Blocks: 40913
  Show dependency treegraph
 
Reported: 2015-11-02 12:24 CET by Erik Damrose
Modified: 2016-03-18 15:22 CET (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
univention-system-setup.patch (5.44 KB, patch)
2016-02-05 17:18 CET, Eduard Mai
Details | Diff
univention-system-activation.patch (4.86 KB, patch)
2016-02-05 17:22 CET, Eduard Mai
Details | Diff
Patch for help text (1.24 KB, patch)
2016-03-14 16:14 CET, Alexander Kläser
Details | Diff
Patch for setting UCR variables via global array (1.54 KB, patch)
2016-03-16 05:45 CET, Alexander Kläser
Details | Diff
Patch for correct call in postrm (2.16 KB, patch)
2016-03-16 15:35 CET, Alexander Kläser
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Damrose univentionstaff 2015-11-02 12:24:49 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
Comment 1 Erik Damrose univentionstaff 2015-11-02 12:28:22 CET
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.
Comment 2 Alexander Kläser univentionstaff 2016-01-28 18:30:35 CET
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.
Comment 3 Eduard Mai univentionstaff 2016-02-05 17:18:47 CET
Created attachment 7455 [details]
univention-system-setup.patch

WIP changes for univention-system-setup
Comment 4 Eduard Mai univentionstaff 2016-02-05 17:22:00 CET
Created attachment 7456 [details]
univention-system-activation.patch

WIP changes univention-system-activation
Comment 5 Eduard Mai univentionstaff 2016-02-18 16:53:52 CET
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
Comment 6 Alexander Kläser univentionstaff 2016-03-02 17:54:12 CET
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.
Comment 7 Eduard Mai univentionstaff 2016-03-03 14:55:57 CET
UCS4.1-1:

r67873: removed setting up of root restrictions from postinst file
Package: univention-system-activation
Version: 1.0.1-4.52.201603031445
Comment 8 Alexander Kläser univentionstaff 2016-03-14 16:14:12 CET
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.
Comment 9 Jürn Brodersen univentionstaff 2016-03-15 11:39:49 CET
UCS4.1-1:

r68093: Changed help text
r68095: YAML
Package: univention-system-activation
Version: 1.0.1-4.52.201603031445
Comment 10 Alexander Kläser univentionstaff 2016-03-15 15:06:30 CET
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
Comment 11 Alexander Kläser univentionstaff 2016-03-15 15:31:38 CET
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 ..."
Comment 12 Jürn Brodersen univentionstaff 2016-03-15 18:38:33 CET
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
Comment 13 Jürn Brodersen univentionstaff 2016-03-15 18:41:39 CET
r68119: YAML
Comment 14 Alexander Kläser univentionstaff 2016-03-16 05:45:52 CET
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).
Comment 15 Alexander Kläser univentionstaff 2016-03-16 06:00:48 CET
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?
Comment 16 Jürn Brodersen univentionstaff 2016-03-16 12:08:39 CET
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
Comment 17 Jürn Brodersen univentionstaff 2016-03-16 12:11:56 CET
r68138: YAML
Comment 18 Alexander Kläser univentionstaff 2016-03-16 12:54:33 CET
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.
Comment 19 Jürn Brodersen univentionstaff 2016-03-16 13:30:10 CET
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
Comment 20 Alexander Kläser univentionstaff 2016-03-16 14:03:42 CET
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
Comment 21 Jürn Brodersen univentionstaff 2016-03-16 14:26:49 CET
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
Comment 22 Alexander Kläser univentionstaff 2016-03-16 15:35:40 CET
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).
Comment 23 Jürn Brodersen univentionstaff 2016-03-16 16:18:15 CET
UCS4.1-1:

r68147: Fix for prerm & postrm
Package: univention-system-activation
Version: 1.0.1-10.58.201603161614

r68148: YAML
Comment 24 Alexander Kläser univentionstaff 2016-03-16 16:36:27 CET
Looks good now :) !