Newsgroup: it.comp.sicurezza.unix
Titolo: set-uid

Vorrei sepere le vostre opinioni, possibilmente anche quella di MdI
su di un pezzo che si trova nella documentazione di Postfix.
"No Postfix program is set-uid. Introducing the concept was the biggest
 mistake made in UNIX history. Set-uid (and its weaker cousin, set-gid)
 causes more trouble than it is worth. Each time a new feature is added
 to the UNIX system, set-uid causes a security problem: shared
 libraries, the /proc file system, multi-language support, to mention
 just a few examples. Set-uid makes it impossible to introduce some of
 the features that make UNIX successors such as plan9 so attractive,
 for example, per-process file system name spaces."
E` realistico pensare che un giorno Linux possa abbracciare le
caratteristiche di plan9?
Le capability applicate ai processi potrebbero essere una soluzione
alternativa migliore al set-uid?
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(address rot13 encoded)

alternativa migliore al set-uid?
Certo. 
http://www.linux.it/~md/software/ssd.tgz
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *
      | (Ri)scoprire fidonet: 
http://bbs.mi.linux.it

 (address rot13 encoded)
IMHO questa opinione e' una stupidaggine di dimensioni
stratosferiche. Il problema vero non e' il flag suid, bensi' i
buffer overflow ... A tutt'oggi nessuno ha trovato una soluzione,
tranne quella di sforzarsi di scrivere programmi corretti.
 
-- 
Francesco P. Lovergine  f.lovergine AT 
iesi.ba.cnr.it

Certo. 
http://www.linux.it/~md/software/ssd.tgz
Attualmente qual'e` lo stato della compatibilita` POSIX ?
Le utilities setfcap, setpcap e getfcap ci sono?


tranne quella di sforzarsi di scrivere programmi corretti.
Veramente la soluzione che fu proposta qualche tempo fa su linux-kernel
era di rendere lo stack non eseguibile. Tuttavia poi non se ne fece
niente per vari motivi. E` piu` una questione filosofica che tecnica.


Le utilities setfcap, setpcap e getfcap ci sono?
Si.


niente per vari motivi. E` piu` una questione filosofica che tecnica.
No, e` una questione tecnica. Lo stack non eseguibile impedisce solo gli
attacchi piu` banali e ha vari svantaggi.



questo è un dubbio che mi perseguita da diverso tempo,
perche è possibile piazzare codice eseguibile nello stack?
costa così tanto marcare le paggine dello stack come non eseguibili?
che problemi può causare questa modifica?
bye

perche č possibile piazzare codice eseguibile nello stack?
Mi pare che Linux 2.2 faccia una cosa del genere nell'ambito della
gestione dei segnali.

Si chiamano "trampolines" e vengono usati per fare modifiche del codice
al volo. 
Ciao
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"


codice automodificante?
sui libri di sistemi operativi c'è scritto
che fu abbolito negli anni 60 perchè era difficile
da debugare e causava più problemi di quanti ne risolveva.
come mai?
bye

 di scrivere programmi corretti.
A me pareva di avere visto qualche tempo fa su packetstorm un compilatore
o una patch per gcc che (a quanto era scritto) avrebbe dovuto eliminare il
problema dei buffer overflow a scapito di un maggior overhead del sistema.
E' possibile come cosa? come poteva funzionare? allocando dinamicamente
le variabili? Se funzionasse non lo si potrebbe utilizzare in alcuni casi?
(almeno i piu' pericolosi, set-uid ecc...)
byez.
keii.

]

come mai?
Esiste anche oggi ma nelle CPU moderne non e` coveniente.


(almeno i piu' pericolosi, set-uid ecc...)
forse ti riferisci a stack guard,
è una patch per il gcc,
che inserisce nei binari generati dei controlli sullo stack
per evitare i problemi derivanti da buffer overflow.