Sudo exploit

[jimshatt]

Hoi,

Ik ben onlangs aan het experimenteren geweest met sudo op een Debian desktop met Gnome. Ik ben tot de ontdekking gekomen dat ik met een vrij simpel shell script (een minder opvallend procesje dat op de achtergrond in de context van die user draait werkt ook) op het moment dat de gebruiker sudo gebruikt en zijn password heeft ingetypt in een terminal window, keystrokes naar dat window kan sturen en zo vanuit het ongeprivilegieerde proces sudo commando's kan uitvoeren.

Hier is mijn blog post hierover.

Ik ben absoluut geen expert op dit gebied en ik kan niet inschatten of dit een big deal is of dat het gewoon werkt zoals het hoort.

Nu moet je natuurlijk al een proces kunnen draaien in naam van die gebruiker, dus je bent ergens al 'binnen', maar dan zou je als het systeem goed dichtzit niet moeten kunnen sudo-en, toch?

Anyway, alle op- en aanmerkingen zijn welkom!

[vanaalten]

Mischien dat ik 'm niet snap, maar: als je al een script kan draaien onder die gebruiker, dan zal je toch zijn login-gegevens (incl. wachtwoord) al hebben? Dan kan je toch ook al direct via sudo commando's uitvoeren?

[jimshatt]

Daar zat ik dus ook over te twijfelen.

Normaal gesproken als je een gebruiker malafide code kan uit laten voeren, via een mail attachment of browser/javascript exploit of iets dergelijks, dan weet je het password van de gebruiker niet. Die code kan je het leven op zich al zuur maken maar buiten de context van de gebruiker verder niets.

Door te wachten totdat de gebruiker sudo gebruikt, krijg je ineens een mogelijkheid voor privilege escalation.

Zie ook: Wikipedia: Arbitrary code execution

[ Voor 14% gewijzigd door jimshatt op 31-03-2020 16:37 . Reden: Referentie ]

[Vloris]

En daarom wordt je in de handleiding van sudo ook zo gewaarschuwd dat het over het algemeen een slecht idee is om mensen via sudo overal rechten op te geven.

Sudo is bedoeld voor dit soort zaken, als je gebruikers niet vertrouwd dat ze goed met hun security omgaan moet je ze geen sudo rechten geven.

Als je sudo inzet om bepaalde gebruikers rechten te geven op bepaalde applicaties dan is er niks aan de hand, tenzij in die bepaalde applicaties ook nog een privilege escalation lek zit.

[LEDfan]

Dit lijkt me inderdaad iets dat niet gewenst is. Als ik het juist hebt, zijn dit soort dingen de rede dat we van X.org weg willen en overstappen naar wayland.
Gelijkaardig is dat veel screenshot tools niet standaard meer onder wayland werken, net omdat er extra restricties zijn.
Je zou dus misschien eens kunnen uitzoeken of dit onder wayland nog steeds mogelijk is.

In X.org is er ook een programma "xhost", dat access controle doet voor processen die met de X.org server willen verbinden. Maar ik vermoed dat dit programma je exploit niet zal voorkomen.

[Verwijderd]

Volgens mij ga je er van uit dat die gebruiker dan een shell start met sudo (blog niet gelezen overigens)

Als ik twee terminals open. In één ‘sudo <programma>’ uitvoer en m’n wachtwoord typ kan vanuit de andere terminal afaik alleen input naar ‘programma’ gestuurd worden. Daar kun je niet zoveel mee in de meeste gevallen.

Het hele idee van sudo is nu juist dat je géén terminal / shell met root-rechten opent voor beheer. Of dat je gebruikers een beperkt aantal programma’s kunt laten uitvoeren (niet bash!) die root-rechten nodig hebben.

Wat je volgens mij ontdekt hebt is hoe je met sudo de ‘beveiligingsdeur’ onbedoeld te ver open zet Ook cool om te ontdekken

[jimshatt]

@Vloris Dat is een goede observatie. Als enige gebruiker op mijn systeem heb ik natuurlijk sudo rechten, en die zijn standaard in de distro die ik gebruik zodanig dat ik met sudo alles mag.

Toen mijn vrouw en kinderen nog een gebruiker hadden op mijn systeem kregen die geen sudo rechten, behalve mijn dochter om een .iso van een barbie CD-ROM te kunnen mounten en starten

