Verder Terug Inhoud

12. Beveiligingszaken

Het pad is soms een groot beveiligingsprobleem. Het is een zeer algemene manier om een systeem te kraken door een aantal fouten in padinstellingen te gebruiken. Het is makkelijk om Trojan horse aanvallen te genereren als hacker aan root privileges of die van andere gebruikers kan komen om zijn versies van commando's uit te voeren.

Een veelvoorkomende fout in het verleden (?) was door de `.' in het pad van de root te houden. Een kwaadwillige hacker maakt een programma `ls' in zijn home-directory. Als root dan vervolgens doet

# cd ~hacker
# ls

voert hij het ls commando van de hacker uit.

Indirect geldt hetzelfde voor alle programma's die als root worden uitgevoerd. Ieder belangrijk daemon proces zou nooit iets moeten uitvoeren waarin een andere gebruiker iets weg kan schrijven. In een aantal systemen is het mogelijk om in /usr/local/bin programma's te plaatsen met minder strikte beveiligings afscherming. - het is slechts uit het pad van de root gebruiker verwijderd. Het is echter bekend dat een aantal daemon processen `foo' uitvoert door gebruik te maken van het pad `/usr/local/bin/:...', het zou mogelijk kunnen zijn om de daemon om de tuin te leiden om `/usr/local/bin/foo' in plaats van `/bin/foo' uit te voeren. Het is aannemelijk dat voor iemand die naar `/usr/local/bin' kan schrijven het mogelijk is om op het systeem in te breken.

Het is erg belangrijk te overwegen in welke volgorde de directory's in het pad staan. Als /usr/local/bin voor /bin staat, is dit een beveiligings risico - als het erachter staat, is het niet mogelijk het commando /bin/foo met wat plaatselijke wijzigingen in /usr/local/bin/foo te overschrijven.

Onder Linux zou er aan moeten worden gedacht dat de evaluatie van het pad op het system call level wordt afgehandeld. Overal waar een uitvoerbaar bestandspad wordt opgegeven kun je een verkorte naam opgeven waarnaar op z'n minst wordt gezocht vanuit /bin en /usr/bin - waarschijnlijk ook op vele andere plaatsen.


Verder Terug Inhoud