Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Voor een bestandssysteem vindt het grootste deel van het interessante beveiligingswerk plaats tijdens IRP_MJ_CREATE verwerking. Dit is deze stap die de binnenkomende aanvraag moet analyseren, bepalen of de beller de juiste rechten heeft om de bewerking uit te voeren en de bewerking indien van toepassing te verlenen of te weigeren. Gelukkig wordt voor ontwikkelaars van het bestandssysteem het grootste deel van het beslissingsmechanisme geïmplementeerd in de Security Reference Monitor. In de meeste gevallen hoeft het bestandssysteem dus alleen de juiste beveiligingsreferentiemonitorroutines aan te roepen om de toegang goed te bepalen. Het risico voor een bestandssysteem treedt op wanneer het deze routines indien nodig niet aanroept en ongepast toegang verleent aan een beller.
Voor een standaardbestandssysteem, zoals het FAT-bestandssysteem, zijn de controles die worden uitgevoerd als onderdeel van IRP_MJ_CREATE voornamelijk semantiekcontroles. Het FAT-bestandssysteem heeft bijvoorbeeld talloze controles om ervoor te zorgen dat IRP_MJ_CREATE verwerking is toegestaan op basis van de status van het bestand of de map. De controles van het FAT-bestandssysteem omvatten het controleren van alleen-lezen media (pogingen om destructieve 'create'-bewerkingen uit te voeren, zoals overschrijven of vervangen, op dit soort media zijn bijvoorbeeld niet toegestaan), controles op gedeelde toegang en oplockcontroles. Een van de moeilijkste onderdelen van deze analyse is te realiseren dat een bewerking op één niveau (bijvoorbeeld het bestandsniveau) mogelijk niet is toegestaan vanwege de status van een andere resource op een ander niveau (bijvoorbeeld het volumeniveau). Een bestand kan bijvoorbeeld niet worden geopend als een ander proces het volume exclusief heeft vergrendeld. Veelvoorkomende zaken die moeten worden gecontroleerd, zijn onder andere:
Is het bestandsniveau compatibel met de toestand van het volumeniveau? Vergrendeling op volumeniveau moet worden gerespecteerd. Als één proces dus een exclusief volumeniveauvergrendeling bevat, kunnen alleen threads binnen dat proces bestanden openen. Threads van andere processen mogen geen bestanden openen.
Is de open-status van het bestandsniveau compatibel met de mediastatus? Bepaalde 'create'-bewerkingen wijzigen het bestand als onderdeel van de bewerking 'maken'. Dit omvat het overschrijven, vervangen en zelfs het bijwerken van de laatste toegangstijd op het bestand. Deze „create‟-bewerkingen zijn niet toegestaan op alleen-lezen media en de laatste toegangstijd wordt niet bijgewerkt.
Is het volumeniveau compatibel met de status van het bestandsniveau? Een exclusief volume openen zou niet zijn toegestaan als er bestaande bestanden op het volume worden geopend. Dit is een veelvoorkomend probleem voor nieuwe ontwikkelaars omdat ze proberen het volume te openen en merken dat het mislukt. Als dit mislukt, kan FSCTL_DISMOUNT_VOLUME worden gebruikt om open ingangen ongeldig te maken en een ontkoppeling af te dwingen, waardoor exclusieve toegang tot het zojuist gekoppelde volume mogelijk is.
Daarnaast moeten bestandskenmerken compatibel zijn. Een bestand met het kenmerk Alleen-lezen kan niet worden geopend voor schrijftoegang. Houd er rekening mee dat de gewenste toegang moet worden gecontroleerd nadat de algemene rechten zijn uitgebreid. Deze controle in het FASTFAT-bestandssysteem bevindt zich bijvoorbeeld in de functie FatCheckFileAccess (zie het bronbestand Acchksup.c uit de fastfat-voorbeelden die de WDK bevat).
Het volgende codevoorbeeld is specifiek voor de FAT-semantiek. Een bestandssysteem dat OOK DACL's implementeert, zou een extra beveiligingscontrole uitvoeren met behulp van de routines van Security Reference Monitor (SeAccessCheck-, bijvoorbeeld.)
//
// check for a read-only Dirent
//
if (FlagOn(DirentAttributes, FAT_DIRENT_ATTR_READ_ONLY)) {
//
// Check the desired access for a read-only Dirent
// Don't allow
// WRITE, FILE_APPEND_DATA, FILE_ADD_FILE,
// FILE_ADD_SUBDIRECTORY, and FILE_DELETE_CHILD
//
if (FlagOn(*DesiredAccess, ~(DELETE |
READ_CONTROL |
WRITE_OWNER |
WRITE_DAC |
SYNCHRONIZE |
ACCESS_SYSTEM_SECURITY |
FILE_READ_DATA |
FILE_READ_EA |
FILE_WRITE_EA |
FILE_READ_ATTRIBUTES |
FILE_WRITE_ATTRIBUTES |
FILE_EXECUTE |
FILE_LIST_DIRECTORY |
FILE_TRAVERSE))) {
DebugTrace(0, Dbg, "Cannot open readonly\n", 0);
try_return( Result = FALSE );
}
Een subtielere controle die door FASTFAT wordt geïmplementeerd, is ervoor te zorgen dat de toegang die wordt aangevraagd door de beller iets is waarover het FAT-bestandssysteem zich bewust is (in de FatCheckFileAccess- functie in Acchksup.c uit het fastfat-voorbeeld dat de WDK bevat):
In het volgende codevoorbeeld ziet u een belangrijk concept voor bestandssysteembeveiliging. Controleer of wat wordt doorgegeven aan uw bestandssysteem niet buiten de grenzen valt van wat u verwacht. De conservatieve en juiste benadering vanuit het oogpunt van beveiliging is dat als u geen toegangsaanvraag begrijpt, u die aanvraag moet afwijzen.
//
// Check the desired access for the object.
// Reject what we do not understand.
// The model of file systems using ACLs is that
// they do not type the ACL to the object that the
// ACL is on.
// Permissions are not checked for consistency vs.
// the object type - dir/file.
//
if (FlagOn(*DesiredAccess, ~(DELETE |
READ_CONTROL |
WRITE_OWNER |
WRITE_DAC |
SYNCHRONIZE |
ACCESS_SYSTEM_SECURITY |
FILE_WRITE_DATA |
FILE_READ_EA |
FILE_WRITE_EA |
FILE_READ_ATTRIBUTES |
FILE_WRITE_ATTRIBUTES |
FILE_LIST_DIRECTORY |
FILE_TRAVERSE |
FILE_DELETE_CHILD |
FILE_APPEND_DATA))) {
DebugTrace(0, Dbg, "Cannot open object\n", 0);
try_return( Result = FALSE );
}
Gelukkig worden voor bestandssystemen, nadat de beveiligingscontrole is uitgevoerd tijdens de initiële aanmaakverwerking, de daaropvolgende beveiligingscontroles uitgevoerd door de I/O-manager. Zo zorgt de I/O-manager ervoor dat toepassingen in de gebruikersmodus geen schrijfbewerking uitvoeren op een bestand dat alleen is geopend voor leestoegang. Een bestandssysteem mag zelfs tijdens de IRP_MJ_WRITE verzendroutine geen semantiek met het kenmerk Alleen-lezen afdwingen, zelfs niet als het alleen is geopend voor leestoegang. Dit komt door de manier waarop de geheugenbeheerder een specifiek bestandsobject koppelt aan een bepaald sectieobject. Toekomstige schrijfbewerkingen via deze sectie worden verzonden als IRP_MJ_WRITE-bewerkingen op het bestandsobject, ook al is het bestand geopend als alleen-lezen. Met andere woorden, de toegangshandhaving wordt uitgevoerd wanneer een bestandsgreep wordt geconverteerd naar het bijbehorende bestandsobject bij Nt systeemservice-invoerpunt door ObReferenceObjectByHandle.
Er zijn twee extra plaatsen in een bestandssysteem waar semantische beveiligingscontroles moeten worden uitgevoerd die vergelijkbaar zijn met 'create'-verwerking:
Tijdens het wijzigen van de naam of het verwerken van vaste koppelingen.
Bij het verwerken van besturingsbewerkingen op het bestandssysteem.
Hernoemverwerking en de verwerking van bestandssysteembeheer worden in de volgende secties besproken.
Houd er rekening mee dat dit geen volledige lijst is van semantische problemen met betrekking tot 'create'-verwerking. Het doel van deze sectie is om aandacht te vestigen op deze problemen voor ontwikkelaars van het bestandssysteem. Alle semantische problemen moeten worden geïdentificeerd voor een specifiek bestandssysteem, geïmplementeerd om te voldoen aan de specifieke semantiek en getest om ervoor te zorgen dat de implementatie de verschillende gevallen afhandelt.