Het is een hoop werk om sudo goed te configureren zodanig dat je niet alles of niets mag. Maar in de meeste gevallen is de administrator van een systeem wel slim genoeg om geen willekeurige meuk van het internet te draaien. Maar als een pakket dat je gebruikt kwetsbaar is kun je alsnog de sjaak zijn.

Overigens een trend bij het installeren van willekeurige software op Linux tegenwoordig is het wget of curl en dan pipen naar sudo bash. Dat vind ik altijd een beetje zorgelijk.

[jimshatt]

@Verwijderd

Als ik twee terminals open. In één ‘sudo <programma>’ uitvoer en m’n wachtwoord typ kan vanuit de andere terminal afaik alleen input naar ‘programma’ gestuurd worden. Daar kun je niet zoveel mee in de meeste gevallen.

Dat is nu precies wat niet het geval is. Wat ik ontdekt heb is dat als ik twee terminals open en in een daarvan sudo uitvoer, ik vanuit de tweede terminal keystrokes naar de eerste terminal kan sturen en daarmee sudo commando's kan laten uitvoeren.

Edit: sorry, ik begreep je verkeerd. Nadat <programma> klaar is kun je nog een tijdje sudo commando's uitvoeren zonder een wachtwoord in te hoeven typen. Dat is je window of opportunity om vanuit een ander window (of losstaand programma) sudo commando's als keystrokes naar het terminal window te sturen.

[ Voor 24% gewijzigd door jimshatt op 31-03-2020 17:14 ]

[Verwijderd]

Installeren van software hoort dan ook voorbehouden te zijn aan mensen die weten waar ze mee bezig zijn - op alle operating systemen

Edit: nu wel je (@jimshatt) blogpost gelezen. Die password timeout is gewoon ‘evil’. Behalve voor systeembeheer (daarvoor daarom liever een root-shell) is het ook niet gebruikersonvriendelijk imho.

[ Voor 43% gewijzigd door Verwijderd op 31-03-2020 17:17 ]

[jimshatt]

Verwijderd schreef op dinsdag 31 maart 2020 @ 17:09:
Installeren van software hoort dan ook voorbehouden te zijn aan mensen die weten waar ze mee bezig zijn - op alle operating systemen

Dat is waar, maar de praktijk is anders. Daarom heb je op Windows UAC. En daarom implementeert Microsoft geen sudo functionaliteit, omdat je daarmee de UAC zou kunnen omzeilen.

Een geprivilegieerd window kan geen keystrokes ontvangen van ongeprivilegieerde windows. Dit is zowel onder Windows als Linux het geval.

[jimshatt]

LEDfan schreef op dinsdag 31 maart 2020 @ 17:02:
Je zou dus misschien eens kunnen uitzoeken of dit onder wayland nog steeds mogelijk is.

Dat is inderdaad een leuk experiment. Zal ik uitproberen.

[DaFeliX]

jimshatt schreef op dinsdag 31 maart 2020 @ 14:51:
Hoi,

Ik ben onlangs aan het experimenteren geweest met sudo op een Debian desktop met Gnome. Ik ben tot de ontdekking gekomen dat ik met een vrij simpel shell script (een minder opvallend procesje dat op de achtergrond in de context van die user draait werkt ook) op het moment dat de gebruiker sudo gebruikt en zijn password heeft ingetypt in een terminal window, keystrokes naar dat window kan sturen en zo vanuit het ongeprivilegieerde proces sudo commando's kan uitvoeren.
[...]

Dit is geen probleem van sudo, maar van de X display server. Dit is een vrij bekend probleem met X server. Er is wel een alternatief, wayland, waar dit probleem niet in zit.

Je hebt helaas geen zeroday voor sudo gevonden; je kunt alle keyboard input vanuit alle applicaties lezen, dus ook wat je typt in je browser op tweakers.net

jimshatt schreef op dinsdag 31 maart 2020 @ 14:51:

[...]

Ik ben absoluut geen expert op dit gebied en ik kan niet inschatten of dit een big deal is of dat het gewoon werkt zoals het hoort.

[...]

Zet je dit ook even in je blog post er bij, dan weet iedereen dit die je blog leest

[ Voor 33% gewijzigd door DaFeliX op 31-03-2020 20:48 ]

[jimshatt]

DaFeliX schreef op dinsdag 31 maart 2020 @ 20:44:
[...]


