Domino 9 und frühere Versionen > ND8: Entwicklung

NotesAgent.RunOnServer bei nicht aktivierten Agenten

<< < (2/3) > >>

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete