[LINUX] Bestuur systeem vanuit webpage

[Charles Nasi]

Beste tweakers,

Een tijdje terug heb ik ook een topic geopend over hoe ik een Linux-systeem (Ubuntu in mijn geval) kan besturen via een web-interface. Nu had ik in dat topic wat tips gekregen om te kijken naar eBox en naar het pakket WebMin. Ik heb beide pakketten getest, en de sources bekeken, maar kom er niet echt wijs uit.

Wat ik wil gaan bouwen:
- Via een webpagina inloggen in de interface (En dit moet dan tevens direct gekoppeld zijn aan de linux- rechtenstructuur)
- Mogelijk maken om .sh scripts uit te voeren met de webinterface.
- Commando's op het systeem uitvoeren.

Het systeem gaat twee verschillende interfaces krijgen, namelijk een eindgebruiker interface en een technici-interface.

Op de linux-doos draai ik momenteel LAMP met Apache2. Distributie is Ubuntu Server. Het project is een stageproject.

Nu heb ik een klein stukje code gemaakt:

PHP:

 <?php

// parameter 'p' has been set > check
if(isset($_GET['p']))
{
    $p = $_GET['p'];
    // shutdown server
    if($p == 'servershutdown')
    {
        $output = shell_exec('shutdown -h now');
        echo "<p>" . $output . "</p>"; 
        echo "<p>Shutting down the server...</p>";
    }
    // reboot server
    elseif($p == 'serverreboot')
    {
        $output = shell_exec('shutdown -r now');
        echo "<p>" . $output . "</p>";
        echo "<p>Server is now rebooting....</p>";
    }
    // parameter error > no valid value
    else
        echo "Not valid value!.";
}
// parameter 'p' contains no value
else
    echo "No value entered!";
?> 

Uiteraard werkt dit stukje code niet, omdat de Apache2 user niet in root-modus draait. Is het mogelijk om dit toch te kunnen? Ben geen voorstander om de Apache2 user / webuser in root te laten draaien, dus zoek eigenlijk een nette oplossing.

[RedHat]

in /etc heb je toch de scripts staan?

(shutdown is volgens mij gewoon een scriptje).

Geef Apache rechten op het scriptje shutdown, et voila?

[Spider.007]

Je zou de apache user sudo-rechten kunnen geven; maar een goede beveiliging wordt dan wel steeds belangrijker Evenwel zal dat precies zijn hoe bijvoorbeeld webmin werkt

RedHat schreef op woensdag 18 maart 2009 @ 16:41:
in /etc heb je toch de scripts staan?

(shutdown is volgens mij gewoon een scriptje).

Geef Apache rechten op het scriptje shutdown, et voila?

nee, shutdown is geen scriptje; het is een binary die alleen werkt als je voldoende rechten hebt; en anders gewoon zal zeggen "shutdown: you must be root to do that!"

[ Voor 55% gewijzigd door Spider.007 op 18-03-2009 16:46 ]

[DexterDee]

Als eerste wil ik even een dikke waarschuwing geven. Als je acties wilt uitvoeren onder superuser rechten, dan moet je verdomd goed weten dat je beveiliging op alle lagen goed in elkaar steekt. Ik zou de web interface achter https zetten met een self-signed certificaat en een degelijk login systeem maken met een client side salt, session hijack beveiliging, cross side scripting en sql injectie veilig, etc... Als deze onderwerpen je niks zeggen, dan is google je vriend. Als je hier geen rekening mee houdt en iemand met een beetje brains wil volledige controle over je linux systeem, dan ben je heel snel nat.

Ok, dan nu verder met je vraag...

Het makkelijkste om superuser rechten aan apache te geven is om een proxy bash scriptje te maken die uitvoert wat er aan parameters gegeven wordt. Dit scriptje voorzie je van de juiste 'sticky bit' en alles wat je ermee uitvoert zal als root gebeuren.

Persoonlijk zou ik (afgezien van het feit dat ik dit hele probleem anders zou benaderen) voor een iets elegantere oplossing gaan. Ik zou sudo inrichten zodat ik bepaalde commando's zonder password zou kunnen uitvoeren. Vervolgens zou ik met php en exec gewoon de commando's prefixen met sudo om ze als superuser uit te voeren. Dit is wel zo veilig, omdat je zelf kunt bepalen welke commando's wel en niet uitgevoerd kunnen worden onder root.

[Charles Nasi]