Dit is geen probleem van sudo, maar van de X display server. Dit is een vrij bekend probleem met X server. Er is wel een alternatief, wayland, waar dit probleem niet in zit.

Je hebt helaas geen zeroday voor sudo gevonden; je kunt alle keyboard input vanuit alle applicaties lezen, dus ook wat je typt in je browser op tweakers.net


[...]


Zet je dit ook even in je blog post er bij, dan weet iedereen dit die je blog leest

Het klopt dat de X server het mogelijk maakt naar willekeurige windows (in dezelfde user context) keystrokes te sturen. Sudo verergert het probleem doordat je nu binnen de password timeout sudo commando's naar een ander window kan sturen. Het is geen zero day, en zelfs niet eens een bug, maar wel een design flaw imho.
In het geval van Wayland kun je met uinput een virtueel device creëren in userspace, en die events laten sturen.

Zal een disclaimer bij mijn blogpost zetten. Dank voor de suggestie.

[jimshatt]

Verwijderd schreef op dinsdag 31 maart 2020 @ 17:09:
Edit: nu wel je (@jimshatt) blogpost gelezen. Die password timeout is gewoon ‘evil’. Behalve voor systeembeheer (daarvoor daarom liever een root-shell) is het ook niet gebruikersonvriendelijk imho.

Een root-shell heeft hier inderdaad geen last van omdat je daar geen keystrokes naar kan sturen. Ik koos eigenlijk altijd voor sudo omdat je in een root-shell makkelijker onherstelbare fouten kan maken.

[Thralas]

jimshatt schreef op dinsdag 31 maart 2020 @ 22:11:
In het geval van Wayland kun je met uinput een virtueel device creëren in userspace, en die events laten sturen.

En hoewel Wayland een flinke verbetering is, is het 'probleem' van je stelling dat je aanval al rechten op het systeem vereist (als de gebruiker van je slachtoffer).

Zodra je je realiseert dat je niets wat je ziet of intikt meer kunt 'vertrouwen' als dat het geval is, dan blijkt dat de belangrijkste boodschap.

Wie zegt dat de password prompt van sudo immers nog wel van sudo is?

sudo laat je zaken uitvoeren met de rechten van een andere gebruiker, maar is expliciet niet bedoeld om de andere 'gebruiker' te beschermen tegen misbruik van die (toegekende) rechten.

Dat is tevens ook de reden dat 'sudo' überhaupt zien als 'beveiligingslaag' (sudo-to-root) een extreem fragiele (en m.i. zinloze) toepassing is. Om rechten te delegeren icm. een stukje (beperkte) auditing is het wel nuttig.

[ Voor 14% gewijzigd door Thralas op 31-03-2020 22:41 ]

[jimshatt]

Thralas schreef op dinsdag 31 maart 2020 @ 22:33:
[...]


En hoewel Wayland een flinke verbetering is, is het 'probleem' van je stelling dat je aanval al rechten op het systeem vereist.

Zodra je je realiseert dat je niets wat je ziet of intikt meer kunt 'vertrouwen' als dat het geval is, dan blijkt dat de belangrijkste boodschap.

Wie zegt dat de password prompt van sudo immers nog wel van sudo is?

sudo laat je zaken uitvoeren met de rechten van een andere gebruiker, maar is expliciet niet bedoeld om de andere 'gebruiker' te beschermen tegen misbruik van die (toegekende) rechten.

Dat klopt, maar een ACE exploit op zich is nog niet zo heel gevaarlijk, zolang het in de context van die user blijft. Die sudo timeout maakt een privilege escalation mogelijk. Je hebt niet voor niets verschillende lagen, anders is het alles of niets en kun je net zo goed sudo geen password laten vragen, of erger, altijd als root inloggen.

Hoe zou je de password prompt van sudo kunnen faken als je geen root access hebt?

Edit:

Dat is tevens ook de reden dat 'sudo' überhaupt zien als 'beveiligingslaag' (sudo-to-root) een extreem fragiele (en m.i. zinloze) toepassing is. Om rechten te delegeren icm. een stukje (beperkte) auditing is het wel nuttig.

Excuus, hier had ik overheen gelezen. Helemaal mee eens. Dat is eigenlijk de kern van mijn argument / blog post. Sudo (to root) als beveiligingslaag is fragiel.
Heel nauwkeurig geconfigureerde sudo is extreem krachtig, maar dat ben ik in de praktijk (toegegeven, beperkte ervaring) nog nooit tegen gekomen.

