Fedora 15 usa ancora i bit suid?

Correggi, vedi questa funzione pubblicata da Dan Walsh, il manutentore di SELinux per Fedora / Redhat.

Riepilogo: Fedora 15 non verrà distribuita con i binari con il flag setuid impostato su di essi, preferendo invece impostare le funzionalità necessarie a questi binari tramite POSIX Filesystem Capabilities. setuid etc può ancora essere impostato su binari. Tutto ciò che deve assolutamente avere setuid può ancora averlo. Al momento non posso confermare (il mio rawhide è morto) cosa succede con sudo / su - è possibile per un'applicazione per utilizzare le funzionalità per arrivare a root tramite CAP_SETUID ma non so se useranno questa tecnica o semplicemente avranno +s set.

"suid bit = bug di progettazione sicurezza?". Bene, immagino sia una questione di opinione; fondamentalmente si tratta di dare a un programma che un utente con privilegi bassi usa l'abilitity per eseguire, temporaneamente, un'operazione privilegiata. Sfortunatamente, qualsiasi vulnerabilità in quel programma potrebbe permetterti di sfruttarla per ottenere privilegi più elevati, ad esempio l'accesso root. Tecnicamente, non è un bug o una minaccia alla sicurezza; il software con bug sfruttabili è il problema. Ma scrivere software privo di bug è molto più difficile di quanto sembri.

Per quanto riguarda le funzionalità del file system posix, ecco una FAQ . Citando le parti pertinenti:

Then there is something quite different called "POSIX capabilities" which is what Linux uses. These capabilities are a partitioning of the all powerful root privilege into a set of distinct privileges (but look at securelevel emulation to find out that this isn't necessary the whole truth). Users familiar with VMS or "Trusted" versions of other UNIX variants will know this under the name "privileges". The name "capabilities" comes from the now defunct POSIX draft 1003.1e which used this name.

E

When a process tries to do a privileged operation, the operating system will check the appropriate bit in the effective set of the process (instead of checking whether the effective uid of the process is 0 as is normally done). For example, when a process tries to set the clock, the Linux kernel will check that the process has the CAP_SYS_TIME bit (which is currently bit 25) set in its effective set.

E

6) How can I use capabilities to make sure Mr. Evil Luser (eluser) can't exploit my "suid" programs?

This is the general outline of how this works given filesystem capability support exists. First, you have a PAM module that sets the inheritable capabilities of the login-shell of eluser. Then for all "suid" programs on the system, you decide what capabilities they need and set the allowed set of the executable to that set of capabilities. The capability rules

new permitted = forced | (allowed & inheritable)

means that you should be careful about setting forced capabilities on executables. In a few cases, this can be useful though. For example the login program needs to set the inheritable set of the new user and therefore needs an almost full permitted set. So if you want eluser to be able to run login and log in as a different user, you will have to set some forced bits on that executable.

In altre parole, hai un effetto di partizionamento per i privilegi di root, quindi un binario setuid ha meno possibilità di essere sfruttato per l'escalation dei privilegi. Questa è una buona notizia, specialmente quando gli utenti di Fedora disattivano SELinux.

Tuttavia, in un sistema SELinux, i bit setuid / setguid sono in gran parte ridondanti, poiché selinux applicherà il criterio indipendentemente dalle autorizzazioni unix (capacità o altro). Citerò un commento nel sorgente del kernel per questo:

* Since setuid only affects the current process, and since the SELinux
* controls are not based on the Linux identity attributes, SELinuxdoes not
* need to control this operation.  However, SELinux does control the use of
* the CAP_SETUID and CAP_SETGID capabilities using the capable hook.

In breve, non è necessario che SELinux abbia una politica scritta in modo appropriato per controllare / limitare il comportamento influenzato dalle funzionalità, ma viene utilizzato.

Lo riformulerò per chiarezza. In un sistema con una politica SELinux correttamente scritta, limitare l'impostazione delle capacità è un non-problema poiché SELinux bloccherà l'attività concessa dalla funzionalità se non è consentita anche nella politica. Questo vale anche per i bit setuid / gid - potresti essere eseguito come un altro utente, ma la politica dovrebbe comunque impedire al programma di fare qualcosa al di fuori del contesto definito.

Un esempio di utenti potrebbe essere in grado di apprezzare / ricostruire meglio; prendi una scatola fedora e scrivi uno script di caricamento di file di base che mette i dati in /var/www/html/uploads . Dando un'occhiata a quella cartella puoi eseguire:

$ ls -alZ
drwxrwxrwx. root   root   system_u:object_r:httpd_sys_content_t:s0 uploads

Suppongo che tu abbia eseguito chmod 777 su detta cartella. Quindi ora prova il tuo caricamento tramite Apache. Dovresti vedere un messaggio AVC; se stai eseguendo la GUI lo troverai tramite setroubleshoot. Fondamentalmente, finché non imposti il contesto di quella cartella su httpd_sys_rw_content_t SELinux negherà l'accesso di scrittura di httpd , indipendentemente dal permissiosn di unix.

Vuoi una demo interattiva? Accedi alla macchina di questo tizio come utente root.

Tuttavia, esiste anche un concetto di accodamento delle autorizzazioni. Vedi questo (in particolare:

Add secondary calls in selinux/hooks.c to task_setioprio and task_setscheduler so that selinux and capabilities with file cap support can be stacked).

Queste funzionalità discusse sono implementate nel codice sorgente sopra citato. In altre parole, impostando tale directory su chmod 755 avendo ancora httpd_sys_rw_content_t come il contesto negherà ancora la scrittura. Questo perché le autorizzazioni di livello base di unix sono state prima negate e quindi il controllo del contesto di SELinux non è mai necessario.