DexterDee schreef op woensdag 18 maart 2009 @ 16:50:
Als eerste wil ik even een dikke waarschuwing geven. Als je acties wilt uitvoeren onder superuser rechten, dan moet je verdomd goed weten dat je beveiliging op alle lagen goed in elkaar steekt.

Dit is ook een beetje mijn angst, het product wat ik aan het bouwen ben op mijn stageplek wordt dadelijk commercieel ingezet.. Oftewel, het moet zeer veilig zijn.

Ik ga daarom nu aan het googlen over sudo en het toekennen van sudo aan bepaalde commands. De binary 'shutdown' is eigenlijk een stom voorbeeld, maar dit is meer om door te krijgen hoe ik sudo command's kan uitvoeren onder de apache-user.

Gracias!

[NMe]

En daarmee is dit dus geen programmeerprobleem maar een kwestie van de juiste rechten zetten. Waar hoort mijn topic?

PRG>>NOS

[Charles Nasi]

NMe schreef op woensdag 18 maart 2009 @ 17:00:
En daarmee is dit dus geen programmeerprobleem maar een kwestie van de juiste rechten zetten. Waar hoort mijn topic?

PRG>>NOS

*Charles Nasi wist van tevoren niet of het een programming issue was of een rechtenissue Danku voor het schopje

[Storm90]

Misschien kom je wat verder als je dit topic leest:
http://www.webhostingtalk...ts-uitvoeren-via-php.html

En anders zou je misschien naar een FTP oplossing kunnen kijken?
Je kunt namelijk via php een ftp verbinding openen..
Aan de ene kant denk ik dat je wat meer problemen krijgt aangezien je nog meer op je beveiliging
moet gaan letten, maar wellicht een goede oplossing om scripts vanuit je root te runnen...

[ Voor 5% gewijzigd door Storm90 op 18-03-2009 17:28 ]

[berties]

Ik zou toch een stapje terug gaan, waarom kom je niet uit webmin?
Dat kan nooit een heel groot probleem zijn lijkt me (ga naar webmin.com download de debain package en voer "dpkg -i dedebianpackage.deb" uit). Moet zeker geen groter probleem zijn dan de voorgestelde functies op een veilige manier implementeren in een eigen gemaakte omgeving.
Webmin heeft een inlog die aan je (zoals je het zelf zegt) linux-rechtenstructuur gekoppeld is.
Webmin kan .sh scripts uitvoeren
Webmin kan ook andere commando's op het systeem uitvoeren.
Webmin kun je gebruiken als technici-interface en de usermin variant binnen webmin voor de eindgebruikers.
zie onderstaand bericht, heb het oudere topic niet gezien vandaar..


Apache als root is een onwenselijke situatie en zoals eerder gezegd; de kans op een volledige hack / rootkit is aanzienlijk. Als het commercieel ingezet gaat worden moet je al helemaal voorzichtiger te werk gaan.

[ Voor 4% gewijzigd door berties op 18-03-2009 18:20 ]

[DexterDee]

@Berties: Zover ik de bedoelingen snap van de TS is hij niet op zoek is naar een kant en klaar pakket wat zijn taken kan uitvoeren, maar een eigen script dat onderdeel wordt van een 'eigen product'. In dat licht zijn de perl sources van Webmin alles behalve duidelijk om als uitgangspunt te nemen. Webmin heeft zijn eigen reeks van 'exploits' gekend waartegen allerlei patches zijn gegooid. Dat geeft maar weer eens aan dat security flaws snel zijn gemaakt, zelfs door goede ontwikkelaars op grote projecten die heel goed weten waar ze mee bezig zijn. Het is een teken dat je het onderwerp security erg serieus moet nemen. Zeker als individuele (beginnend?) programmeur met minder overzicht en verstand van zaken. En al helemaal als je een oplossing commercieel wilt gaan aanbieden.

Aan de topicstarter kan ik nog de tip geven om ervoor te zorgen dat input data (bijvoorbeeld van de querystring of POST data) NOOIT één op één in een systeemcommando gebruikt wordt. Zorg altijd voor een waterdichte translatie van de input naar het daadwerkelijke commando. Als je bijvoorbeeld een proces wil killen, maak dan geen commando met 'kill ' . $_GET['pid'] of iets dergelijks. Want dan is het wachten totdat iemand een querystring als ?pid=0;rm+-rf+/ gaat gebruiken. Command injection is de meestvoorkomende fout als het gaat om scripts die execs doen.

