[PLUTO-help] Perche' il bit setuid e` pericoloso

[Gian Uberto Lauri]

Dato che in  questa mailing list si e` spiegato  come impostare il bit
setuid ad un file senza  peraltro spiegare perhce' questo non andrebbe
fatto, provo a mettere giu` un paio di righe.

0.02 EUR di teoria

Il bit  setuid e` uno dei bit  che codificano i permessi  dei file che
sono 12. I 9 bassi li conoscono credo tutti e sono quelli che regolano
i permessi di lettura, scrittura ed esecuzione. Rimangono i 3 bit alti

Set UID
Set GID
Sticky

Linux usa sticky solo per le directory (vedi man chown).

Gli altri due  indicano al sistema che l'esecuzione  del programma non
deve  avvenire  con  l'uid  dell'utente  collegato ma  con  l'uid  del
proprietario del file.

L'uid  e` l'identita`  utilizzata, per  il sistema  c'e`  anche quella
reale, per  cui un  programma e` comunque  in grado di  conoscere l'id
dell'utente che lo usa se serve).

Scopo  dell'ambaradan  ?  Ci  sono  risorse che  non  devono  rimanere
liberamente  accessibili ma  che  l'utente deve  poter utilizzare,  ad
esempio, con determinati programmi. X e` uno di questi.

"WOW, quindi se io metto  setuid un certo programma posso usarlo anche
da utente peone..."

##     	##   ######    ##
##	##   ######    ##
####    ## ##  	   ##  ##
####	## ##	   ##  ##
##  ## 	## ##	   ##  ##
##  ##	## ##	   ##  ##
##    #### ##	   ##
##    #### ##  	   ##
##     	##   ######    ##
##	##   ######    ##

Il bit setuid non va usato se non quando e` veramente l'unica risorsa,
sopratutto se l'utente proprietario del file e` root.

1) Certe operazioni  sono lasciate solo  a root perche'  sono critiche
   per il  sistema ed il loro  uso deve avvenire in  modo "protetto da
   abusi".  

   Se si mette  setuid root un file, questa  protezione salta. Cio` e`
   male (E. Spengler).

   Ci  sono  vari meccanismi  (sudo,  o  file  di configurazione  come
   shutdown.allow descritto  in man  shutdown) per delegare  ad alcuni
   utenti  certe  operazioni  senza  peraltro  permettere  a  loro  di
   diventare root a tutti gli effetti.

2) Mettere setuid root un file che generalmente non lo e` puo` aprire
   falle di sicurezza.

   Ad esempio, e` poco probabile che tale file sia stato sottoposto ad
   auditing per l'uso di  tecniche di programmazione poco sicure (i.e.
   buffer  overflow).  C'e` gia`  abbastanza  da  tenere d'occhio  per
   quello che "istituzionalmente" gira con l'uid 0:0.

   Il programma potrebbe avere una shell escape: "Mi metto setuid less
   cosi` non ho  problemi di permessi. Ho tutti i  servizi di rete che
   girano come nobody, anche se  li sfondano...". Peccato che la prima
   cosa che si fa quando si  sfonda una macchina con utente diverso da
   root la  prima cosa  che si va  a vedere  sono i file  setuid root:
   "WOW", esclama l'intruso, "less  setuid!", fa less /etc/motd, preme
   !, scrive sh, preme return ed ha una shell di root.

   Non  parliamo  del  fatto che  se  un  utente  riesce ad  avere  la
   scrivibilita` di  un file  setuid allora ha  la porta  aperta verso
   l'account 0:0:

	     copia il file incriminato, tanto per avere un backup
	     e cancellare le prove.

	     cat /bin/sh > file_incriminato

	     esegue file incriminato

	     cat copia_backup > file_incriminato #via le prove

   Sembra  uno  scenario  stupido  ma  e`  gia`  successo  perche'  il
   sistemista era troppo facilone.

Oh, se fate questa prova sotto Linux:

    fate uno shell script che contenga il solo comando id

    diventate root e fate chmod 4755 file_di_prova

    tornate utenti

    richiamate il file

vi ritornera` i vostri dati di utente normale e non quelli di root.

Il perche' e`  banale. Chi ha scritto la bash sa  che gli shell script
setuid root sono estremamente pericolosi, e quindi per default bash va
a vedere chi siete veramente e ripristina la vostra identita`.

E' anche vero che puo` essere _realmente_ necessario avere uno shell
script setuid.

bash vi  chiede di "esserne consci"  e richiede il  parametro -p sulla
command line, parametro che sta a dire "sono perfettamente conscio che
potrebbe essere una cazzata, ma hai l'ordine di eseguirlo setuid".

Si puo`  fare, ma  e` meglio  non farlo. Si  puo` percuotere  i propri
geniali con un martellone, ma e` meglio non farlo.


	      E`   M E G L I O   N O N   F A R L O ! ! !
	      E`   M E G L I O   N O N   F A R L O ! ! !
	      E`   M E G L I O   N O N   F A R L O ! ! !
	      E`   M E G L I O   N O N   F A R L O ! ! !
	      E`   M E G L I O   N O N   F A R L O ! ! !
	      E`   M E G L I O   N O N   F A R L O ! ! !
	      E`   M E G L I O   N O N   F A R L O ! ! !


/*
 * Nota decisamente polemicosa :)
 *
 * Questo e`  IMNSHO il  modo corretto di  parlare di cose  potenti ma
 * pericolose agli utenti non preparati.
 *
 * E forse ci sono ancora dei buchi di sicurezza in quello che ho detto.
 */

/*
 * Nota storica:
 *
 * Come ho gia` detto, ho gia` visto gente che si supponeva essere "un
 * professionista" agire in maniera facilona. Il problema e` che gli
 * altri utenti meno esperti, pur non essendo degli scemi, si fidavano
 * del suo operato e bene o male imparavano da lui. Ci sono voluti 6
 * anni per sentirne uno dire "ma sai che pensavo che quelle cose di
 * sicurezza fossero solo paranoie"...
 */

-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico, fancazzista 
\/                  e coltivatore diretto di software