original in en Serge Lozovsky
en to nl Tom Uijldert
Een groot probleem met de beveiliging van Unix is dat de superuser (gebruiker root) alles kan doen met het systeem wat hij maar wil. Er zijn achtergrond programma's (daemons) die met dit soort privileges werken. popd bijvoorbeeld en sendmail zijn toegankelijk via het netwerk (Internet/Intranet). Fouten kunnen in ieder programma zitten, de indringer kan via het netwerk verbinding leggen met dit soort programma's en zo dit soort fouten vinden en misbruiken om uiteindelijk de controle te krijgen over deze machines.
VXE (Virtual eXecuting Environment) beschermt Unix servers tegen dergelijke indringers, aanvallen vanuit het netwerk, enzovoorts. Het beveiligt bepaalde subsystemen zoals SMTP, POP, HTTP en ieder ander systeem wat geïnstalleerd is op het netwerk. Hiervoor hoeven de instellingen niet te worden veranderd - alleen maar BEVEILIGD.
Aldus lost VXE de volgende problemen op: beveiliging van de machine en bepaalde subsystemen die werken met superuser privileges en fouten kunnen bevatten. Dit is de realiteit.
Deze restricties kunnen zo slim als nodig worden aangebracht. Als een indringer de controle krijgt
over een dergelijk subsysteem dan kan hij niet via dat programma op zoek gaan naar additionele
informatie of het systeem beïnvloeden. Alles wat hij in theorie met geavanceerde methoden
kan doen is het OS beïnvloeden maar niet het OS zelf, noch andere subsystemen. De
normale methode hierbij is dat de indringer privileges verkrijgt en hiermee een interactief
programma opstart (shell) om vervolgens tekst-editors of het copy
-commando
te gebruiken voor beïnvloeding van het systeem. Zonder deze hulpmiddelen kan hij niets
uithalen. Een POP server bijvoorbeeld heeft geen behoefte aan een tekst-editor of het
copy
commando voor het uitvoeren van zijn werk, daarom is dit niet
beschikbaar in de beveiligde VXE omgeving waarin POPD werkt.
Om precies te zijn beveiligd VXE het (sub-)systeem tegen beïnvloeding via een ander ingebroken subsysteem (die onder de VXE omgeving werkt). Als neveneffect beveiligt het ook het subsysteem tegen zichzelf (op de manier als boven omschreven). Voor de eenvoud zullen we in het vervolg stellen dat VXE subsystemen beveiligd.
Er zijn twee methoden om VXED te activeren. Expliciet en impliciet (automatisch). Expliciet kan
het met het vxe programma. De parameters zijn de VXED padnaam, pad en
parameters van het programma wat zal worden uitgevoerd met de restricties. Voor de
automatische methode zullen alle benodigde VXEDs van tevoren door vxed in
de kernel worden ingeladen. Iedere VXED heeft een patroon voor activering. Tijdens de start van
een programma (exec()
) zal de kernel het pad van opstarten controleren op
het bijbehorende patroon en de betreffende VXED activeren. Deze methode kan worden gebruikt
voor het activeren tijdens de start van een programma in een opgegeven directory (en alle
subdirectories). Om bijvoorbeeld CGI-scripts van gebruikers te beveiligen kan men VXEDs
definiëren voor de subdirectory van iedere gebruiker.
Een dergelijke exercitie geeft als uitvoer beschrijvingen van toegestane (gebruikte) systeemfuncties. Het aanmaken en veranderen van een VXED kan met behulp van een WWW interface. Het ontwikkelsysteem ondersteunt twee soorten VXED. Strikte- en bestandssysteem typen. De strikte VXED beschrijft expliciet alle toegestane systeemfuncties. Bestandssysteem VXED beschrijft lees- en schrijfrechten voor een gegeven pad. Deze restricties slaan op bestandstoegang, alle andere systeemfuncties zijn toegestaan. Na het aanmaken van een VXED voor een subsysteem zal het in soft mode werken. Hierin wordt alle misbruik door VXED vastgelegd maar de systeemfunctie wordt wel uitgevoerd. Het VXE ontwikkelsysteem kan automatisch een VXED veranderen als de vastgelegde informatie dit vereist.
Uiteraard kunnen benodigde veranderingen handmatig worden aangebracht met de VXED editor. Inbreuk kan het gevolg zijn van indringers of door een afwijking in het gedrag van een subsysteem onder verschillende omstandigheden. De VXE beheerder bekijkt de log met behulp van het ontwikkelsysteem en baseert hierop een beslissing. Als er geen inbreuken meer te constateren zijn dan kan VXE in de production mode. Hierbij worden inbreuken weer vastgelegd en systeemfuncties worden geblokkeerd. Nogmaals, de vastlegging (log) kan worden gebruikt voor het detecteren van een indringer of voor een fijnafstemming met VXED.
Om beveiligingsredenen kan men alleen VXE aansturen vanuit de superuser en altijd buiten VXE om.
VXE ondersteuning:
vxe@intes.odessa.ua
VXE home page:
http://www.intes.odessa.ua/vxe