OpenBSD e sicurezza
Alberto Rubinelli
Sto configurando un firewall con OpenBSD. Mi confermate che ho scelto il
prodotto migliore ?
Si, lo so che la sicurezza dipende sempre da come un amministratore e'
capace di configurarla, ma a parita' di amministratore, dovrebbe essere il
prodotto piu' sicuro, o sbaglio ?
Ciao.Alberto.
Marco d'Itri
>Si, lo so che la sicurezza dipende sempre da come un amministratore e'
>capace di configurarla, ma a parita' di amministratore, dovrebbe essere il
>prodotto piu' sicuro, o sbaglio ?
E` un po' come dire che la panda e` piu` affidabile della mercedes
perche` ha meno accessori.
--
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
Cthulhu
>>capace di configurarla, ma a parita' di amministratore, dovrebbe essere il
>>prodotto piu' sicuro, o sbaglio ?
> E` un po' come dire che la panda e` piu` affidabile della mercedes
> perche` ha meno accessori.
Non e' invece come dire che una FIAT Campagnola e' piu' resistente ed
affidabile di una Mercedes, se devi andare in giro per campi incolti?
analogalmente,
Cthulhu
--
Ph'nglui mglw'nafh Cthulhu http://www.rlyeh.it wgah'nagl fhtgan!
<cthulhu at flashnet dot it>
Fabio Pagnottella
> perche` ha meno accessori.
linux.
OpenBSD e' il sistema + sicuro in assoluto. come strumento di firewalling
ha un interfaccia come ipfiltrer che ipchains non lo vede nemmeno di quanto
gli sta' sopra, uno stack tcp/ip SERIO, un fracco di features che linux si
sogna e ora come ora possono essere usate con iproute2 e una buona lettura
della man page.
come firewall e' il meglio in assoluto, se non vuoi appoggiarti a prodotti
commerciali come un Chekpoint FW-1 o un Cisco PIX.
e' evidente che se devi configurarlo adeguatamente dovrai sudare un po' +
che con una debian, ma ne vale la pena.
per quanto riguarda il paragone e' proprio fuori luogo.
Marco d'Itri
>Non e' invece come dire che una FIAT Campagnola e' piu' resistente ed
>affidabile di una Mercedes, se devi andare in giro per campi incolti?
Il paragone non e` pertinente, linux configurato in modo sicuro IMO e`
sicuro tanto quanto OpenBSD.
Re Marco (Laza)(togli i +)
wrote:
>>Non e' invece come dire che una FIAT Campagnola e' piu' resistente ed
>>affidabile di una Mercedes, se devi andare in giro per campi incolti?
>Il paragone non e` pertinente, linux configurato in modo sicuro IMO e`
>sicuro tanto quanto OpenBSD.
e' piu' o meno sicuro ?
Ovvio che poi io posso benissimo fare un auditing intensivo su di una
linux, ma se qualcuno l'ha gia' fatto e' meglio.
Inoltre da una macchina unix io di certo non ho bisogno ne del
plug&play ne della configurazione bellina in grafica.. :-)
Bye Marco
--
Re Marco(Laza) (CBR 900 & Clito 16 Vulve) laza@world+online.it
Official Sughero Of Spidi Fan Club
Very Bastard Inside Racing Team
------------------------------------------------------------
Ti do' un consiglio: mai sputare in un tornado!
------------------------------------------------------------
Simone Piccardi
>
> OpenBSD e' il sistema + sicuro in assoluto. come strumento di firewalling
> ha un interfaccia come ipfiltrer che ipchains non lo vede nemmeno di quanto
> gli sta' sopra, uno stack tcp/ip SERIO, un fracco di features che linux si
stack TCP di linux?
> della man page.
>
> come firewall e' il meglio in assoluto, se non vuoi appoggiarti a prodotti
> commerciali come un Chekpoint FW-1 o un Cisco PIX.
>
piacerebbe capirle queste superiorita'.
Ciao
--
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"
Maurizio Cimaschi
> Non e' invece come dire che una FIAT Campagnola e' piu' resistente ed
> affidabile di una Mercedes, se devi andare in giro per campi incolti?
Mai visto una Mercedes Serie G ????
Maurizio Cimaschi
> OpenBSD e' il sistema + sicuro in assoluto. come strumento di firewalling
> ha un interfaccia come ipfiltrer che ipchains non lo vede nemmeno di quanto
> gli sta' sopra, uno stack tcp/ip SERIO, un fracco di features che linux si
> della man page.
Hai dato un' occhiata al "Linux Advanced Route HOWTO" oppure al progetto
GNU/Zebra ??????
> e' evidente che se devi configurarlo adeguatamente dovrai sudare un po' +
> che con una debian, ma ne vale la pena.
Quindi OpenBSD e' meglio perche' non e' stato fatto un lavoro accurato
da chi lo ha sviluppato ?????
Cthulhu
> Il paragone non e` pertinente, linux configurato in modo sicuro IMO e`
> sicuro tanto quanto OpenBSD.
IMO Linux configurato in modo sicuro e' un Linux privato della
stragrande maggioranza di accessori e suppellettili, quindi e' il tuo
paragone tra panda e mercedes a non essere pertinente. :)
limatamente,
Cthulhu
> Mai visto una Mercedes Serie G ????
Azz, sono le camionette in dotazione ai Carabinieri?
Effettivamente, non me ne ricordavo, ma non credo che siano a livello
di comfort di una CLK. :)
suppostamente,
Cthulhu
> Quindi OpenBSD e' meglio perche' non e' stato fatto un lavoro accurato
> da chi lo ha sviluppato ?????
No, anzi, se proprio devo dire quella che e' la mia impressione a
pelle, non dimostrata da fatti ne tantomento teorie e completamente
personale, OpenBSD da un immagine migliore perche' coordinato da un
gruppo determinato di persone a loro volta coordinate tra loro.
Linux, al contrario, spesso genera l'impressione di uno sfuggente
essere multi cellulare dove pero' ogni cellula procede nell'evoluzione
in modo anarchico. Un patchwork pulsante, in continuo cambiamento, che
riesci a far funzionare se riesci ad entrare in sintonia con le
innumerevoli menti facenti parte dell'entropia vivente.
A quel punto, indubbiamente, funziona bene. :)
Mi sa che a me lo smog di Roma me fa 'no strano effetto.
alteratamente,
Marco d'Itri
>>Il paragone non e` pertinente, linux configurato in modo sicuro IMO e`
>>sicuro tanto quanto OpenBSD.
>Il problema e' sempre il solito. Come esce dal distributore/produttore
>e' piu' o meno sicuro ?
Dipende dal distributore. Un sistema debian e` molto sicuro gia` di
default.
Altri, molto meno.
>Inoltre da una macchina unix io di certo non ho bisogno ne del
>plug&play ne della configurazione bellina in grafica.. :-)
No, pero` a me fa piacere non dovere compilare su ogni macchina trenta o
quaranta programmi che uso e che OpenBSD non ha per scelta progettuale.
Marco d'Itri
>e' evidente che se devi configurarlo adeguatamente dovrai sudare un po' +
>che con una debian, ma ne vale la pena.
No, e` evidente che se devi *usarlo* dovrai perdere un mucchio di tempo
a compilare tutto il software che non viene fornito di serie per dare
l'illusione della sicurezza.
Fabio Pagnottella
> Quindi OpenBSD e' meglio perche' non e' stato fatto un lavoro accurato
> da chi lo ha sviluppato ?????
ai limiti della perfezione. certo, anche debian ha in suo periodo di freeze
dove vengono testati i pacchetti che verranno inseriti nella prossima
versione, ma OpenBSD come primo scopo ha l'auditing e la verifica del
codice, la sicurezza e la flessibilita' delle applicazioni di rete.
alla fine questa mail e' nata quando e' stato chiesto se OpenBSD andasse
bene come firewall, la risposta e', da parte mia: SI, senza ombra di dubbio.
Fabio Pagnottella
> Premesso che io non conosco OpenBDS, mi spieghi cosa ha di poco serio lo
> stack TCP di linux?
fa' venivan trovati bachi a basso livello di rete che causavano il crash
completo della macchina ? i kernel dal 2.2.0 al 2.2.12 non erano proprio il
massimo della sicurezza... chi ti dice che siano davvero finiti ? che ti
dice che con l'uscita del 2.4 tutti questi problemi saranno risolti ? di bug
simili in OpenBSD (non dico che non ce ne siano mai stati) ma non ne ho mai
visto uno.
> Quali sarebbero? queste cose in piu'
mah, iproute2 implementa un bel po' di cose, l'ho letto di sfuggita e quello
che mi ha colpito e' proprio che moltissimo software di linux non sfruttano
tutte le features implementate negli ultimi kernel... iproute2 lo fa', da
solo sostituisce ifconfig+route+netstat, ha una sintatti complessa e non mi
sono ancora messo bene a veder la sue reali potenzilita', un occhiata al
README e dimmi che ne pensi.
> > come firewall e' il meglio in assoluto, se non vuoi appoggiarti a
prodotti
> > commerciali come un Chekpoint FW-1 o un Cisco PIX.
> In che termini scusa, l'affermazione e' un po' generico/dogmatica, mi
> piacerebbe capirle queste superiorita'.
la superiorita' di ipfilter sopra ipchains e' scontata, e si qui non ci sono
dubbi.
la validita'di questi prodotti commerciali e' che non ti appoggi ad un
prodotto freeware ma a un prodotto commerciale, potendo godere di supporto
tecnico e non perdendo performarce in senso tecnico.
ciao :)
Fabio Pagnottella
> No, e` evidente che se devi *usarlo* dovrai perdere un mucchio di tempo
> a compilare tutto il software che non viene fornito di serie per dare
> l'illusione della sicurezza.
make
make install.
questa lunga operazione che occupa un sacco di tempo la devi fare al massimo
10 volte, il fatto e' che un OpenBSD usato come firewall non deve essere
*usato*, non penso che su un sistema simile metterai su gestori di mailing
list MTA e simili, metti il firewall e basta, al massimo, OpenSSH per
l'amministrazione da remoto.
(e non OpenSSH perche' e' stato sviluppato dall'open team, ma perche' e'
nettamente piu' sicuro di ssh1 e ssh2, senza contare la fluidita' della
trasmissione dovuta ad una migliore implementazione del protocollo).
se mi vuoi dire che la compilazione del kernel e' + lunga... ti do' ragione.
ma ripeto che ne vale la pena.
ciao ciao
Marco d'Itri
>> No, e` evidente che se devi *usarlo* dovrai perdere un mucchio di tempo
>> a compilare tutto il software che non viene fornito di serie per dare
>> l'illusione della sicurezza.
>cd /usr/src/ports
>make
>make install.
Non scherzare. I port non sono nemmeno paragonabili ai pacchetti debian.
Quel che e` peggio e` che gli upgrade sono un macello, mentre con debian
sono quasi completamente automatici ed indolore.
Cthulhu
> No, e` evidente che se devi *usarlo* dovrai perdere un mucchio di tempo
> a compilare tutto il software che non viene fornito di serie per dare
> l'illusione della sicurezza.
D'altra parte, usando software gia' compilato, chi ti assicura che con
quella particolare versione di libc e con le particolari
ottimizzazioni usate in congiunzione col processore che usi, non
escano fuori problemi?
verificatamente,
Cthulhu
> Il fatto che sia usato da decine di migliaia di altre persone?
Questo lo dicono pure i sostenitori di NT. ;)
> Il fatto che se ci fossero davvero problemi posso scaricare i sorgenti,
> ricompilare il pacchetto ed ottenere pacchetti .deb installabili con un
> solo comando?
Perche' aspettare che saltino fuori?
Preferisco prendere direttamente il sorgente... se poi con i pacchetti
debian con un solo comando riesci a compilarli ed installari, meglio
ancora.
Con il rischio che l'installazione sia stata 'personalizzata', pero'.
paranoicamente,
Alberto Rubinelli
> ha un interfaccia come ipfiltrer che ipchains non lo vede nemmeno di
quanto
> gli sta' sopra, uno stack tcp/ip SERIO, un fracco di features che linux si
> sogna e ora come ora possono essere usate con iproute2 e una buona lettura
> della man page.
Accidenti, non pensavo di avere scatenato un thread :) E' c'e' pure il mio
amico cthulhu :))
Comunque sono contento che qualcuno apprezzi OpenBSD, quando lavoro su di
lui, ho una sensazione di controllo completo della macchina, cosa che gia'
la Debian, che forse e' la migliore delle distribuzioni linux, non mi da.
Ciao.Alberto.
Cthulhu
> lui, ho una sensazione di controllo completo della macchina, cosa che gia'
> la Debian, che forse e' la migliore delle distribuzioni linux, non mi da.
Ah, ma allora vuoi far arrabbiare VERAMENTE MdI? :)
provocatamente,
Simone Piccardi
OpenBSD quali sono le differenze (con un minimo di contenuto tecnico, le
affermazioni che e' meglio mi paiono poco motivate) che lo rendono tanto
superiore.
Lungi da me ogni scopo polemico, ma siccome non lo conosco vorrei avere
qualche informazione in piu' (la sensazione di controllo completo
francamente non mi pare un dettaglio tecnicamente rilevante).
Lorenzo Allegrucci
>A costo di sembrare monotono vorrei ri-chiedere a voi estimatori di
>OpenBSD quali sono le differenze (con un minimo di contenuto tecnico, le
>affermazioni che e' meglio mi paiono poco motivate) che lo rendono tanto
>superiore.
>Lungi da me ogni scopo polemico, ma siccome non lo conosco vorrei avere
>qualche informazione in piu' (la sensazione di controllo completo
>francamente non mi pare un dettaglio tecnicamente rilevante).
Ti parlo da Linuxaro :-)
Non so darti una panoramica completa di un confronto a livello di
sicurezza tra Linux e OpenBSD, pero` uno degli aspetti dove attualmente
OpenBSD e` superiore (non lo sara` per molto :-) e` il sistema di
hashing delle password. Certo non riguarda il kernel ma fa pur sempre
parte del sistema operativo.
Dove Linux usa il DES o l'MD5 per implementare crypt(), OpenBSD usa
Blowfish per implementare l'omologa, bcrypt().
Blowfish e` un algoritmo di crittazione relativamente giovane ma
(si dice) molto robusto e versatile.
E` stato anche candidato all'AES, "Advanced Encription Standard",
un concorso indetto dal NIST per eleggere il nuovo algoritmo di
crittazione standard dopo il pensionamento del DES.
Ora non mi ricordo se e` ancora presente o no...
In ogni caso, la sua superiorita` rispetto al DES e` che oltre ad
essere intrinsecamente piu` sicuro e` la possibilita` di modificare
i parametri dell'algoritmo. In particolare e` possible variare la
complessita` del key-scheduling e quindi la velocita` dell'algoritmo
in modo da rendere un eventuale dictionary attack impraticabile.
Per darti un'idea basti pensare che una ventina di anni fa un VAX
riusciva a fare 3/4 crypt() al secondo e che bcrypt() rende un
Alpha non proprio come il vecchio VAX ma lo tortura parecchio!
In breve, e` molto piu` facile attaccare password crittate con
DES e MD5 piuttosto che con Blowfish.
Ovviamente questo e` lo scenario peggiore visto che /etc/shadow
e` stato violato e quindi il sistema e` gia` compromesso.
In questo senso OpenBSD offre una garanzia in piu` rendendo la
vita molto piu` difficile al cracker che ha rubato gli hash.
Inoltre sul fronte reti OpenBSD supporta IPsec.
Questo e` un breve riassunto, tutti i dettagli li trovi facilmente
su www.openbsd.org.
Ultima nota, c'e` un progetto interessante che si chiama Trusted BSD
www.trustedbsd.org. Consiste in una serie di patches che quando
saranno completate aspireranno a rendere FreeBSD un sistema sicuro
di classe B1, quindi ACL, Mandatory Access Control, auditing ecc.
Insomma, attualmente vedo i *BSD e Linux press'appoco allo stesso
livello tranne OpenBSD che e` un piccolo gradino piu` su per certi
aspetti. In futuro potremo vedere un BSD certificato B1 ma anche sul
fronte Linux si sta lavorando visto che SGI ha in progetto di portare
Linux allo stesso livello di sicurezza e ha gia` rilasciato del codice.
http://oss.sgi.com/projects/ob1
--
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(address rot13 encoded)
Marco d'Itri
>Dove Linux usa il DES o l'MD5 per implementare crypt(), OpenBSD usa
>Blowfish per implementare l'omologa, bcrypt().
E chissenefrega?
Voglio dire, crypt basata su MD5 non e` certo insicura, neppure
vagamente, ne` ci sono motivi per immaginare che lo sara` nel prossimo
futuro.
Seguono cose vere, ma assolutamente irrilevanti.
>Inoltre sul fronte reti OpenBSD supporta IPsec.
Anche linux..
>Ultima nota, c'e` un progetto interessante che si chiama Trusted BSD
>www.trustedbsd.org. Consiste in una serie di patches che quando
Ci sono almeno un paio di progetti simili per linux. L'utilita` nel real
world non e` molto chiara.
Lorenzo Allegrucci
>yra...@gvfpnyvarg.vg wrote:
>
>>Dove Linux usa il DES o l'MD5 per implementare crypt(), OpenBSD usa
>>Blowfish per implementare l'omologa, bcrypt().
>E chissenefrega?
>Voglio dire, crypt basata su MD5 non e` certo insicura, neppure
>vagamente, ne` ci sono motivi per immaginare che lo sara` nel prossimo
>futuro.
Non ho detto che MD5 non e` sicuro ma che se devi fare un dictionary
attack usando crypt() o bcrypt() lo fai molto piu` agevolmente con
crypt(), almeno cosi` mi e` sembrato leggendo il documento.
Potrei anche sbagliarmi, in caso correggimi.
MD5 e` strasicuro nel senso che non e` praticamente invertibile ma
bcrypt() e` stata progettata per avere dei requisiti parametrizzabili
che crypt() semplicemente non ha, tutto qui.
Quando /etc/shadow e` violato ormai il sistema e` cosi` compromesso che
questa sicurezza teorica in piu` che si avrebbe con bcrypt() e` di poco
conto e dal mio punto di vista la considero di secondaria importanza.
Non ho certo dato a OpenBSD lo scettro della sicurezza assoluta!
Marco, se sepevo che ti avrebbe cosi` irritato sarei stato zitto :-)
>Seguono cose vere, ma assolutamente irrilevanti.
>
>>Inoltre sul fronte reti OpenBSD supporta IPsec.
>Anche linux..
Bene.
>>Ultima nota, c'e` un progetto interessante che si chiama Trusted BSD
>>www.trustedbsd.org. Consiste in una serie di patches che quando
>Ci sono almeno un paio di progetti simili per linux.
Infatti uno l'ho citato, poi so che esiste una patch a parte per
supportare il MAC, c'e` anche un progetto in corso per l'auditing
completo dei sorgenti di Linux. I fan di OpenBSD vanno fieri del
fatto che i loro sorgenti sono stati completamente visionati,
almeno cosi` dicono, puntando l'indice sul "disordine" di Linux.
Anche su questo fronte credo che Linux possa riempire questa lacuna
nel volgere di pochi anni, sempre se la si rintenga davvero una lacuna.
>L'utilita` nel real world non e` molto chiara.
E` vero ma se si stanno muovendo anche sul quel fronte vuol dire che
qualche utilita` ce l'avra`, credo. Non cadiamo nella tentazione di
ritenere una cosa poco utile solo perche` Linux non la possiede, ora.
Io del resto non e` che possa giudicare molto visto non ho la tua
esperienza mi fai da punto di riferimento, pero` mi piacerebbe vedere
un atteggiamento piu` aperto.
Adoro Linux per la sua velocita` di evoluzione, per il fatto che tutti
i giorni ci lavorano decine di magliaia di sviluppatori (solo al kernel)
e basta leggere la mia signature per accorgersi dell'importanza di cio`.
Considero questo una qualita` *vincente* rispetto al codice "statico" dei
*BSD dove lo sviluppo e` piu` basato su un modello a Cattedrale per
dirla alla Eric Raymond.
Spero di aver riparato questo piccolo incidente diplomatico :-)
Marco d'Itri
>Non ho detto che MD5 non e` sicuro ma che se devi fare un dictionary
>attack usando crypt() o bcrypt() lo fai molto piu` agevolmente con
>crypt(), almeno cosi` mi e` sembrato leggendo il documento.
Sostengo che MD5 sia sufficientemente lento per rendere un attacco a
dizionario non praticabile. A questo punto e` inutile rallentare
ulteriormente crypt. Se/quando in futuro sara` necessario, c'e` sempre
tempo a installare una nuova libcrypt.
>MD5 e` strasicuro nel senso che non e` praticamente invertibile ma
>bcrypt() e` stata progettata per avere dei requisiti parametrizzabili
>che crypt() semplicemente non ha, tutto qui.
Piu` che altro perche` non servono. E perche` decidere la forza delle
password e` una decisione del sistemista, e quindi il codice di un
programma non e` il posto appropriato dove farlo. Con le distribuzioni
linux moderne basta modificare /etc/pam.d/login.
>Marco, se sepevo che ti avrebbe cosi` irritato sarei stato zitto :-)
Mi irrito quando la gente scrive per sentito dire.
>completo dei sorgenti di Linux. I fan di OpenBSD vanno fieri del
>fatto che i loro sorgenti sono stati completamente visionati,
Grazie tante, hanno ridotto all'osso il sistema operativo! C'e` cosi`
poco che fare un auditing "completo" e` un compito relativamente veloce.
>E` vero ma se si stanno muovendo anche sul quel fronte vuol dire che
>qualche utilita` ce l'avra`, credo. Non cadiamo nella tentazione di
Spiegamela, io sono sempre qui.
Lorenzo Allegrucci
>yra...@gvfpnyvarg.vg wrote:
>
>>Non ho detto che MD5 non e` sicuro ma che se devi fare un dictionary
>>attack usando crypt() o bcrypt() lo fai molto piu` agevolmente con
>>crypt(), almeno cosi` mi e` sembrato leggendo il documento.
>Sostengo che MD5 sia sufficientemente lento per rendere un attacco a
>dizionario non praticabile. A questo punto e` inutile rallentare
>ulteriormente crypt. Se/quando in futuro sara` necessario, c'e` sempre
>tempo a installare una nuova libcrypt.
Si vede che non si fidano :-)
>>MD5 e` strasicuro nel senso che non e` praticamente invertibile ma
>>bcrypt() e` stata progettata per avere dei requisiti parametrizzabili
>>che crypt() semplicemente non ha, tutto qui.
>Piu` che altro perche` non servono. E perche` decidere la forza delle
>password e` una decisione del sistemista, e quindi il codice di un
>programma non e` il posto appropriato dove farlo. Con le distribuzioni
>linux moderne basta modificare /etc/pam.d/login.
Ok.
>>completo dei sorgenti di Linux. I fan di OpenBSD vanno fieri del
>>fatto che i loro sorgenti sono stati completamente visionati,
>Grazie tante, hanno ridotto all'osso il sistema operativo! C'e` cosi`
>poco che fare un auditing "completo" e` un compito relativamente veloce.
Sono d'accordo.
>>E` vero ma se si stanno muovendo anche sul quel fronte vuol dire che
>>qualche utilita` ce l'avra`, credo. Non cadiamo nella tentazione di
>Spiegamela, io sono sempre qui.
Per esempio il mandatory access control e` indispensabile per
coprire certe falle della protezione offerta dalle sole ACL.
Questo e` tratto da "A GUIDE TO UNDERSTANDING DISCRENTIONARY ACCESS CONTROL"
del NATIONAL COMPUTER SECURITY CENTER
http://www.radium.ncsc.mil/
So gia` che conosci il problema e non ami la roba militare (anch'io :-)
ma lo riporto per completezza.
6.2 AN EXAMPLE OF A TROJAN HORSE
Consider a system where an access control list mechanism (as described
in Section 7.3) is used to implement discretionary access control.
There are two users on this particular system: an honest user, DOE;
and a dishonest user, DRAKE. DOE has a data file which contains highly
sensitive data; this file is known as DOESFILE. He has diligently set
the ACL to allow only himself to read the file. No other users are
authorized to access the file. DOE is confident that no one but
himself will be able to access his data file.
DRAKE is determined to gain access to DOESFILE. He has legitimate
access to the system which allows him to implement a useful utility
program. In this utility DRAKE embeds a covert function to read
DOESFILE and copy the contents into a file in DRAKE's address space
called DRAKESFILE. DRAKESFILE has an ACL associated with it that
allows processes executing on DOE's behalf to write to it, while
allowing DRAKE's processes to read it.
DRAKE induces DOE to execute his utility program by telling him how
useful and efficient it is. DRAKE is careful not to tell DOE about the
covert function (Trojan horse) that is resident in the utility
program. DOE executes the corrupted program and it appears to perform
perfectly. However, while it is operating on DOE's behalf, it assumes
his identity and thus his access rights to DOESFILE. At this time it
copies the contents of DOESFILE to DRAKESFILE. This copying takes
place completely within the constraints of the DAC mechanism, and DOE
is unaware of what is happening.
This example should make clear the danger of Trojan horse attacks and
the inadequacy of most DAC mechanisms to protect against such attacks.
It should be noted that an elaborate DAC mechanism may provide
illusory security to users who are unaware of its vulnerability to
Trojan horse attacks.
...
A reference monitor which implements a mandatory security policy which
includes the *-property would provide robust protection against Trojan
horse attacks. The mandatory access control implementation would
prevent the Trojan horse from disclosing the information to a user who
is not permitted access to the information under the mandatory access
rules. Assume the same scenario as was described previously with the
following changes. The computer system now implements a mandatory
security policy with two hierarchical sensitivity levels. For the sake
of simplicity, the levels are called sensitive and non-sensitive. DOE
operates at the sensitive level, and DOESFILE is sensitive. DRAKE is
not authorized to access sensitive data, so he operates at the
non-sensitive level. DRAKE is only allowed to read non-sensitive
files, so DRAKESFILE is non-sensitive. As before, DRAKE's Trojan horse
program is executed by DOE. The program takes on the sensitivity level
and the identity of DOE. Within the constraints of the mandatory and
the discretionary security policies, the program reads DOESFILE.
However, when the Trojan horse tries to write the sensitive data to
DRAKESFILE, the reference monitor disallows the operation. Since the
Trojan horse is now executing at the sensitive level, the program
cannot be allowed to write to a non-sensitive file. That would be a
violation of the *-property [1].
This example should show the reader that discretionary access control
is only effective to restrict the `honest'' user in browsing through
other users' files and preventing accidental disclosure or destruction
of information. The malicious user who is determined to gain
unauthorized access to data on the computer system must be restricted
by other means, such as mandatory access controls.
Qui *c'e`* un problema.
Il software autenticato certe volte non basta, per esempio il caso
di un programma che gira con privilegi root che potrebbe andare in
core dump a causa di un bug interno di qualsiasi natura e il core
dump potrebbe contenere informazione sensibile.
In passato ci sono stati diversi buffer overflow del server X11 che
permettevano di leggere /etc/shadow, con il MAC questo non potrebbe
mai accadere. Software autenticato non implica software corretto
purtroppo e in questo caso qualunque cosa che giri con alti privilegi
e` relativamente pericolosa. Cosa ne pensi?
Ti prego non massacrarmi, voglio solo imparare :-)
Cthulhu
> Lungi da me ogni scopo polemico, ma siccome non lo conosco vorrei avere
> qualche informazione in piu' (la sensazione di controllo completo
L'unico vero modo per scegliere e' provarli entrambi, e lasciare che
sia uno di loro a scegliere te. :)
consigliamente,
Marco d'Itri
>>>E` vero ma se si stanno muovendo anche sul quel fronte vuol dire che
>>>qualche utilita` ce l'avra`, credo. Non cadiamo nella tentazione di
>>Spiegamela, io sono sempre qui.
>Per esempio il mandatory access control e` indispensabile per
>coprire certe falle della protezione offerta dalle sole ACL.
Eh? Ma ti rendi conto di cosa c'e` scritto nel testo che hai riportato?
E` piu` che ovvio che un utente attento alla sicurezza deve eseguire
solo programmi installati da lui o dall'amministratore! Non serve mica
il DoD per spiegare che fare diversamente e` pericoloso...
Il passo successivo e` domandarsi: e` piu` economico implementare tutta
questa roba oppure comprare due macchine separate da qualche centimetro
di vera Aria(tm)?
E comunque, questo e` un problema di sistemi multiutente, e nessuno si
sogna di proporre OpenBSD se non per server.
>Il software autenticato certe volte non basta, per esempio il caso
>di un programma che gira con privilegi root che potrebbe andare in
>core dump a causa di un bug interno di qualsiasi natura e il core
>dump potrebbe contenere informazione sensibile.
I programmi suid non generano core file. E qualunque programma scriva un
core file non lo crea world readable.
>In passato ci sono stati diversi buffer overflow del server X11 che
>permettevano di leggere /etc/shadow, con il MAC questo non potrebbe
>mai accadere. Software autenticato non implica software corretto
Se /etc/shadow avesse un livello di sicurezza superiore a quello
dell'utente allora l'utente non potrebbe accedervi...
Questo problema lo si risolve compartimentalizzando i privilegi, per
esempio assegnando all'X server solo la possibilita` di accedere alla
scheda grafica senza dargli UID=0 e tutto cio` che vi e` associato.
>purtroppo e in questo caso qualunque cosa che giri con alti privilegi
>e` relativamente pericolosa. Cosa ne pensi?
Che le cose piu` semplici spesso sono le piu` sicure.
Lorenzo Allegrucci
>yra...@gvfpnyvarg.vg wrote:
>
>>>>E` vero ma se si stanno muovendo anche sul quel fronte vuol dire che
>>>>qualche utilita` ce l'avra`, credo. Non cadiamo nella tentazione di
>>>Spiegamela, io sono sempre qui.
>>Per esempio il mandatory access control e` indispensabile per
>>coprire certe falle della protezione offerta dalle sole ACL.
>E` piu` che ovvio che un utente attento alla sicurezza deve eseguire
>solo programmi installati da lui o dall'amministratore! Non serve mica
>il DoD per spiegare che fare diversamente e` pericoloso...
Certo che e` ovvio, ma Il MAC ti consente una migliore condivisione
delle risorse in tutta sicurezza.
>Il passo successivo e` domandarsi: e` piu` economico implementare tutta
>questa roba oppure comprare due macchine separate da qualche centimetro
>di vera Aria(tm)?
Pero` se diamo ad ogni utente una macchina dopo e` difficile condividere
le risorse.
>E comunque, questo e` un problema di sistemi multiutente, e nessuno si
>sogna di proporre OpenBSD se non per server.
E` pur vero che se un giorno Linux vorra` essere una valido sistema
multiutente dovra` scontrarsi con questi problemi.
>>Il software autenticato certe volte non basta, per esempio il caso
>>di un programma che gira con privilegi root che potrebbe andare in
>>core dump a causa di un bug interno di qualsiasi natura e il core
>>dump potrebbe contenere informazione sensibile.
>I programmi suid non generano core file. E qualunque programma scriva un
>core file non lo crea world readable.
Ho imparato qualcosa.
>>In passato ci sono stati diversi buffer overflow del server X11 che
>>permettevano di leggere /etc/shadow, con il MAC questo non potrebbe
>>mai accadere. Software autenticato non implica software corretto
>Se /etc/shadow avesse un livello di sicurezza superiore a quello
>dell'utente allora l'utente non potrebbe accedervi...
Ho scelto un esempio infelice.
Quello che volevo sottolineare e` la proprieta` del MAC di consentire
l'accesso in scrittura da parte di un soggetto ad un file solo se
il soggetto e` gerarchicamente superiore al file. In questo modo
non puo` esserci fuga accidentale di informazioni sensibili dal
soggetto con alti privilegi.
Il mio esempio era infelice perche` la storiella di DOE e DRAKE si
adatta solo in un rapporto utente/utente invece che root/utente.
Dato che il core file non e` leggibile al mondo esterno il mio
esempio non funziona, anche se dovevo immaginarlo...
Cio` nonostante in sistemi adibiti alla multiutenza la protezione
offerta dal MAC e` molto utile.
>Questo problema lo si risolve compartimentalizzando i privilegi, per
>esempio assegnando all'X server solo la possibilita` di accedere alla
>scheda grafica senza dargli UID=0 e tutto cio` che vi e` associato.
Come fa?
Nella realta` e` cosi`?
>>purtroppo e in questo caso qualunque cosa che giri con alti privilegi
>>e` relativamente pericolosa. Cosa ne pensi?
>Che le cose piu` semplici spesso sono le piu` sicure.
Sono d'accordo a meta`.
Le cose semplici mi piacciono molto, perche` solo facili da gestire
e si fanno meno errori. Tuttavia in certi casi la flessibilita` e`
piu` importante.
Le ACL sono piu` complicate da gestire ma permettono un controllo
degli accessi piu` preciso e quindi piu` sicuro.
E` possibile escludere l'accesso al solo utente "cattivo" di un gruppo.
Non fare caso all'esempio stupido, e` solo per esprimere il concetto.
Con il mandatory access control e` la stessa cosa, si infittiscono
le maglie della sicurezza aumentando la quantita` e la qualita` dei
controlli.
D'altra parte sono d'accordo con te che aumentando la complessita`
l'essere umano tende a sbagliare, e se lo fa root mette cerca di
districarsi tra permission bits, ACL e MAC i risultati possono
essere disastrosi.
Lorenzo Allegrucci
>Ho scelto un esempio infelice.
>Quello che volevo sottolineare e` la proprieta` del MAC di consentire
>l'accesso in scrittura da parte di un soggetto ad un file solo se
>il soggetto e` gerarchicamente superiore al file. In questo modo
inferiore
Marco d'Itri
>Certo che e` ovvio, ma Il MAC ti consente una migliore condivisione
>delle risorse in tutta sicurezza.
E ne vale la pena?
>>Il passo successivo e` domandarsi: e` piu` economico implementare tutta
>>questa roba oppure comprare due macchine separate da qualche centimetro
>>di vera Aria(tm)?
>Pero` se diamo ad ogni utente una macchina dopo e` difficile condividere
>le risorse.
Hanno inventato apposta le reti...
>>E comunque, questo e` un problema di sistemi multiutente, e nessuno si
>>sogna di proporre OpenBSD se non per server.
>E` pur vero che se un giorno Linux vorra` essere una valido sistema
>multiutente dovra` scontrarsi con questi problemi.
No, perche` ormai l'hardware e` abbastanza economico da rendere questi
problemi risolvibili piu` semplicemente separando fisicamente i servizi.
>>Questo problema lo si risolve compartimentalizzando i privilegi, per
>>esempio assegnando all'X server solo la possibilita` di accedere alla
>>scheda grafica senza dargli UID=0 e tutto cio` che vi e` associato.
>Come fa?
Con le capabilities.
>Nella realta` e` cosi`?
Lo sara` tra qualche mese, il codice nel kernel c'e` gia` tutto.
TNT
>
> yra...@gvfpnyvarg.vg wrote:
>
> >completo dei sorgenti di Linux. I fan di OpenBSD vanno fieri del
> >fatto che i loro sorgenti sono stati completamente visionati,
> Grazie tante, hanno ridotto all'osso il sistema operativo! C'e` cosi`
> poco che fare un auditing "completo" e` un compito relativamente veloce.
Mah. Veramente in fatto di crittografia integrata,
ad esempio, Linux č ridotto molto pių "all'osso"
di quanto non lo sia OpenBSD.
TNT
>
> ge...@beer.com wrote:
>
> >e' evidente che se devi configurarlo adeguatamente dovrai sudare un po' +
> >che con una debian, ma ne vale la pena.
> a compilare tutto il software che non viene fornito di serie per dare
> l'illusione della sicurezza.
E quale sarebbe questa montagna di software che uno
deve prendersi la briga di compilare per poterlo
usare? Io lo uso e c'ho aggiunto ben poco, e di
certo nessun programma che dà particolari problemi
di sicurezza.
TNT
>
> Simone Piccardi <