NotesAgent.RunOnServer bei nicht aktivierten Agenten

[Peter Klett]

Habe gerade eine (zumindest für mich) interessante Entdeckung gemacht.

In alten Notesversionen (5?) war es so, dass ein periodischer Agent, der nicht aktiviert war, per NotesAgent.RunOnServer gestartet werden konnte. Er lief dann mit den Rechten des Agentensignierers. Später (in 6 oder 7) ging das nur noch, wenn der Agent aktiviert war.

Das hatte ich bisher als Sicherheitsfeature verstanden und auch als gut empfunden. Denn sonst baut man in eine Datenbank einen periodischen Agenten ein, lässt vom Admin die Datenbank signieren (damit ist dann auch der Agent signiert), und kann den danach beliebig laufen lassen (nicht den Admin, den Agenten ). Administrativ hat man keine Chance, sich dagegen zu wehren, außer den Agenten zu löschen, aber in welchem Unternehmen gibt es solch eine Qualitätssicherung, bei der so etwas auffallen würde.

Nun ziehen wir gerade auf einen neuen Server um. Version 8.5.3 auf Linux 2.6.32. Dort hatten wir fälschlicherweise Agenten deaktiviert, können die aber mit NotesAgent.RunOnServer starten. Die Sicherheitslücke ist also wieder da. Oder gibt es eine Einstellung am Server, die das verhindert, und die wir vergessen haben, zu setzen?

[ata]

... also wenn es da was geben sollte, dann würde ich in das Server-Dokument schauen. Ich denke hier ist doch die Sicherheit verdrahtet...

Toni

[Peter Klett]

Hab da mal das Serverdokument durchgesehen und nichts gefunden. Den Effekt, dass es in der alten Version ging und in der neuen nicht mehr, hatte ich auch auf meinen lokalen Testservern, und da hatte ich praktisch keine Sicherungsbeschränkungen eingestellt (alle dürfen alles).

[ata]

... als Sicherheitsfeature wäre mir das aber nicht in den Sinn gekommen. Je nach Konstrukt kann man damit allerhand anstellen...

Toni

[Peter Klett]

... als Sicherheitsfeature wäre mir das aber nicht in den Sinn gekommen. Je nach Konstrukt kann man damit allerhand anstellen...

Toni

Unter Sicherheitsfeature verstand ich, dass es NICHT funktioniert, wenn der Agent NICHT AKTIVIERT ist. Nun geht es auch wieder, obwohl der Agent nicht aktiviert ist, also ist die Lücke wieder offen.

[it898ur]

Hallo,

als Lücke würde ich das nicht unbedingt interpretieren, da ich ja auch andere (nicht periodische) Agenten per RunOnServer ausführen kann - die können ja per se nicht aktiviert werden. Warum sollte man hier also zwischen periodisch und nicht periodisch unterscheiden.

Eine Sicherheitslücke tut sich aus meiner Sicht nur auf, wenn der Code im periodischen Agenten so konzipiert ist, dass er Unsinn anstellt, wenn er zur falschen Zeit läuft. Im Normalfall sollte der Code so konzipiert sein, dass er entweder nur etwas macht, was er sowieso nahezu immer machen könnte oder sich entsprechend absichert, dass er nur dann und dort läuft, wo er laufen soll.

Gruß

André

[Peter Klett]

Dass man nicht periodische Agenten per RunOnServer laufen lassen kann, wusste ich nicht (auf die Idee wäre ich nicht gekommen, und hab das daher auch nie probiert). Da es zumindest in Notes 7 nicht ging, wenn der Agent nicht aktiviert war, will ich das auch noch nicht glauben. Muss ich wohl mal nachstellen, wenn Zeit ist.

Unter Sicherheitslücke verstehe ich nicht, dass technisch etwas falsch läuft (Agent läuft zur falschen Zeit), sondern organisatorisch. Im Klartext: Bewusste Platzierung von Schadcode. Hier wäre das Code, der durch einen User mit höheren Rechten (DB-Signierer) durch Anstoß eines Entwicklers mit weniger Rechten läuft. Z.B. ausspionieren von Mailfächern oder anderen Datenbanken, Manipulation von Dokumenten u.s.w..

Wenn ich dafür sensibel wäre, würde ich mein Augenmerk vorallem auf Agenten richten, die mit höheren Rechten (z.B. periodisch) ausgeführt werden. Spätestens, wenn sie aktiviert werden, sollte eigentlich klar sein, was die machen. Jetzt laufen die auch ohne Aktivierung, und da sehe ich die Lücke.

[it898ur]

