Op tal van systemen heeft een hoofdgebruiker volledig beheer over het systeem. In SUA (Subsystem for UNIX-based Applications) wordt een hoofdgebruiker niet herkend. Bij de ontwikkeling van de POSIX-standaard (Portable Operating System Interface) werd het concept van een hoofdgebruiker als een beheervraagstuk beschouwd. In plaats van een hoofdgebruiker worden in de POSIX-standaard de juiste bevoegdheden gedefinieerd voor bepaalde bewerkingen.
In dit onderwerp
Subsystem for UNIX-based Applications en identiteiten
Overwegingen bij het instellen van setuid in Subsystem for UNIX-based Applications
Setuid en setgid
Met de mechanismen setuid en setgid kunnen tijdens het uitvoeren van programma's bepaalde aspecten worden overgenomen van een andere beveiligings-principal dan die van de gebruiker die het programma uitvoert. Hierdoor kan het programma voor deze aspecten afwisselen tussen de gebruiker die het programma aanroept, en een andere beveiligings-principal.
Bij 'juiste bevoegdheden' is de benadering anders. Terwijl een toepassing dankzij de mechanismen setuid en setgid in staat is om antwoord te geven op de vraag: 'Wie bent u?', wordt met juiste bevoegdheden de vraag: 'Wat mag u doen?' beantwoord.
Subsystem for UNIX-based Applications en identiteiten
In de meeste UNIX-omgevingen worden alle bevoegdheden aan exact één gebruiker verleend. Deze gebruiker, die meestal root wordt genoemd, heeft uid == 0. In Subsystem for UNIX-based Applications worden alle bevoegdheden die op een bepaald systeem worden ondersteund, verleend aan gebruikers die lid zijn van de groep Administrators of de groep Domeinadministrators op dat systeem. Aanmelden als beheerder is niet meer nodig. Elke gebruiker die lid is van de groep Administrators of de groep Domeinadministrators, beschikt over de bevoegdheden van de root. Niet alle bevoegdheden die in POSIX of UNIX zijn gedefinieerd, zijn beschikbaar in SUA. Dit wil zeggen dat sommige bevoegdheden aan geen enkele gebruiker worden verleend.
Juiste bevoegdheden zijn doorgaans vereist voor een scala van acties. Voorbeelden hiervan zijn toegang tot het bestandssysteem, het verzenden van signalen naar andere processen (procesbeheer) of het wijzigen van de effectieve gebruikers-id (UID) of groeps-id (GID) voor een proces, zodat bepaalde acties door het proces kunnen worden uitgevoerd.
Volgens de POSIX-standaard beschikt een bestand over machtigingen met bits voor het instellen van een UID (setuid) en het instellen van een GID (setgid). Als voor een bestand een of beide bits zijn ingesteld en het bestand door een proces wordt uitgevoerd, krijgt het proces de UID of GID van het bestand. Als hiermee voorzichtig wordt omgegaan, kunnen niet-bevoegde gebruikers op deze manier programma's uitvoeren waarvoor de hogere bevoegdheidsniveaus gelden van de eigenaar van het bestand of van de groep. Bij onjuist gebruik vormt dit echter een beveiligingsrisico, omdat niet-bevoegde gebruikers wordt toegestaan om acties uit te voeren die eigenlijk alleen door een beheerder mogen worden uitgevoerd. Daarom wordt dit mechanisme niet standaard door SUA ondersteund. Bij een poging om een bestand uit te voeren waarvoor de bit setuid of de bit setgid is ingesteld, wordt het bestand dus niet door SUA uitgevoerd en wordt de foutcode ENOSETUID geretourneerd.
Overwegingen bij het instellen van setuid in Subsystem for UNIX-based Applications
Als u werkt met een toepassing waarvoor standaard POSIX-gedrag is vereist, kunt u SUA zodanig configureren dat bij het uitvoeren van bestanden de bits setuid of setgid worden ingesteld. Als SUA op deze manier is geconfigureerd, worden bij het uitvoeren van een bestand waarvoor de bits setuid of setgid zijn ingesteld, lokale beveiligingstokens voor het proces samengesteld met de bevoegdheden die aan de eigenaar van het bestand of aan de groep zijn toegewezen. Omdat het gaat om lokale tokens, worden deze niet herkend door andere computers in het netwerk. Dit wil bijvoorbeeld zeggen dat zelfs wanneer een lid van de groep Domeinadministrator eigenaar is van het bestand, het proces geen vertrouwde toegang heeft tot andere computers in het domein via de netwerkfuncties van Microsoft® Windows®. In plaats daarvan gelden de bevoegdheden uitsluitend op de computer waarop het proces wordt uitgevoerd.
Neem bijvoorbeeld een proces dat een programmabestand uitvoert waarvoor de bit setuid is ingesteld en waarvan een lid van de groep Domeinadministrators eigenaar is. Een poging van het programma om het wachtwoord van een domeingebruiker te wijzigen mislukt, omdat de beveiligingstokens van het proces lokaal zijn en dus niet worden herkend door andere systemen in het domein. Een poging van het programma om het wachtwoord van een lokale gebruiker te wijzigen, is echter wel succesvol, omdat de eigenaar van het bestand lid is van de groep Domeinadministrators, die meestal deel uitmaakt van de groep Administrators op de lokale computer. Zie de Help-bestanden bij het downloadpakket Utilities and Software Development Kit (SDK) for UNIX-based Applications voor meer informatie over het configureren van SUA voor het uitvoeren van bestanden waarvoor de bits setuid of setgid zijn ingesteld.
Voor de functies setuid(2), setgid(2) en chroot(2) moet het proces beschikken over de effectieve UID waarmee wordt verwezen naar het systeemaccount, het administratoraccount voor het lokale domein of het administratoraccount voor het principaldomein. Het lokale administratoraccount kan de UID of GID alleen wijzigen in een andere id in hetzelfde domein.
Voor chown(1), chmod(1) en chgrp(1) moet een account beschikken over de Windows-bevoegdheden SE_BACKUP en SE_RESTORE. Alleen dan is het mogelijk om make-bewerkingen uit te voeren op bestanden waarvan een andere gebruiker of groep eigenaar is, of om machtigingen te wijzigen voor een bestand waarvan een andere gebruiker eigenaar is. Deze machtigingen behoren meestal toe aan de accounts Administrator en Back-upoperator.