In diesem Abschnitt sollen nun die Schnittstellen jener Entitäten untersucht werden, an denen Aktionen von anderen Subjekten des Modells ausgeführt werden können. Diese entsprechen den ``Kommunikationspartnern'' aus Tabelle. 3.2. Hierzu soll u.a. dargestellt werden, wie die Schnittstellen definiert sind und ob ihre Benutzung autorisiert wird bzw. dies vorgesehen ist.
Die Begriffe CORBA-Schnittstelle bzw. Java-Schnittstelle meinen dabei Funktionalität, die über den CORBA- bzw. Java-Kanal nutzbar sind.
In der Implementierung sind diese CORBA-Schnittstellen völlig ungesichert, was bedeutet, daß jedes beliebige lokale oder entfernte CORBA-Objekt (d.h. damit auch Agenteninstanzen, Applets, Client-Programme und indirekt Benutzer) diese ungehindert benutzen können. Eine Autorisierung findet weder statt, noch ist sie vorgesehen (weder in MASA selbst, noch im verwendeten ORB).
Zusätzlich zu den CORBA-Schnittstellen existieren jedoch
auch noch Methoden, die über den Java-Kanal erreichbar sind. Diese
werden in den Klassen Agent,
StationaryAgent und MobileAgent definiert
und werden vom Agentensystem für Verwaltungsaufgaben (z.B. vor und
nach einer Migration) an der Agenteninstanz benötigt:
Dabei sind sowohl die genannten Basisklassen für Agenten public deklariert, als auch diese Methoden selbst. Die Verwendung der Methoden wird dabei nicht autorisiert. Eine Autorisierung ist auch nicht vorgesehen. Weiterhin sind teilweise aber auch Attribute der jeweiligen Klassen als public deklariert.
Beispielsweise durch die Methode initTransient(...) entsteht dabei für eine Agenteninstanz die Möglichkeit interne Attribute des Agentensystems zu manipulieren, womit das Agentensystem massiv beeinträchtigt werden kann.
Durch die Art der Deklaration und die fehlende Autorisierung sind
neben den CORBA-Schnittstellen nun auch jegliche Java-Schnittstellen
ungeschützt, und können, zumindest von Komponenten auf dem gleichen
Agentensystem (bzw. der gleichen JVM) ungehindert genutzt werden.
Die Problematik des offenen Java-Kanals gilt dabei auch gleichzeitig
für die Methoden, die die CORBA-Schnittstelle implementieren. Diese
müssen nach dem IDL-to-Java Mapping ([OMG 98-04-03]) als
public deklariert werden. Damit können aber, wiederum
innerhalb des gleichen Agentensystems, Methoden der
CORBA-Schnittstelle (selbst wenn diese gesichert wäre) über den
Java-Kanal ungehindert erreicht werden.
Im Falle der Attribute der Klasse Agent, besteht aber noch ein weiteres Risiko. Selbst wenn die Attribute durch die Deklaration protected nicht von fremden Klassen benutzt werden können, sind diese vor Manipulation durch Tochterklassen nicht geschützt. Das bedeutet, daß jede Agenteninstanz, da sie immer durch eine Tochterklasse von Agent implementiert ist, diese Attribute frei verändern kann. Kritisch ist dies bei solchen Attributen, die der Agenteninstanz zwar lesend zur Verfügung stehen sollen, aber nicht verändert werden dürfen. MASA verwaltet einige solcher Attribute direkt in der Klasse Agent. Nachfolgend zwei Beispiele für eine mögliche Gefährdung durch solche ungesicherten Attribute.
Das Attribut _name, durch das die Identität der Agenteninstanz festgelegt wird, darf nur vom startenden Agentensystem einmalig gesetzt werden. In der bisherigen Implementierung kann eine Instanz dieses Attribut jedoch beliebig manipulieren, und damit ihre Identität verändern.
Ein weiteres Beispiel für einen konkreten Angriff liefert das Attribut _code_base. Durch diesen Wert wird bestimmt, wo der ausführbare Code der Agentengattung zu finden ist. Manipuliert eine Agenteninstanz diesen Wert, so kann sie ein ``Trojanisches Pferd'' implementieren, in dem sie einen neuen Ort des zu ladenden Codes angibt. Später wird von Agentensystemen dann zur Ausführung der Instanz der Code vom neuen Ort benutzt. Implementiert der dort zu findende Code dann eine neue Funktionalität, so ist der Angriff gelungen.
Neben den vor der Laufzeit bekannten Schnittstellen kann eine
Agenteninstanz beliebig neue Schnittstellen zur Laufzeit nach außen
einrichten. Da die Erstellung von IP-Sockets nicht überwacht wird,
ist es einer Agenteninstanz möglich über einen IP-Socket eine neue
Schnittstelle zu schaffen, um damit beispielsweise unbemerkt Daten zu
versenden und zu empfangen.
Auch im Fall der Java-Schnittstelle zeigt sich ein zu den Agenten identisches Bild. Besonders kritisch sind dabei interne Java-Schnittstellen des Agentensystems. In der Implementierung ist die Funktionalität des Agentensystem auf zwei Hauptklassen aufgeteilt: AgentSystem und AgentManager. Zur internen Kommunikation der beiden Klassen wird der Java-Kanal benutzt. Die zugehörigen Schnittstellen sind aber ebenfalls von allen Java-Objekten des gleichen Agentensystems wegen ihrer public Deklaration erreichbar. Exemplarisch sei hier die Methode registerAgentManager(...) erwähnt. Sie dient zur Anmeldung weiterer AgentManager-Objekte, die benötigt werden, um Agenten anderer Agentensysteme auf MASA ausführen zu können (vgl. [Bran 99]).
Zur Bewertung kann man anmerken, daß die Problematik der Java-Schnittstelle von Agentensystemen zwar strukturell identisch zu jener der Agenten ist, allerdings sind die Auswirkungen bezüglich der Sicherheit noch kritischer. Während durch ungesicherte Agenten sich diese zwar gegenseitig beeinflussen können, wird in diesem Fall aber die Sicherheit des gesamten Agentensystems beeinträchtigt.
Somit kann jeder Agent alle durch das Java-API angebotenen Aktionen auf dem Endsystem ausführen. Beispielsweise können beliebige Operationen auf Dateien (lesen/schreiben/löschen) vorgenommen werden oder neue Prozesse auf dem Endsystem gestartet werden.
Da für Managementanwendungen häufig privilegierte Rechte im Endsystem notwendig sind, werden Agentensysteme in vielen Fällen unter einer privilegierten Benutzerkennung des Endsystems ausgeführt. Gepaart mit dem ungeschützten Java-API öffnet sich für Agenten damit die ``Büchse der Pandora'' an Angriffsmöglichkeiten denen das Endsystem schutzlos ausgeliefert ist.