Security Update Notification for Admins

1 Initial Problem

ILIAS doesnt provide any check, whether it is up to date - it has to be done manually. As a result:

• some of ILIAS Installations are out of date (regarding minor and/or major updates)
• not everyone is aware of the involved risks

The situation is bad for the whole ILIAS community - from users, organizations to service providers. No one wants vulnerable ILIAS installations and it can also lead to bad PR for the whole product if a single instance gets hacked due to missing updates.

2 Conceptual Summary

ILIAS provides a mean to check for updates regularly. The check is active by default, but can be turned off (with a warning hint, that this is not recommended).

NOTE: At the same time the central version check service could gather pseudonymized statistics about the distribution of ILIAS versions still in use to guide the developer community in decisions and communication about future updates and EOL deadlines

The admin mailing list should be advertised additionally.

2.1 Proof Of Concept (Plugin)

The UpdateNotification plugin (https://github.com/SuitsU/IliasUpdateNotification) was developed as a Proof Of Concept to discuss how Update Notifications could look like.

The PoC-plugin checks the release tags from the public GitHub API which provides enough information for basic update notifications. However it lacks more advanced information like End Of Life dates or fixed mantis tickets, security notes, etc.

Checks are done via Cron-Task in configurable intervals.

Update Notifications for Minor and Major Updates are provided both as System Notifications and ILIAS Mails to users with certain global roles (default: Administrator).

2.2 Server API Mockup

To provide more rich update information the ILIAS open source e-Learning e.V. (=ILIAS e.V.) should provide a central REST-service for version checks.

The following example Request + Response is an early sketch to inspire further discussions.

3 User Interface Modifications

3.1 List of Affected Views

• … { Please list titles of all views (screens) of ILIAS that should be modified, newly introduced or removed. }

3.2 User Interface Details

{ For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour. }

3.3 New User Interface Concepts

{ If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this. }

3.4 Accessibility Implications

{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }

4 Technical Information

According to Fabian Schmid, the notification feature would not be placed in Administrative Notifications: ADN is currently the only consumer of the GlobalScreen scope "System Notifications". In principle, each component can attach itself to this slot and issue its own notifications, which means that an existing service or a new service can issue such messages here. The only question then is which service issues these notifications.

{ The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Privacy

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

6 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

• Author of the Request: Kiegel, Colin [kiegel]
• Maintainer: t.b.d.{Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: t.b.d. {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

9 Discussion

2023-04-03 Kiegel, Colin [kiegel]: Cronjob - Pro / Contra

Nicht jeder Admin konfiguriert notwendigerweise die Cronjobs - was dem niedrigschwelligen Zugang zu Update Notifications entgegen steht.

Alternative Auslöser könnten zum Beispiel sein, wenn ein User mit Rolle ADMIN sich einloggt. Eine Prüfung auf Updates bei jedem Admin-Login hätte natürlich den Vorteil, dass es auch ohne Cronjob funktioniert. Andererseits hat es den Nachteil, den Login-Prozess in die Länge zu ziehen und dass die Benachrichtigung ausbleibt, wenn sich kein Admin einloggt.

Ich fände es sinnvoller, bei Admin-Login eine separate Notification einzublenden, wenn der letzte Cronjob-Run länger als 48 Stunden zurückliegt „Achtung: Für diese ILIAS-Installation werden derzeit keine Cronjobs ausgeführt – regelmäßige Cronjobs sind für einen ordnungsgemäßen Betrieb von ILIAS essenziell. Bitte prüfen Sie Ihre ILIAS-Installation und stellen Sie sicher, dass Cronjobs mindestens einmal am Tag ausgeführt werden.“. Mit diesem Mechanismus könnten wir dann die Update-Prüfung m.E. ruhigen Gewissens in einem Cronjob ausführen, was ich für insgesamt vorteilhafter halte.

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.