[phobosdeimos]

Dit is geen goed idee.
Punt uit.

[Sypher]

Je kunt - mijns inziens - het beste een "agent" maken waarmee je op basis van HTTP kunt communiceren. Dit is een stuk veiliger, kan meer systemen dan alleen zijn eigen beheren en is gewoon sneller. Veel acties laten uitvoeren in PHP laat de gebruiker eindeloos wachten.

Het "Plesk" controlepaneel (heb je in jouw geval waarschijnlijk niets aan, maar goed:) doet dat ook en laat de gebruiker vaak nogal lang wachten op resultaat. Dat wil je natuurlijk ook niet.

Een andere optie is: PHP-SSH. Dit is een module waarmee je kunt SSH- en SCPen vanuit PHP. Het werkt best aardig, en is denk ik wel handig. Maar ja, het gaat om een lokaal systeem voor zover ik zie dus dan is het minder handig, maar alsnog niet "niet handig".

Zolang je Apache maar niet meer rechten geeft, dat is zo ... vies

[NMe]

phobosdeimos schreef op woensdag 18 maart 2009 @ 19:37:
Dit is geen goed idee.
Punt uit.

Leuk dat je dat vindt. Heb je daar ook argumenten blij, of blijft het bij een ononderbouwd schot in de ruimte.

Als je dit gewoon goed beveiligt kan er niet zoveel mis gaan.

[phobosdeimos]

NMe schreef op woensdag 18 maart 2009 @ 19:46:
[...]

Leuk dat je dat vindt. Heb je daar ook argumenten blij, of blijft het bij een ononderbouwd schot in de ruimte.

Als je dit gewoon goed beveiligt kan er niet zoveel mis gaan.

Dat dachten de makers van "webmin" wss ook, vandaar dat het een van de meest buggy software paketten is, en vrijwel in geen enkele linux distro standaard te installeren is.
In ongeveer elk doordeweekse PHP web applicatie worden dagelijks serieuze veiligheidslekken gevonden, en dat zijn dan nog maar eenvoudige toepassingen met weinig rechten zoals een forum of een blog, dan kan je wel raden wat een ellende je te wachten staat als je via een PHP web applicatie commando's als root gaat laten uitvoeren door gebruikers?

Ik geef weinig argumentatie omdat ik aanneem dat iedereen met een beetje development ervaring, en een basiskennis unix toch wel kan inzien dat dit helemaal geen goed idee is.

[ Voor 35% gewijzigd door phobosdeimos op 18-03-2009 19:50 ]

[H!GHGuY]

Een mogelijkheid is om voor elke gebruiker een script te maken

Bash:

#! /bin/bash

exec $@ </dev/null 2>&1

met sticky bit en user/group van de desbetreffende user. Vervolgens roep je afhankelijk van de authenticatie elk commando via het script van de correct gebruiker aan. Zorg er tevens voor dat gebruikers geen rechten hebben op de scripts van andere gebruikers (sr-x------) en dat de gebruiker zelf geen write rechten heeft op zijn script. Nog even toevoegen wel dat je in GEEN geval root-access op deze manier geeft. Jouw app kan misschien secure zijn, maar daarom is apache of de php module dit nog niet. Root-commando's moet je maar zien te doen via een secure manier zoals SSH.

Bescherm de locatie van alle kritische componenten (apache, php enz) nu met de standaard in linux aanwezige features.
Mogelijk wil je ook kijken naar chroot jails en andere beveiligings mogelijkheden.

Punt blijft wel dat phobosdeimos overschot van gelijk heeft.

Bovendien snap ik niet waarom je commando's over een webinterface wil gaan doen. Geef de mensen SSH access en een degelijk SSH client en je staat al even ver. Let trouwens op met interactieve commando's; bovenstaand script zorgt dat ze al meteen een EOF krijgen wat trouwens moet... Anders start Henkie even 50000 interactieve processen tot je OOM-killer je hele systeem afknalt. Wat trouwens nog steeds niet wegneemt dat ik gerust je server de lucht in kan doen vliegen:

code:

echo "..." >> evil.c  # een hele lap C/C++-code
while (true); do g++ evil.c -o evil.$$ & ; done

Met wat geluk is de OOM-killer even niet nauwkeurig en haal ik je halve systeem onderuit.

[ Voor 18% gewijzigd door H!GHGuY op 18-03-2009 20:08 ]

