In molti sistema gli utenti ROOT e SuperUser dispongono di controllo completo del sistema. Subsystem for UNIX-based Applications (SUA) non riconosce l'utente ROOT. Quando è stato sviluppato lo standard POSIX (Portable Operating System Interface), il concetto di utente ROOT era considerato di interesse amministrativo. Invece di un utente ROOT, lo standard POSIX definisce i privilegi appropriati per alcune operazioni.

In questo argomento

setuid e setgid

I meccanismi setuid e setgid consentono a un programma, quando è in esecuzione, di adottare alcuni aspetti di un'entità di sicurezza diversa da quella dell'utente che esegue il programma. Consentono al programma di alternare tali aspetti tra quelli dell'utente che esegue il richiamo e quelli di un'altra entità di sicurezza.

I privilegi appropriati sono diversi. Mentre i meccanismi setuid e setgid consentono a un'applicazione di controllare la risposta alla domanda "Chi sei?", i privilegi appropriati rispondono alla domanda "Cosa puoi fare?".

Subsystem for UNIX-based Applications e identità

Negli ambienti UNIX tipici, esiste un unico utente a cui sono concessi tutti i privilegi. A tale utente, in genere denominato root, è associato uid == 0. In Subsystem for UNIX-based Applications tutti i privilegi supportati in un dato sistema vengono concessi agli utenti che fanno parte del gruppo Administrators o del gruppo Domain Administrators in tale sistema. Non è necessario effettuare l'accesso come amministratore. Tutti gli utenti che fanno parte del gruppo Administrators o Domain Administrators possiedono i privilegi root. Non tutti i privilegi definiti in POSIX o UNIX sono disponibili in SUA, ovvero esistono alcuni privilegi che non vengono concessi a qualsiasi utente.

I privilegi appropriati in genere sono necessari per una serie di azioni, quali l'accesso al file system, l'invio di segnali ad altri processi (controllo dei processi) o la modifica dell'ID utente (UID) o dell'identificatore di gruppo (GID) per un processo per modificare la capacità di tale processo di eseguire determinate azioni.

Secondo lo standard POSIX, un file è autorizzato a includere bit per impostare un UID (setuid) e un GID (setgid). Se vengono impostati uno o entrambi i bit su un file e un processo esegue tale file, il processo ottiene l'UID e/o il GID del file. Se utilizzato con attenzione, questo meccanismo consente a un utente privo di privilegi di eseguire programmi che vengono eseguiti con i privilegi più elevati del proprietario o del gruppo del file. Se utilizzato in modo non corretto, tuttavia, può introdurre problemi di sicurezza consentendo a utenti privi di privilegi di eseguire azioni che dovrebbero essere eseguite solo da un amministratore. È per questo che SUA non supporta questo meccanismo per impostazione predefinita. Se invece si tenta di eseguire un file con impostato il bit setuid o setgid, SUA non eseguirà il file e restituirà il codice di errore ENOSETUID.

Considerazioni sull'installazione per setuid in Subsystem for UNIX-based Applications

Se si fa affidamento su un'applicazione che richiede il comportamento POSIX standard, è possibile configurare SUA per l'esecuzione di file con il bit setuid o setgid impostato. Con questa configurazione, quando un processo esegue un file in cui è impostato il bit setuid o setgid, SUA costruisce token di sicurezza locali per il processo con i privilegi assegnati al proprietario o al gruppo del file. Dato che i token sono locali, non vengono riconosciuti da altri computer sulla rete. Di conseguenza, anche se il file appartiene a un membro del gruppo Domain Administrators, ad esempio, il processo non dispone di accesso trusted tramite rete Microsoft® Windows® ad altri computer nel dominio. I privilegi saranno invece validi solo sul computer in cui viene eseguito il processo.

Ad esempio, un processo esegue un file di programma con il proprio bit setuid impostato e di proprietà di un membro del gruppo Domain Administrators. Se tale programma tenta di modificare la password di un utente del dominio, tale tentativo avrà esito negativo perché i token di sicurezza del processo sono locali e non vengono riconosciuti dagli altri sistemi nel dominio. Se invece il programma tenta di cambiare la password di un utente locale, tale tentativo avrà esito positivo perché il proprietario del file fa parte del gruppo Domain Administrators, che in genere fa parte del gruppo Administrators del computer locale. Per informazioni sulla configurazione di SUA per l'esecuzione di file con il bit setuid o setgid impostato, vedere la Guida fornita con il pacchetto di download Utilities and Software Development Kit (SDK) for Subsystem for UNIX-based Applications.

Per le funzioni setuid(2), setgid(2) e chroot(2), un processo deve disporre dell'UID effettivo che a sua volta è mappato all'account di sistema, all'account Administrator per il dominio locale o all'account Administrator per il dominio dell'entità. L'account dell'amministratore locale può impostare l'UID o il GID solo su un altro ID nello stesso dominio.

Per chown(1), chmod(1) e chgrp(1), un account deve disporre dei privilegi Windows SE_BACKUP e SE_RESTORE per eseguire operazioni make sui file di proprietà di un altro utente o gruppo oppure per modificare le autorizzazioni per un file di proprietà di un altro utente. Queste autorizzazioni in genere sono associate agli account dei gruppi Administrators e Backup Operators.

Vedere anche