Identificateur de sécurité
Windows utilise l’identificateur de sécurité (SID) comme la valeur définitive pour distinguer les entités de sécurité les unes des autres. Par exemple, un identificateur de sécurité unique est attribué à chaque nouveau compte créé pour les utilisateurs individuels sur le système. Pour un système de fichiers, seul ce SID est utilisé.
La figure suivante illustre la structure de l’identificateur de sécurité.
En plus des SIDs uniques, le système Windows définit un ensemble d’identificateurs bien connus. Par exemple, l’Administrateur local est un SID bien connu.
Windows fournit un mécanisme intégré au noyau pour convertir entre les SIDs et les noms d’utilisateur dans l’environnement du noyau. Ces appels de fonction sont disponibles à partir du pilote ksecdd, qui implémente ces fonctions en utilisant des services auxiliaires en mode utilisateur. Par conséquent, leur utilisation au sein des systèmes de fichiers doit respecter les règles habituelles de communication avec les services en mode utilisateur. Ces appels ne peuvent pas être utilisés pendant les E/S du fichier d’échange.
Certaines de ces fonctions sont :
SecMakeSPN crée une chaîne de nom de fournisseur de services qui peut être utilisée lors de la communication avec des fournisseurs de services de sécurité spécifiques.
SecMakeSPNEx est une version augmentée de SecMakeSPN qui a été introduite dans Windows XP.
SecMakeSPNEx2 est une version augmentée de SecMakeSPNEx disponible à partir de Windows Vista et Windows Server 2008.
SecLookupAccountSid renvoie un nom de compte pour un SID spécifié.
SecLookupAccountName récupère le SID pour un nom de compte spécifié.
SecLookupWellKnownSid renvoie le SID correct pour un type d’identificateur bien connu spécifié. Cette fonction est disponible sur Windows Server 2003 et les versions ultérieures.
De plus, tout pilote du noyau peut créer un SID en utilisant les routines standard de la bibliothèque d’exécution suivantes :
RtlInitializeSid initialise un tampon pour un nouveau SID.
RtlLengthSid détermine la taille du SID stocké dans le tampon donné.
RtlValidSid détermine si le tampon SID donné est un tampon formaté valide.
RtlLengthSid et RtlValidSid supposent que l’en-tête fixe de 8 octets pour un SID est présent. Un pilote doit donc vérifier cette longueur minimale pour un en-tête SID avant d’appeler ces fonctions.
Bien qu’il existe plusieurs autres fonctions RTL, cette liste fournit les principales fonctions nécessaires à la construction d’un SID.
L’exemple de code suivant montre comment créer un SID pour l’entité « système local ». La fonction plus simple SecLookupWellKnownSid introduite dans Windows Server 2003 pourrait également être utilisée.
{
//
// temporary stack-based storage for an SID
//
UCHAR sidBuffer[128];
PISID localSid = (PISID) sidBuffer;
SID_IDENTIFIER_AUTHORITY localSidAuthority =
SECURITY_NT_AUTHORITY;
//
// build the local system SID
//
RtlZeroMemory(sidBuffer, sizeof(sidBuffer));
localSid->Revision = SID_REVISION;
localSid->SubAuthorityCount = 1;
localSid->IdentifierAuthority = localSidAuthority;
localSid->SubAuthority[0] = SECURITY_LOCAL_SYSTEM_RID;
//
// make sure it is valid
//
if (!RtlValidSid(localSid)) {
DbgPrint("no dice - SID is invalid\n");
return(1);
}
}
L’exemple de code suivant montre comment créer un SID en utilisant la fonction SecLookupWellKnownSid pour l’entité « système local » :
{
UCHAR sidBuffer[128];
PISID localSid = (PISID) sidBuffer;
SIZE_T sidSize;
status = SecLookupWellKnownSid(WinLocalSid,
&localSid,
sizeof(sidBuffer),
&sidSize);
if (!NT_SUCCESS(status)) {
//
// error handling
//
}
}
L’une ou l’autre de ces approches est valide, bien que le dernier code soit préféré. Ces exemples de code utilisent des tampons locaux pour stocker le SID. Ces tampons ne peuvent pas être utilisés en dehors du contexte d’appel actuel. Si le tampon SID devait être persistant, il faudrait allouer le tampon à partir de la mémoire de pool.