[lordgandalf]

Wat ik zou bouwen is een script met een beperkte functionaliteit.
Maak een script dat onder root draait dat om de zoveel tijd een database bekijkt en de hier in staande commando`s uitvoert.
En dan wel een omslag zodat je niet meteen commando`s niet direct uitvoert maar bij delete omzet naar rm enz.

[ny-hardcore]

Sypher schreef op woensdag 18 maart 2009 @ 19:42:
Je kunt - mijns inziens - het beste een "agent" maken waarmee je op basis van HTTP kunt communiceren. Dit is een stuk veiliger, kan meer systemen dan alleen zijn eigen beheren en is gewoon sneller.

ken het oude topic niet...maar dit "lijkt mij" de eleganste oplossing.

is het niet mogelijk om een 'client side app' te maken die via ssh ofzo iets doet op je linux doos?
http://www.jcraft.com/jsch/

[Verwijderd]

Storm90 schreef op woensdag 18 maart 2009 @ 17:27:
En anders zou je misschien naar een FTP oplossing kunnen kijken?
Je kunt namelijk via php een ftp verbinding openen..

ffs

[Verwijderd]

NMe schreef op woensdag 18 maart 2009 @ 19:46:
[...]

Leuk dat je dat vindt. Heb je daar ook argumenten blij, of blijft het bij een ononderbouwd schot in de ruimte.

Als je dit gewoon goed beveiligt kan er niet zoveel mis gaan.

Op het moment dat er een fout in de web applicatie zit is het een DOS attack (Van het volledige systeem; want je kan het systeem afsluiten..) .

Maar dat maakt niet zo veel uit, toch ?

[ Voor 8% gewijzigd door Verwijderd op 18-03-2009 21:22 . Reden: Maak het wat duidelijker ]

[Charles Nasi]

H!GHGuY schreef op woensdag 18 maart 2009 @ 20:02:
Bovendien snap ik niet waarom je commando's over een webinterface wil gaan doen. Geef de mensen SSH access en een degelijk SSH client en je staat al even ver. Let trouwens op met interactieve commando's; bovenstaand script zorgt dat ze al meteen een EOF krijgen wat trouwens moet... Anders start Henkie even 50000 interactieve processen tot je OOM-killer je hele systeem afknalt. Wat trouwens nog steeds niet wegneemt dat ik gerust je server de lucht in kan doen vliegen:

code:

echo "..." >> evil.c  # een hele lap C/C++-code
while (true); do g++ evil.c -o evil.$$ & ; done

Met wat geluk is de OOM-killer even niet nauwkeurig en haal ik je halve systeem onderuit.

Dat is juist het hele doel van het stageproject Mijn school vereist dat ik een informatiesysteem bouw. Dit wordt een Linux 'box' die er niet uitziet als server, maar toch een server is die alleen het NAS-gebeuren voor zich neemt. Nu weet het bedrijf waarvoor ik het moet bouwen dat er alternatieven zijn zoals een WD-MyBook (Die erg goed te hacken zijn) en QNAP nas-sen. Maar zij willen juist voor het MKB een linux systeem waarvan ze zelf de hardware kunnen onderhouden.

En de eindgebruiker moet een simpele interface hebben waarin de Linux-box herstart kan worden, nieuwe mappen/shares aangemaakt moeten kunnen worden en rechten op bestanden en mappen kunnen worden geconfigureerd.

Ook moet er informatie worden weergegeven over het systeem (CPU-temperatuur, vrije harddiskruimte, RAID-status) maar dan allemaal 'versimpelt' zodat de Henkie ermee uit de voeten moet kunnen.

De technische dienst gaat gewoon via SSH de server overnemen.

@Edit: De interface moet worden geprogrammeerd / gescript door mij. Dit wil mijn school zien.

[berties]

Kun je dan geen free-nas als basis nemen (of begrijp ik het nog steeds niet ), je zorgt dat dit een uitgeklede versie is met alleen het broodnodige. Deze maak je alleen toegankelijk via interne ip-adressen en je zet de ssh open voor remote ondersteuning vanaf een remote locatie.

[deadinspace]

Charles Nasi schreef op woensdag 18 maart 2009 @ 16:56:
Dit is ook een beetje mijn angst, het product wat ik aan het bouwen ben op mijn stageplek wordt dadelijk commercieel ingezet.. Oftewel, het moet zeer veilig zijn.

