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.