Also für viele Dinge sind "remote" Serveragenten, d. h. nicht periodische Agenten, die mit RunOnServer laufen sinnvoll. Und da das nur funktioniert, wenn die Agenten mit den richtigen IDs signiert sind, liegt die Sicherheitslücke bei der Signierung.

Wenn der Admin ohne zu prüfen, von wem ein Code ist diesen signiert, dann kann man nicht mehr helfen. Ein gewisses Vertrauen zwischen Entwicklern und Admins ist natürlich unumgänglich, da kaum ein Admin in der Lage ist den vollständigen Code eines Programms einzuschätzen.

D. h. im Zweifelsfall kann der Code auch ganz offen in einem aktiven periodischen Agenten liegen (entsprechende kriminelle Energie beim Entwickler vorausgesetzt). Einen Sicherheitsunterschied zwischen aktiviert und nicht aktiviert sehe ich hier nicht.

Gruß

André

[Peter Klett]

Ohne dieses Thema zu breit auswalzen zu wollen, noch ein Nachsatz:

Die Schuld dem Signierer zu geben, halte ich für falsch. In der Praxis ist es doch so, dass eine Datenbank bei Produktivnahme KOMPLETT signiert wird, allein schon deshalb, um eine saubere Steuerung der ECL zu ermöglichen.

In dem Freigabeprozess sollte man sich dann die sicherheitskritischen Elemente anschauen. Und das sind vor allem die Elemente, die mit ANDEREN Rechten ausgeführt werden. Alle anderen Elemente sehe ich grundsätzlich unkritisch an, da sie ja mit den Rechten des angemeldeten Benutzers laufen. D.h. wenn nicht das Programm diese Aktion ausgeführt hätte, hätte es der Benutzer manuell selbst tun können, da er die Rechte dazu hat (natürlich kann ich auch Schadfunktionen so einbauen, dass sie dann von den Benutzern mit den von mir gewünschten Rechten manuell ausgeführt werden, das hat aber eine andere Qualität und die Gefahr der Entdeckung ist da m.E. größer, außerdem kann ich da schlechter den Zeitpunkt der Ausführung bestimmen).

Als sicherheitskritische Elemente bleiben also zu aktivierende Agenten. Und wenn man in diesen nach kritischen Schlüsselwörtern sucht, kann man m.E. recht schnell solche Schweinereien finden. Kritische Schlüsselwörter sind m.E. Funktionen wie

Execute
Evaluate
Save
Send
Remove

Wenn nun alle Agenten betroffen sind, müsste man sich alle anschauen, unabhängig davon, ob sie aktiviert werden sollen, oder nicht. Und das ist sicherlich vielen nicht bewusst (mir auch erst wieder seit heute).

Solche Agenten laufen dann auch in Schablonen oder archivierten Datenbanken, aber das ist ein anderes Thema. Die alte Lösung fand ich auf jeden Fall besser, aber das ist auch nur meine persönliche, revisisonsgeschädigte, Meinung.

[koehlerbv]

Ich kann das nicht nachvollziehen oder ich habe Dich nicht richtig verstanden, Peter:
Bei mir laufen ohne weiteres scheduled agents im status "deactivated" - unter 5 bis 8.5.

Bernhard

[Peter Klett]

Ich kann das nicht nachvollziehen oder ich habe Dich nicht richtig verstanden, Peter:
Bei mir laufen ohne weiteres scheduled agents im status "deactivated" - unter 5 bis 8.5.

Bernhard

Na gut, dann war es vielleicht ein Zufall, und ich hatte gedacht, es ginge nicht mehr ab 6 oder 7. Möglicherweise waren damals Signaturen defekt gewesen, und durch das Aktivieren wurden die natürlich repariert. Und das hatte ich fälschlicherweise so interpretiert, wie ich es oben geschildert hatte. Da ändere ich meine Aussage dahin, dass ich es gut gefunden hätte, wenn Agenten nur im aktivierten Zustand hätten gestartet werden können.

Begeistert bin ich davon nicht, denn ansonsten halte ich Notes für ein - wenn nicht sogar DAS - Werkzeug, mit dem man tolle, revisionssichere Anwendungen bauen kann.

[koehlerbv]

Hallo Peter,

ich will das Thema hier auch nicht weiter auswälzen - das wäre, wenn dann schon - einen extra Thread wert.
A-Bär: Der Entwickler, der ansonsten keinen Manager-Zugriff oder gar Full Admin Access hat, kann an x möglichen anderen Stellen Code unterbringen, der dort das (unheilvolle) verbringt, was er gerne möchte.
Revisionssicher heisst ja auch, dass der auszuführende Code einer Revision zu unterliegen hat, bevor man dem Entwickler vertraut.

Bernhard