En dat is wel een beetje een probleem, want onervaren mensen (op gebied van systeembeheer en/of programmeren) zien vrij snel iets over het hoofd wat grote gevolgen voor security kan hebben. Zie bijvoorbeeld het command injection voorbeeld dat DexterDee aanhaalt, dat zijn hele reëele risico's (input checken/sanitizen is daarom heel belangrijk).

Om wat voor taken gaat het eigenlijk? Shutdown is makkelijk veilig te doen. Iets als apache herstarten ook. Dat zijn eenvoudige commando's waar verder geen input van de website in verwerkt hoeft te worden. Maar wat moet er nog meer kunnen? Instellingen aanpassen? Van wat? Daar zit mogelijk veel complexiteit en daardoor risico's.

Sudo is instelbaar om specifieke commando's (met beperkingen op de argumenten zelfs) passwordloos uitvoerbaar te maken voor specifieke users. Dat is waarschijnlijk de beste methode om de gewenste acties uitvoerbaar te maken voor Apache. Door sudo zo beperkt mogelijk in te stellen perk je eventuele risico's op dat punt in.

Het is bijvoorbeeld mogelijk om in te stellen dat "/sbin/shutdown" uitvoerbaar is als root door www-data, maar alleen met de argumenten "-h now". Op die manier voorkom je dat iemand die commands weet te injecten nare dingen kan doen door bepaalde argumenten aan shutdown mee te geven. Shutdown is een beetje een suf voorbeeld, maar er zijn bijvoorbeeld wel commando's waar je een locatie voor een output-bestand kan opgeven. Als je op een zelf te kiezen locatie als root een file kunt wegschrijven met controle over de inhoud van die file, dan heb je praktisch root. Denk bijvoorbeeld aan het overschrijven van /etc/passwd of /etc/shadow, het overschrijven van roots (of system-wide) shell-configuratie, het installeren van een cronjob, etc.

H!GHGuY schreef op woensdag 18 maart 2009 @ 20:02:
Een mogelijkheid is om voor elke gebruiker een script te maken [...] met sticky bit en user/group van de desbetreffende user. Vervolgens roep je afhankelijk van de authenticatie elk commando via het script van de correct gebruiker aan.

Dan kun je net zo goed sudo passwordloos open zetten voor die gebruiker. Dat is het zelfde idee, maar dan met minder moeite (en sudo kan nog loggen ook). Maar het is waarschijnlijk veel te liberaal.

De sticky bit doet trouwens op files niks onder GNU/Linux, ik denk dat je de setgid bit bedoelt. Niet dat setuid bits werken op scripts, maar dat terzijde

Zorg er tevens voor dat gebruikers geen rechten hebben op de scripts van andere gebruikers (sr-x------) en dat de gebruiker zelf geen write rechten heeft op zijn script.

De gebruiker zelf geen write-rechten op zijn script heeft weinig zin natuurlijk. Als je willekeurige commando's kan uitvoeren, dan zijn write-rechten op dat script maar één chmod verwijderd.

Jouw app kan misschien secure zijn, maar daarom is apache of de php module dit nog niet.

De ervaring leert dat in de overgrote meerderheid van de gevallen lekken in php scripts zitten, en niet in php zelf of Apache

[H!GHGuY]

Charles Nasi schreef op woensdag 18 maart 2009 @ 21:40:
[...]


Dat is juist het hele doel van het stageproject Mijn school vereist dat ik een informatiesysteem bouw. Dit wordt een Linux 'box' die er niet uitziet als server, maar toch een server is die alleen het NAS-gebeuren voor zich neemt. Nu weet het bedrijf waarvoor ik het moet bouwen dat er alternatieven zijn zoals een WD-MyBook (Die erg goed te hacken zijn) en QNAP nas-sen. Maar zij willen juist voor het MKB een linux systeem waarvan ze zelf de hardware kunnen onderhouden.

En de eindgebruiker moet een simpele interface hebben waarin de Linux-box herstart kan worden, nieuwe mappen/shares aangemaakt moeten kunnen worden en rechten op bestanden en mappen kunnen worden geconfigureerd.

Ook moet er informatie worden weergegeven over het systeem (CPU-temperatuur, vrije harddiskruimte, RAID-status) maar dan allemaal 'versimpelt' zodat de Henkie ermee uit de voeten moet kunnen.

De technische dienst gaat gewoon via SSH de server overnemen.

