Sì sollevò il problema riguardante il rischio, legato alla sicurezza di sistema, comportato dalla mancata protezione del file HOSTS.
Infatti, i malware, oggi giorno (in particolar modo i worms), vanno ad iniettare, all'interno di quel file, un fotìo di dati, al fine di reindirizzare gli hostnames web, legati alle società di security più conosciute, al localhost, in modo da complessificare le operazioni di pulizia, da parte degli utenti poco esperti.
Sebbene vi siano dei programmi anti-spyware, che assicurino, all'utente, l'impossibilità di modificare tale file, in realtà, tale protezione è completamente inutile. Sotto le belle e grosse parole, non viene nient'altro che impostato l'attributo di sola lettura, al file. Il malware nota tale impostazione, la rimuove e tutto è come prima.
Tutto questo, in Windows XP.
Su ReactOS, però, è bene, in via generale, escogitare un metodo, onde evitare che questo genere di problemi, possano trovar campo fertile per manifestarsi.
File HOSTS, file DB della Rubrica di Sistema, file DB degli AV ecc.., sono tutti a rischio.
La mia idea, a questo punto, tende a ricalcare una già presente: "L'utente SYSTEM". L'utente System, in soldoni, è il sistema. Ogni cartella è dotata di questo utente. Ove non c'è, il sistema non può entrare.
Qualcuno, a sto punto, potrà dire "E quindi?". Bene, perchè non creare un utente, modulare, anche per i programmi?
Quest'ultimo dichiara i privilegi d'azione permessi ad un gruppo di uno o più programmi, oppure tutti.
Per default, il sistema, alla creazione di una cartella, dovrebbe assegnarci l'utente "SYSTEM" e l'utente "PROGRAMS". In PROGRAMS, son presenti tutti i programmi di sistema, registrati durante l'installazione (per quelli Portable, invece, occorrerà escogitare un metodo, o aggiungere le entry manualmente, magari creando una form per facilitare l'operazione).
In questo modo, se si leva quell'utente o si modificano alcuni parametri, gli altri programmi dovranno, nell'esecuzione, adeguarsi di conseguenza.
Inoltre, nell'area di gestione dei criteri, si può pensare nell'introdurre (tra Computers, Utenti e Gruppi) anche programmi e gruppi di programmi.
In questo modo, sarebbe possibile creare un criterio di gruppo, assegnando, a dei particolari programmi, dei privilegi d'azione.
In questo modo, ad esempio, s'installa l'anti-virus. Quest'ultimo crea un criterio per gli eseguibili dell'AV, in modo che solo questi possano agire nelle cartelle ove son presenti le informazioni sensibili del programma (come, ad esempio, i database). Durante l'update, l'eseguibile relativo può accedervi. Tutto il resto no. In questo modo, non solo si evita che l'utente vada, magari, per sbaglio, a cancellare dei files, per errore, rendendo l'AV malfunzionante, ma si evita che, qualche attaccante, possa sfruttare l'utente compromesso, per disattivare i sistemi di sicurezza.
Allo stesso modo, si può applicare tale logica per il file HOSTS o per i DB della rubrica di sistema.
Solo il software di gestione del file HOSTS, può accedere alla cartella (o al file) ove sono contenuti i dati. In questo modo, il malware, non può causare danno (sempre se non eseguito da administrator) e il sistema non è castrato in modo assoluto, isolando solo le aree sensibili.
Allo stesso modo, i mass-mailer non possono più controllare i DB, durante la fase di harvesting degli indirizzi.
Hardening dei Privilegi di Sistema & Sicurezza
Moderators: gabrielilardi, forart, Davy Bartoloni
Altre implementazioni utili, per la sicurezza, sarebbero:
- Possibilità di proteggere l'accesso ad una cartella, o l'esecuzione di un file, con password. Anche se il computer viene utilizzato con un utente non privilegiato, assegnare dei diversi criteri di accesso, alle cartelle, per proteggere i dati, spesso, è un lavoro lungo e inutile. Se ad esempio, uso un account, ove ci son dei privilegi d'azione maggiori, di quello usato normalmente e, quel giorno, viene un mio amico, vorrei poter evitare che questo scorrazzi nel mio sistema, accedendo a dati privati. E' una soluzione maggiormente più semplice che non star là a creare un nuovo utente, regolargli tutti gli accessi (e non è cosa facile) ecc....
Uno ci piazza la password e amen.
- Possibilità di nascondere le cartelle, per il motivo spiegato appena adesso. Occhio non vede, cuore non duole, LoHacker non fà lo scemo nel sistema. Magari, il tutto, può essere gestito, da pannello di controllo, ov'è possibile decidere se nascondere, porre la password o entrambi le cose, anche, magari, bloccando/sbloccando i dati temporaneamente o modificando la disposizione di apertura/chiusura, in modo permanente, all'avvio successivo.
- Possibilità di proteggere l'accesso ad una cartella, o l'esecuzione di un file, con password. Anche se il computer viene utilizzato con un utente non privilegiato, assegnare dei diversi criteri di accesso, alle cartelle, per proteggere i dati, spesso, è un lavoro lungo e inutile. Se ad esempio, uso un account, ove ci son dei privilegi d'azione maggiori, di quello usato normalmente e, quel giorno, viene un mio amico, vorrei poter evitare che questo scorrazzi nel mio sistema, accedendo a dati privati. E' una soluzione maggiormente più semplice che non star là a creare un nuovo utente, regolargli tutti gli accessi (e non è cosa facile) ecc....
Uno ci piazza la password e amen.
- Possibilità di nascondere le cartelle, per il motivo spiegato appena adesso. Occhio non vede, cuore non duole, LoHacker non fà lo scemo nel sistema. Magari, il tutto, può essere gestito, da pannello di controllo, ov'è possibile decidere se nascondere, porre la password o entrambi le cose, anche, magari, bloccando/sbloccando i dati temporaneamente o modificando la disposizione di apertura/chiusura, in modo permanente, all'avvio successivo.
Re: Hardening dei Privilegi di Sistema & Sicurezza
Windows NT ha sempre avuto una gestione utenti completa. Il problema e che nessuno la usa, perche gli utenti creati dalla istallazione di Windows hanno sempre i diritti d'amministratore (quindi tutti). Questi problemi di file HOSTS manipolati sarebbero tutti risolti se tutti farebbero uso della gestione utenti.
Comunque, una gestione utenti richiede un file system più avanzato di FAT32. Per questo, MS ha introdotto NTFS (New technology file system). Al momento non esiste un driver NTFS funzionante aparte quello di MS, che ovviamente non possiamo integrare in ReactOS. E per quello che stanno lavorando per fare funzionare i driver per ext2 (anche ext2 e capace di salvare i diritti dei file e dei utenti)
Comunque, una gestione utenti richiede un file system più avanzato di FAT32. Per questo, MS ha introdotto NTFS (New technology file system). Al momento non esiste un driver NTFS funzionante aparte quello di MS, che ovviamente non possiamo integrare in ReactOS. E per quello che stanno lavorando per fare funzionare i driver per ext2 (anche ext2 e capace di salvare i diritti dei file e dei utenti)
Il ROS dovrà, cmq, avere, per forza di cose, un account administrator, pertanto, l'utenza non farà altro che usare quello.
Coloro, invece, che non avranno sufficienti competenze per farlo, rimarranno su XP.
Ho provato a chiedere in giro, su Azzurra, cosa ne pensavano e questo è emerso.
Ecco perchè, in parte, mi sto tanto animando per proporre idee alternative.
Coloro, invece, che non avranno sufficienti competenze per farlo, rimarranno su XP.
Ho provato a chiedere in giro, su Azzurra, cosa ne pensavano e questo è emerso.
Ecco perchè, in parte, mi sto tanto animando per proporre idee alternative.
Basta disattivarlo e usare runas. Sotto Ubuntu Linux funziona perfettamente cosi. Anche in Windows Vista gli utenti creati dallo setup saranno utenti normali (senza i diritti d'amministratore), funzionera anche con ReactOS.PUOjACKz wrote:Il ROS dovrà, cmq, avere, per forza di cose, un account administrator, pertanto, l'utenza non farà altro che usare quello.
AFAIK lo supporto ext2 e quasi comleto e arriverá con ReactOS 0.3.0PUOjACKz wrote:Riguardo l'Ext2, IMHO, l'idea è buona. Su linux, il suo funzionamento, è egregio. Spero venga introdotto anche su ROS.
Lo spero, in quanto, se si costringe un utente nel shiftare, per troppe cose, all'utente Administrator, quest'ultimo, s'adagerà ad usarlo sempre.Basta disattivarlo e usare runas. Sotto Ubuntu Linux funziona perfettamente cosi. Anche in Windows Vista gli utenti creati dallo setup saranno utenti normali (senza i diritti d'amministratore), funzionera anche con ReactOS.
AFAIK lo supporto ext2 e quasi comleto e arriverá con ReactOS 0.3.0[/quote]PUOjACKz wrote:Riguardo l'Ext2, IMHO, l'idea è buona. Su linux, il suo funzionamento, è egregio. Spero venga introdotto anche su ROS.
Sì, inoltre, ho sentito alcune news, riguardanti i brevetti e il FAT. Meglio cambiare.
Questo aspetto, IMHO, può essere implementato, nell'OS, via Snap-In della Management Console, senza riempire il pannello di controllo di 100000 icone, con funzioni divise tra loro.- Possibilità di proteggere l'accesso ad una cartella, o l'esecuzione di un file, con password. Anche se il computer viene utilizzato con un utente non privilegiato, assegnare dei diversi criteri di accesso, alle cartelle, per proteggere i dati, spesso, è un lavoro lungo e inutile. Se ad esempio, uso un account, ove ci son dei privilegi d'azione maggiori, di quello usato normalmente e, quel giorno, viene un mio amico, vorrei poter evitare che questo scorrazzi nel mio sistema, accedendo a dati privati. E' una soluzione maggiormente più semplice che non star là a creare un nuovo utente, regolargli tutti gli accessi (e non è cosa facile) ecc....
Uno ci piazza la password e amen.
- Possibilità di nascondere le cartelle, per il motivo spiegato appena adesso. Occhio non vede, cuore non duole, LoHacker non fà lo scemo nel sistema. Magari, il tutto, può essere gestito, da pannello di controllo, ov'è possibile decidere se nascondere, porre la password o entrambi le cose, anche, magari, bloccando/sbloccando i dati temporaneamente o modificando la disposizione di apertura/chiusura, in modo permanente, all'avvio successivo.
Personalmente, la configurazione degli utenti, in XP può avvenire in 2 modi: Via pannello di controllo, tramite il tool apposito, il quale, ahimè è molto colorato, ma totalmente scarso delle funzionalità di base per configurare adeguatamente un utente; via Management Console, ma, in quel caso, occorre che l'utente vada ad acquisire informazioni sufficienti per configurare i parametri presenti nello Snap-In apposito, fattore, spesso, non possibile a tutti.Windows NT ha sempre avuto una gestione utenti completa. Il problema e che nessuno la usa, perche gli utenti creati dalla istallazione di Windows hanno sempre i diritti d'amministratore (quindi tutti).
Intercorre una certa differenza tra l'usare un Wizard e configurarsi tutto in via manuale. Ok che il Wizard-Mode è un scemenza per Utonti, ma nell'altro modo, devi avere conoscenze, riguardo il funzionamento del sistema, non indifferenti.
Non lo metto in dubbio, ma un hardening dei privilegi, con l'inserimento di un fake group, può agevolare, in certi casi, la configurazione nel sistema, più che di una smanettata nello Snap-In apposito degli utenti, il quale, sembra per ora, disegnato solo per l'approccio con SysAdmins e altra gente competente.Questi problemi di file HOSTS manipolati sarebbero tutti risolti se tutti farebbero uso della gestione utenti.
E', in fase di elaborazione, anche un ipotetica Ext3?Comunque, una gestione utenti richiede un file system più avanzato di FAT32. Per questo, MS ha introdotto NTFS (New technology file system). Al momento non esiste un driver NTFS funzionante aparte quello di MS, che ovviamente non possiamo integrare in ReactOS. E per quello che stanno lavorando per fare funzionare i driver per ext2 (anche ext2 e capace di salvare i diritti dei file e dei utenti)
Who is online
Users browsing this forum: DotBot [Crawler] and 6 guests