[ Voor 20% gewijzigd door jimshatt op 31-03-2020 22:49 ]

[Thralas]

jimshatt schreef op dinsdag 31 maart 2020 @ 22:45:
Hoe zou je de password prompt van sudo kunnen faken als je geen root access hebt?

Niets weerhoudt iemand met toegang tot jouw account ervan om een alias te zetten (alias sudo=cowsay). Of $PATH te wijzigen.

[jimshatt]

Thralas schreef op dinsdag 31 maart 2020 @ 23:09:
[...]


Niets weerhoudt iemand met toegang tot jouw account ervan om een alias te zetten (alias sudo=cowsay). Of $PATH te wijzigen.

Ah ja, slim. Dan ben je de sigaar inderdaad. Dus eigenlijk is een root-shell dan nog de beste optie, al zal daar ook iets van gksu oid aan te pas komen. Of PolicyKit / Polkit? Is dat ook zo makkelijk te omzeilen?

[_JGC_]

@jimshatt root shell met gksu (ook al zo'n deprecated k*t tool) doet ook niks tegen dit probleem. We hebben het over X. Zodra je toegang hebt tot de displayserver kan je gewoon alle vensters lezen en schrijven, ook als dat programma door een andere user met toegang is gestart.

Er is een reden waarom Wayland en MIR zijn gebouwd, dit is er eentje van.

[DaFeliX]

jimshatt schreef op dinsdag 31 maart 2020 @ 22:11:
[...]


Het klopt dat de X server het mogelijk maakt naar willekeurige windows (in dezelfde user context) keystrokes te sturen. Sudo verergert het probleem doordat je nu binnen de password timeout sudo commando's naar een ander window kan sturen

[...]

Hoe verergert sudo iets? Je hebt een script dat het wachtwoord kan lezen dat je intypt. Dan kun je toch gewoon echo $readInput | sudo -S touch /root/owned uitvoeren; dat je toevallig sudo gebruikt, maar verder niets uit.

[jimshatt]

DaFeliX schreef op woensdag 1 april 2020 @ 07:12:
[...]


Hoe verergert sudo iets? Je hebt een script dat het wachtwoord kan lezen dat je intypt. Dan kun je toch gewoon echo $readInput | sudo -S touch /root/owned uitvoeren; dat je toevallig sudo gebruikt, maar verder niets uit.

Nee, ik heb geen script dat het wachtwoord uitleest. Ik heb een script dat zonder het wachtwoord nodig te hebben sudo commando's uitvoert in het venster waar je zojuist hebt gesudo't.

[jimshatt]

_JGC_ schreef op dinsdag 31 maart 2020 @ 23:49:
@jimshatt root shell met gksu (ook al zo'n deprecated k*t tool) doet ook niks tegen dit probleem. We hebben het over X. Zodra je toegang hebt tot de displayserver kan je gewoon alle vensters lezen en schrijven, ook als dat programma door een andere user met toegang is gestart.

Er is een reden waarom Wayland en MIR zijn gebouwd, dit is er eentje van.

Het zal inderdaad zo zijn dat als je wat dieper in X duikt misschien alle windows kan lezen en schrijven. Met xwininfo en xvkb lukt dat in ieder geval niet.

Maar als ik het goed begrijp is de treurige conclusie dus gewoon dat als iemand user access heeft weten te bemachtigen, ook zonder wachtwoord te weten (bijvoorbeeld via malware oid), root access maar een heel klein stapje verder is. In ieder geval wanneer de user admin/sudo rechten heeft.

[_JGC_]

@jimshatt Met X helaas wel ja. Die architectuur stamt uit de jaren 70, is door de jaren heen helemaal versierd met extenties als een grote kerstboom en uiteindelijk was de conclusie dat er een compleet ander model moest komen en daar was Wayland.

[kodak]

jimshatt schreef op dinsdag 31 maart 2020 @ 22:45:
Dat is eigenlijk de kern van mijn argument / blog post. Sudo (to root) als beveiligingslaag is fragiel.

Heel nauwkeurig geconfigureerde sudo is extreem krachtig, maar dat ben ik in de praktijk (toegegeven, beperkte ervaring) nog nooit tegen gekomen.

Als een beheerder en gebruiker geen blijk geven de handleiding van sudo goed te hebben gelezen, de beveiligingsgevolgen niet snapt, de principes van least privileges niet kent en al gaat klagen dat iemand een wachtwoord moet invoeren om verhoogde rechten te krijgen dan denk ik niet dat het aan sudo ligt.

Ik lees in de blog post eerder dat de gebruiker die te makkelijk maar tools om de hoogste rechten weg te geven gaat gebruiken de zwakste schakel in de beveiliging is.

De regels voor sudo en hogere rechten krijgen zijn simpel: De beheerder heeft voldoende verstand van wat sudo is. De beheerder heeft goede kennis van beveiligingsprincipes. Het gewone account heeft geen verhoogde rechten nodig. Als het account toch verhoogde rechten nodig heeft dan is dat meestal nite zo tenzij er heel goede redenen voor zijn. Als dat er is dan geeft de beheerder alleen de rechten die nodig zijn voor die redenen en niet meer. Die rechten worden alleen gegeven zolang het nodig is. Om misbruik te voorkomen zorg je dat iemand die de rechten krijgt ze ook goed weet te gebruiken en ook de risico's snapt. Om het risico verder te beperken zorg je er voor dat er een password opgegeven moet worden zodat niet iedere onverlaat die toegang krijgt tot een account omdat de gebruiker de screen vergeet te locken of roekeloos scripts gaat draaien de verhoogde rechten weg geeft. Het spreekt voor zich dat de beheerder dat allemaal al kent. De beheerder zorgt er voor dat die in de gaten kan houden dat de rechten niet misbruikt worden. Als de rechten misbruikt worden worden die ingetrokken en de schade ongedaan gemaakt. Mocht de beheerder gebrek aan kennis blijken te hebben over beveiliging en sudo dan moet die eens heel goed gaan nadenken of die maar beter geen beheerder kan gaan spelen.

sudo is geen tool dat je even laat gebruiken zonder handleiding te lezen of beveiliging te snappen. Microsoft is ook niet voor niet (erg laat pas) least privileges door gaan voeren terwijl dat bij besturingssystemen waar sudo sinds 1993 uit voort komt al jaren heel gewoon was.


Meer informatie over sudo:
https://www.sudo.ws/

Of je dochter die sudo rechten nodig had om die barbie iso te mounten en unmounten betwijfel ik. Daarvoor kan je bijvoorbeeld ook de fstab aanpassen. Misschien wil je toch controleren of ze je systeem niet alvast overgenomen heeft. Je weet het tegenwoordig maar nooit met de jeugd

Hoewel debian heel leerzaam kan zijn krijg heb ik mijn bedenkingen dat het geschikt is voor een windows gebruiker die vooral uit gaat van gemak als een gebruiker in plaats van inrichting en onderhoud als een beheerder. Sinds 2004 is er bijvoorbeeld Ubuntu dat veel meer gericht is om als (windows) gebruiker kennis mee te maken. Misschien past die oplossing dan meer om het gebrek aan kennis en kundigheid te overbruggen.

[jimshatt]

@_JGC_ Eens, maar het lijkt erop dat met een beetje gepiel met de uinput library hetzelfde mogelijk is. Ik heb dit niet uitgeprobeerd, maar de docs geven mij wel die indruk.

@kodak Ik ben het gedeeltelijk met je eens. Maar als je een redelijk standaard distro voor thuisgebruikers installeert, zeg Ubuntu, dan moet je in de installer een gebruiker aanmaken die gewoon sudo rechten krijgt. Zonder grote waarschuwingen of een dik handboek door te hoeven lezen. Ik vermoed dat de meeste gebruikers op een Linux desktop inloggen met een gebruiker die sudo rechten heeft. Hetzelfde geldt voor Windows overigens, maar daar is deze specifieke truuk (ik zal het geen exploit noemen) niet mogelijk.

In situaties waarin je traditioneel een systeembeheerder en meerdere gebruikers hebt (bedrijven, universiteiten, etc.) heb je natuurlijk volledig gelijk. Dan deel je geen sudo rechten uit, tenzij daar een heel specifieke reden voor is.

Voor thuis is het misschien ook een idee om een gewone gebruiker zonder sudo-rechten aan te maken en alleen als ik systeembeheer ga doen te switchen naar de gebruiker met admin rechten. Hoe doe jij dat?

In de tijd dat mijn dochter de barbie iso moest mounten geloof ik niet dat dat standaard mogelijk was binnen Gnome, zoals nu gewoon door te dubbelklikken. Maar ik had sudo zo ingesteld dat alleen die iso op die plek te mounten was, zonder wachtwoord (dan zou het te moeilijk voor haar zijn). Ik vond het vanuit een systeembeheerdersoogpunt een beetje raar om een specifieke iso in fstab op te nemen, maar dat zou een optie zijn geweest inderdaad. Maar misschien heeft ze toen een rootkit geïnstalleerd en ben ik al 10 jaar volledig gepwned!

[ Voor 15% gewijzigd door jimshatt op 01-04-2020 22:36 ]

[kodak]

Bij thuisgebruik ga ik er ook vanuit dat accounts niet zomaar hogere rechten moeten kunnen gebruiken. Iets wat in de praktijk ook normaal lijkt als je een moderne os gebruikt. De eigenaar is thuis vaak ook de beheerder maar je gaat voor normaal gebruik niet een account gebruiken met standaard beheer rechten. In plaats daarvan is er een tussenoplossing: die gebruiker heeft een gewoon account met de mogelijkheid om bewuster tijdelijk hogere rechten te gebruiken. Wil je hogere rechten? Dan zul je aan moeten geven dat je dat wil en dat je je kan authenticeren met bijvoorbeeld het benodigde wachtwoord. En het liefst nog op die manier dat als je die aanvraag doet het zo specifiek is dat die rechten alleen van toepassing zijn op wat nodig is. En bij al die andere gebruikers stel je thuis de vraag of je die wel zoveel rechten wil geven, of je de moeite wil van selectieve rechten of lastig vallen van de gebruiker met hogere rechten.
En als de gebruiker met de hogere rechten dan door krijgt dat andere ook misbruik kunnen proberen te maken dat het account? Bij macht komt ook verantwoordelijkheid.

[jimshatt]

kodak schreef op donderdag 2 april 2020 @ 09:24:
In plaats daarvan is er een tussenoplossing: die gebruiker heeft een gewoon account met de mogelijkheid om bewuster tijdelijk hogere rechten te gebruiken. Wil je hogere rechten? Dan zul je aan moeten geven dat je dat wil en dat je je kan authenticeren met bijvoorbeeld het benodigde wachtwoord. En het liefst nog op die manier dat als je die aanvraag doet het zo specifiek is dat die rechten alleen van toepassing zijn op wat nodig is.

Dat is een beetje hoe men nu sudo gebruikt, namelijk dat je standaard geen beheerrechten hebt en dat als je dat tijdelijk nodig hebt je je wachtwoord in moet voeren.
Kun je sudo zo configureren dat je per specifieke taak een ander wachtwoord in moet voeren? Of is er een tool wat daar beter voor geschikt is?

Een UAC-achtige popup waar geen input events naar toe te sturen zijn vanuit andere processen binnen de context van de gebruiker zou misschien een uitkomst zijn.

[kodak]

jimshatt schreef op donderdag 2 april 2020 @ 15:10:
Kun je sudo zo configureren dat je per specifieke taak een ander wachtwoord in moet voeren?

Dat hangt er vanaf wat je verstaat onder een specifieke taak en welke risico's je daarmee wil voorkomen.

Je beveiliging is niet sterker dan het zwakste onderdeel. Als je iemand rechten geeft om je systeem aan te passen en dat wil je scheiden van toegang tot het mounten dan is je hoogste risico waarschijnlijk niet dat een onbevoegde kan mounten maar dat die mogelijk toegang geeft tot account en het wachtwoord om je systeem aan te kunnen passen.

Als je je zorgen maakt dat een gebruiker onbewust code laat uitvoeren om wachtwoorden af te vangen en de taak is het openen van een shell met verhoogde rechten om het hele systeem aan te kunnen passen dan heeft die scheiding weinig zin. Dan kan je er maar beter voor zorgen dat die gebruiker geen onveilig code kan uitvoeren en geen toegang tot zoveel mogelijkheden heeft. Of je neemt het risico door te zorgen dat je wel genoeg vertrouwen hebt dat de persoon geen code gaat uitvoeren die tot heel veel problemen gaat leiden (en zorg je voor oplossingen om eventuele problemen snel te detecteren en te herstellen zoals altijd).