@Edit: De interface moet worden geprogrammeerd / gescript door mij. Dit wil mijn school zien.

Dit zijn al veel duidelijkere requirements. Het gaat namelijk niet over eender welk commando, maar over vooraf gedefinieerde use cases.

Zoals deadinspace aangeeft: configureer sudo zo restrictief mogelijk en laat dan je php script sudo gebruiken om de commando's uit te voeren. Definieer vooraf al de use-cases zeer grondig en script die dingen dan in je WebGUI. Geef in elk geval geen toegang tot eender welk commando.

[sam.vimes]

deadinspace schreef op woensdag 18 maart 2009 @ 21:49:
[...]
Het is bijvoorbeeld mogelijk om in te stellen dat "/sbin/shutdown" uitvoerbaar is als root door www-data, maar alleen met de argumenten "-h now". Op die manier voorkom je dat iemand die commands weet te injecten nare dingen kan doen door bepaalde argumenten aan shutdown mee te geven.
[...]

Je kunt zelfs voor iedere use-case een apart script schrijven (eventueel met goed voorgedefinieerde opties) en de apache-user alleen sudo-rechten geven op die specifieke scripts. In zo'n script kun je veel beter afregelen wat je wel en niet toestaat dan in de sudoers configuratie.

Bijvoorbeeld het shutdown-probleem: ik kan me voorstellen dat je een tijdstip wilt meegeven. Dan kun je in je script bepalen of shutdown wordt aangeroepen met "now" of met een tijdstip dat aan de regexp /^\d\d?:\d\d$/ voldoet.

Perl:

#!/usr/bin/perl -wT
use strict;
# set default time
my $time = "now";
# get time if given on command line
@ARGV>0 and $time = shift @ARGV;
# only one command line parameter allowed
@ARGV>0 and die "extra parameters not allowed\n";
# check format of $time
$time =~ /^(now|\d\d?:\d\d)$/ or die "invalid time: $time\n";
# untaint $time
$time = $1;
delete $ENV{PATH};
system("/sbin/shutdown", "-h", $time);
die "exec shutdown failed: $!\n";

Je ziet dat er 4 "die" statements bij mogelijke foutsituaties in het script staan, en dat is zelfs nog te weinig (er moet in principe nog een test op geldigheid van het tijdstip bij). Verder draait Perl in "taint" mode (optie -T in de eerste regel), zodat er nog wat extra veiligheidscontroles worden uitgevoerd (de regels 12 & 13 en de absolute padnaam in regel 14 zijn daar het gevolg van).
Dit is een algemeen gegeven: in zulke gevaarlijke situaties dat in principe iedereen als root commando's kan geven, moet je je back-end ontzettend goed dicht timmeren! Het is hierboven al vaker genoemd en het kan niet genoeg herhaald worden.

[silentsnake]

NMe schreef op woensdag 18 maart 2009 @ 19:46:
[...]

Leuk dat je dat vindt. Heb je daar ook argumenten blij, of blijft het bij een ononderbouwd schot in de ruimte.

Als je dit gewoon goed beveiligt kan er niet zoveel mis gaan.

Tja, je hebt opzich een punt, het is alleen een hele grotte vette als. Ik ben het opzich ook wel mee eens dat dit geen goed idee is. Iets als webmin wordt al jaren aan gewerkt door een heel team van mensen. Ik ben het ook wel met phobosdeimos eens dat dit simpelweg geen goed idee is.

Als er maar een beperkt aantal commando's nodig zijn is het opzich niet eens zo erg, maar dat is ook informatie die ik niet uit de TS heb kunnen achterhalen (of ik heb er overheen gelezen). Als de TS een tweede webmin wilt nabouwen zou ik er zeker op tegen zijn, al helemaal als het commercieel moet ingezet worden. Niet helemaal eerlijk om dit van een stagaire te verwachten, maar da's mijn mening.

Maar om antwoord te geven op de vraag van de TS: sudo inderdaad, wellicht in combinatie met een agent / daemon concept. Zeker in de daemon kan je allerlei gore hack attemps afvangen voordat je daadwerkelijk het commando gaat uitvoeren.

[DexterDee]

Een daemon maakt trouwens de hele opzet niet per definitie veiliger. Natuurlijk kun je de daemon onder andere rechten laten draaien dan root en apache, maar je zult nog steeds je commando's via een vorm van IPC moeten aanleveren. En die input moet sanitized zijn, anders voorkom je command injectie nog steeds niet.