Discussioni su eventuali implementazioni e migliorie nell'OS

Moderators: forart, Davy Bartoloni, gabrielilardi

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Per lo switch, legato all'autoaccensione del behavior blocker (il quale, presumo, sarà un servizio di sistema), è buona cosa far interagire le opzioni dell'area del pannello, con l'ipotetica area Servizi del Management Console di ReactOS (come Windows). In particolare, è bene porre degli elementi per l'accensione manuale, lo spegnimento manuale e la disposizione se avviare tale servizio, durante il LogOn.
Ah, è bene tener in considerazione una cosa: Tale funzione NON deve poter essere killata, nè, in caso di crash, rimanere spenta, se nel pannello, sia manualmente, che automaticamente, risulta avviata.
Tale fattore, in quanto, se il processo và a farsi benedire, dopo un crash, un qualsiasi malware può generare un attacco DoS apposito, al fine di spegnere il Behavior Blocker.

Es.

1) Il programma maligno, viene avviato dall'utente
2) Il programma maligno causa un iniezione di codice anomalo, che conduce, il sistema, nel crashare alcuni moduli
3) Il Behavior Blocker rimane spento (mentre il malware è acceso)
4) Il Malware fà bisboccia nel sistema e la sicurezza è andata a quel paese (senza affrancatura, nè biglietto di viaggio)

Opzioni

Personalmente, ha poco senso slegare queste 3 opzioni:

Code: Select all

* identificare l'accensione dei programmi
* identificare la sostituzione dei programmi
* identificare quando i programmi tentano di avviare altri programmi
Sono la base del Behavior Blocker. Se si disattiva anche una sola di queste 3, è abbastanza inutile tener acceso il resto.

Code: Select all

* informare dello stato di un programma (se scandito dagli engine eucaristici, oppure no)
Questo, in riferimento ad un discorso futuro, può essere disattivato, come opzione dell'utility, in quanto, sarebbe, alla fin fine, una semplice segnalazione, all'utente, per scopo informativo. Certo ha la sua gravità, ma questa è circoscritta solo in particolari ambiti.

Code: Select all

* presentare una descrizione generica riguardo il rischio possibile, a seconda del tipo di programma attivo
Questa parte, non dev'essere collegata ad alcun switch. E' bene che l'utente si legga, OGNI VOLTA, cosa significhi attivare un programma, in modo che, magari, gli entri in testa di non fare sciocchezze. Come si diceva una volta? Repetita Juvant?

Frasi, ipotetiche, che possono essere inserite, come descrizione, in caso di Popup possono essere:

Per l'avvio di un programma:

Code: Select all

[b]Avvio di un File Eseguibile[/b]

E' stato avviato il programma: $NomeProgrammaDaEseguire

E' consigliato permetterne l'esecuzione, solo se tale sollecitazione è volontaria e consapevole. In caso contrario, si consiglia di vietare tale comportamento, onde evitare l'avvio di operazioni che potrebbero causare effetti indesiderati (a volte anche gravi).
Per la sostituzione di un applicazione:

Code: Select all

[b]Sostituzione di un File Eseguibile[/b]

E' stato identificato un tentativo di sostituzione del programma: $NomeProgrammaSostituito

E' consigliato permette la sostituzione, solo se l'operazione è stata compiuta volontariamente e consapevolmente. In caso contrario, si consiglia di vietare tale attività, onde evitare la possibile sostituzione del file, con una versione contenente codice malfunzionante o pericoloso.
Per l'avvio di un applicazione, richiamata da un'altra applicazione:

Code: Select all

[b]Esecuzione Nidificata[/b]

Il programma: $NomeProgrammaRichiamante
Ha tentato di eseguire il programma: $NomeProgrammaRichiamato

E' consigliato permetterne l'esecuzione, solo se tale sollecitazione è volontaria e consapevole. In caso contrario, si consiglia di vietare tale comportamento, onde evitare l'avvio di operazioni che potrebbero causare effetti indesiderati (a volte anche gravi). 
Per la ricezione di un tentativo di autoaccensione, tramite la configurazione dell'utilità di pianificazione di sistema:

Code: Select all

[b]Tentativo d'Interazione con l'Utilità di Pianificazione[/b]

Il File Eseguibile: $NomeFile
Ha tentato di apportare delle modifiche all'utilità di pianificazione di sistema: $Aggiunta/$Modifica/$Cancellazione 

$InformazioneCoinvolta

E' consigliato permettere tale operazione, solo se il file è sicuro. In caso contrario, si consiglia di vietare la configurazione di tale impostazione, onde evitare l'esecuzione di programmi che potrebbero ridurre la sicurezza o la stabilità di sistema, ed, in certi casi, anche comportando una perdita di dati. Inoltre, altri applicativi leciti, potrebbero non funzionare più in modo corretto.
Per la ricezione di un tentativo di autoaccensione, tramite l'inserimento di collegamenti nelle cartelle di auto-esecuzione di sistema:

Code: Select all

[b]Tentativo d'Interazione con l'Utilità di Esecuzione Automatica[/b]

Il programma: $NomeProgrammaRichiamante
Ha tentato di apportare delle modifiche all'utilità di esecuzione automatica: $Aggiunta/$Modifica/$Cancellazione 

$InformazioneCoinvolta

E' consigliato permetterne l'esecuzione, solo se tale sollecitazione è volontaria e consapevole. In caso contrario, si consiglia di vietare tale comportamento, onde evitare l'avvio di operazioni che potrebbero causare effetti indesiderati (a volte anche gravi).  Inoltre, altri applicativi leciti, potrebbero non funzionare più in modo corretto. 
Ovviamente, eventuali informazioni sui possibili rischi, è bene fornirli, premendo un pulsante di Help (diversificando di caso in caso), magari, cercando di non spaventare l'utente, in quanto, se effettivamente, il programma è maligno, è bene, in quei casi, mantenere la calma (fattore impossibile, se si viene bombardati da messaggi intimidatori e pieni di paroloni catastrofici e apocalitici, come su Windows).

Nel corpo del popup, bene in vista, inserire un pulsante decisionale per permettere tale esecuzione, un altro per vietarla, un checkbox per rendere permanente tale decisione, un altro se si vuole loggare tale attività in un file, ed un altro ancora se si vuole essere avvisati di tale esecuzione.

Inoltre, un buon consiglio è quello d'introdurre un eventuale switch per visualizzare eventuali informazioni aggiuntive specifiche ed esaustive (da includere in caso di logging), tra cui (alla rinfusa):

Code: Select all

Path Eseguibile Avviato: $Drive\$Path\$EseguibileConNomeEdEstensione
Path Eseguibile Sostituito: $Drive\$Path\$EseguibileConNomeEdEstensione
Path Eseguibile Richiamante: $Drive\$Path\$EseguibileConNomeEdEstensione
Path Eseguibile Richiamato: $Drive\$Path\$EseguibileConNomeEdEstensione
Path File Sospettato: $Drive\$Path\$FileConNomeEdEstensione (usato per le attività d'interazione sospetta)
Descrizione: $DescrizioneDell'Eseguibile
Versione Del File: $Versione ($BuildEdAltreInfo)
Esecuzione Nidificata Richiesta: $DataEOraDelRichiamo
File Richiamante Creato: $DataEOraDiCreazione
File Richiamante Modificato: $DataEOraDiModifica
Ultimo Accesso al File Richiamante: $DataEOraUltimoAccesso 
File Richiamato Creato: $DataEOraDiCreazione
File Richiamato Modificato: $DataEOraDiModifica
Ultimo Accesso al File Richiamato: $DataEOraUltimoAccesso 
File Controllato Dall'AntiVirus/Engine Euristico di Sistema: $Sì/$No ($SoloDall'EngineEuristico/$SoloDall'AntiVirus/$DaEntrambi)
Ultimo Controllo del File: $DataEOraUltimoControllo
File Considerato Sicuro: $Sì/$No ($SoloDall'EngineEuristico/$SoloDall'AntiVirus/$DaEntrambi)
N.B: I valori $Valore, li ho messi, all'incirca, per spiegare cosa c'andrebbe messo.

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Nel pannello di gestione delle opzioni del Behavior Blocker, direi, inoltre, di aggiungere delle voci per diversificare il comportamento automatico dell'utilità, al manifestarsi di certe operazioni.

Per l'Accensione dei programmi:

- Avviare l'applicazione, senza richiedere l'intervento dell'utente
- Controllare la presenza dell'applicazione, nelle regole. Se questa è negata, non avviare nulla, altrimenti, eseguire l'applicazione senza richiedere l'interazione dell'utente
- Controllare la presenza dell'applicazione, nelle regole. Se questa è permessa, avviare il programma, altrimenti, bloccare l'applicazione senza richiedere l'interazione dell'utente
- Controllare la presenza dell'applicazione, nelle regole. Se non è presente, richiedere l'intervento decisionale dell'utente
- Bloccare l'applicazione, senza richiedere l'intervento dell'utente

Come Switch specifici:

- Avviare l'applicazione solo se è stata controllata da almeno uno dei due dispositivi di sicurezza (o Engine Euristico o Antivirus) ed è considerata sicura
- Avviare l'applicazione solo se è stata controllata da tutti e due i dispositivi di sicurezza (Engine Euristico e Antivirus) ed è considerata sicura
- Avviare l'applicazione anche se non è stata sottoposta al controllo di almeno uno dei due dispositivi di sicurezza
- Avviare l'applicazione anche se non è considerata sicura

E' bene, inserire una breve descrizione ed un pulsante di Help, per l'utente, in modo da poter conoscere, con esattezza cosa comportano le seguenti funzioni, i pro e i contro.

Per il Monitoraggio & L'avviso

- Aggiornare il file log, con l'esecuzione del programma (da consigliare solo per certi programmi sospetti)
- Avvertire, l'utente, dell'avvenuta esecuzione del programma (da consigliare solo per certi programmi sospetti)

Allo stesso modo, deve funzionare l'opzione di gestione della Sostituzione delle applicazioni, così come quella dell'Esecuzione Nidificata.

Per i programmi che tentano di interagire con le utilità di pianificazione e auto-esecuzione, occorre aggiungere, inoltre, altre opzioni (oltre alle precedenti), da qualche parte, nella configurazione dei programmi, oppure, in quella generica:

- Permettere la modifica arbitraria delle entry presenti
- Permettere solo l'aggiunta (per quei programmi che necessitano di essere eseguiti periodicamente, ma che non devono combinare casino nella lista, mettendo le mani dove non devono)
- Permettere solo la modifica delle proprie entry (per quei programmi che permettono, all'utente, l'impostazione di eventuali attività pianificate o auto-esecuzioni, dalla loro interfaccia GUI, configurando, per loro, i parametri appropriati nell'utilità)
- Permettere la modifica di tutte le entry presenti (per quei programmi di gestione dell'utilità di pianificazione, con, ad esempio, un interfaccia più semplice)
- Permettere solo la cancellazione della propria entry (per quei programmi che rimuovono le loro entry, durante la disinstallazione)
- Permettere la cancellazione di tutte le entry (per quei programmi, di sicurezza, che monitorano l'eventuale presenza di entry legate a malware conosciuti)

Ovviamente, per la questione relativa all'ipotetico SandBox, che avrà anche funzioni di salvaguardia del sistema, per l'esecuzione di programmi poco sicuri, occorrerà sostenere un discorso apparte, più specifico.
Inoltre, è buona cosa includere la presenza attiva del Behavior Blocker, come configurazione di sicurezza nei profili degli utenti, in modo che, ad esempio, un utente possa decidere se accenderlo, oppure no. Altrimenti, l'admin può decidere se forzare l'attivazione, al LogOn, di tale tool, impedendo, all'utente, di spegnerlo ecc.

Sergio Neddi
Posts: 6
Joined: Mon Jan 30, 2006 1:21 am

Post by Sergio Neddi »

Non entro in merito alle questioni sulla sicurezza in quanto non ci capisco molto e non riesco a seguirvi.
Pensavo ad un'altra cosa, riguardo alle migliorie effettuabili.
Una sarebbe la possibilità di supportare partizioni differenti dalle Fat32.
Se vogliamo usare il sistema come server ok per la sicurezza, ma poi lo facciamo girare su partizioni FAT?
So che una partizione NTFS è un casino da gestire perché volutamente incasinata da MS ed inoltre non documentata, ma perché non partizioni ext2, ext3, reiserfs, insomma, roba di provenienza Linux, sicuramente ben documentata?
Sospetto che ci sia una difficoltà, e cioè che, come NTFS è pensata per Windows, così le altre sono pensate per Linux e più difficilmente adattabili, anche per la gestione dei diritti, ecc... non so di preciso, ma immagino che mettere Windows su ext3 sia come giocare fuori casa, alla fine si prendono più gol.
Ma sarebbe interessante.
Altra considerazione: Windows ha il kernel fuso con l'interfaccia grafica, non separato come Linux.
In particolare explorer fa sia da barra delle applicazioni che da browser per le risorse, per cui, se si inchioda qualcosa s'inchioda tutto e non ri riesce più a controllare niente.
Ad esempio se io faccio start -> esegui e poi \\pippo, se esiste in rete un PC di nome pippo mi verrà aperta una finestra che mostra le condivisioni del PC. E fin qui va bene.
Mettiamo caso che \\pippo non esista... tutto si blocca, non si riesce più ad operare con la barra finché non c'è il timeout ed appare la finestra che ci informa che pippo non è stato trovato.
Non è che funzionerebbe meglio separare la barra di explorer dal resto? E magari darle una priorità di esecuzione leggermente superiore in modo da poterne sempre mantenere il controllo?
Ho fatto qualche esperimento sul mio Windows XP.
Ho preso come esempio un malfunzionamento che avevo (poi risolto) e cioè che spesso, aprendo cartelle con molti file di grossa dimensione, mi si inchiodava la baracca (esplora risorse e la barra) per circa un minuto per poi riprendere come se nulla fosse.
Cos'ho provato a fare?
Ho duplicato explorer.exe con nome explorer2.exe ed ho creato dei collegamenti che mi consentano di lanciare quest'ultimo per navigare nelle cartelle, inoltre nelle opzioni cartella ho impostato "esegui le finestre delle cartelle in un processo separato", altrimenti il sistema userebbe sempre l'unico processo explorer per tutto.
Poi, visto che XP esegue la barra con priorità normale e le finestre di explorer a priorità alta, ho fatto in modo (creato un processo che lavora in background) che le finestre vengano portate alla priorità normale, mentre la barra a priorità più elevata.
Poi ho provato a vedere come si comporta on il mio malfunzionamento, e...
...quando avveniva il blocco...
potevo mantenere il controllo della barra applicazioni, inoltre, se volevo, potevo chiudere la finestra bloccata senza avere casini (prima, se riuscivo a farlo) mi terminava tutto explorer e mi ricaricava la barra, perdendo la visualizzazione di alcune delle icone della tray.
Ecco, separando le cose a livello nativo e non in maniera posticcia come ho fatto io potrebbe forse dare più stabilità alla baracca (e non occorrerebbe il processo che ho fatto e che cambia artificialmente il livello di priorità).
Che dite, sarebbe utile una cosa del genere o sto semplicemente dicendo cavolate?

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Sergio Neddi wrote:Non entro in merito alle questioni sulla sicurezza in quanto non ci capisco molto e non riesco a seguirvi.
Pensavo ad un'altra cosa, riguardo alle migliorie effettuabili.
Una sarebbe la possibilità di supportare partizioni differenti dalle Fat32.
Se vogliamo usare il sistema come server ok per la sicurezza, ma poi lo facciamo girare su partizioni FAT?
So che una partizione NTFS è un casino da gestire perché volutamente incasinata da MS ed inoltre non documentata, ma perché non partizioni ext2, ext3, reiserfs, insomma, roba di provenienza Linux, sicuramente ben documentata?
FAT è brevettato da MS. Non è più possibile, pertanto, utilizzare tale tipo di file system, negli OS free (ed è meglio così, in quanto, è uno dei peggiori FS in circolazione). Ora come ora, pare che ROS funzioni in Ext2, ma non si capisce se poi i coders vogliano passare NTFS. Vedremo...
Sospetto che ci sia una difficoltà, e cioè che, come NTFS è pensata per Windows, così le altre sono pensate per Linux e più difficilmente adattabili, anche per la gestione dei diritti, ecc... non so di preciso, ma immagino che mettere Windows su ext3 sia come giocare fuori casa, alla fine si prendono più gol.
Uhm... NO. Semplicemente, per WinXP è disponibile un driver che permette l'impiego dell'Ext2.
Ma sarebbe interessante.
Altra considerazione: Windows ha il kernel fuso con l'interfaccia grafica, non separato come Linux.
In realtà, Linux è un Kernel.
In particolare explorer fa sia da barra delle applicazioni che da browser per le risorse, per cui, se si inchioda qualcosa s'inchioda tutto e non ri riesce più a controllare niente.
Occorre tener in considerazione un fattore: ROS è opensource, pertanto, tutte ste sciocchezze compiute dalla Microsoft, presto o tardi, verran corrette. Se poi qualcuno rimane su piattaforme MS, auguri a lui.
Ad esempio se io faccio start -> esegui e poi \\pippo, se esiste in rete un PC di nome pippo mi verrà aperta una finestra che mostra le condivisioni del PC. E fin qui va bene.
Mettiamo caso che \\pippo non esista... tutto si blocca, non si riesce più ad operare con la barra finché non c'è il timeout ed appare la finestra che ci informa che pippo non è stato trovato.
Figurati che, su XP, ho letto, in un sito, che la funzione di decompressione dei files .ZIP, può causare problemi, se mantenuta attiva, anche dopo aver installato il programma apposito di gestione dei compressi, in quanto, la funzione di ricerca, và a controllare anche all'interno di tutti i .zip. Occorreva, quindi, agire usando il RegServ32, per rimuovere una .DLL. Ovviamente, anche questo dovrà essere alquanto ri-progettato, su ROS.
[zigozago]
Poi ho provato a vedere come si comporta on il mio malfunzionamento, e...
...quando avveniva il blocco...
potevo mantenere il controllo della barra applicazioni, inoltre, se volevo, potevo chiudere la finestra bloccata senza avere casini (prima, se riuscivo a farlo) mi terminava tutto explorer e mi ricaricava la barra, perdendo la visualizzazione di alcune delle icone della tray.
Sì, ma non solo. Era anche, in allestimento, il desiderio di riscrivere alcune parti dello skin engine del desktop, in modo da renderlo più configurabile, senza necessità di Tweak e altri programmi più o meno costosi, per funzioni che l'OS dovrebbe già fornire all'utente.
Ecco, separando le cose a livello nativo e non in maniera posticcia come ho fatto io potrebbe forse dare più stabilità alla baracca (e non occorrerebbe il processo che ho fatto e che cambia artificialmente il livello di priorità).
Che dite, sarebbe utile una cosa del genere o sto semplicemente dicendo cavolate?
Direi che va bene. Occorre, però, tenere in considerazione, che, su ROS, sarà disponibile anche la modalità di compatibilità. Quest'ultima andrà testata in maniera alquanto massiccia, al fine di aggirare, il più possibile, eventuali crash causati dai vecchi programmi. Inoltre, non si sà ancora nulla, in riferimento agli applicativi eseguiti in ambiente Vista. Si vedrà comunque.

Sergio Neddi
Posts: 6
Joined: Mon Jan 30, 2006 1:21 am

Post by Sergio Neddi »

Figurati che, su XP, ho letto, in un sito, che la funzione di decompressione dei files .ZIP, può causare problemi, se mantenuta attiva, anche dopo aver installato il programma apposito di gestione dei compressi, in quanto, la funzione di ricerca, và a controllare anche all'interno di tutti i .zip. Occorreva, quindi, agire usando il RegServ32, per rimuovere una .DLL.
Ehehehe!
Guarda caso il malfunzionamento di cui parlavo era proprio causato da quello (stano però che non succeda a tutti, ho provato anche su altri PC ma lì non faceva 'sto scherzo).
Ho risolto proprio disregistrando la DLL con regsvr32.
Ci ho messo un po' ad arrivarci in quanto succedeva con vari tipi di file, non solo zip, quindi non pensavo fosse quello.
Per la ricerca di sistema, il fatto che la faccia anche dentro agli zip (odioso) non m'interessava, infatti utilizzo un altro programma per le ricerche e quindi che 'sta DLL ci fosse o no...
E invece 'sta schifezza rompeva le scatole lo stesso.
Morale della favola: meglio togliere ciò che non serve, meno ca**a c'è... meno puzza si sente! :D
Semplicemente, per WinXP è disponibile un driver che permette l'impiego dell'Ext2.
Lo so, ma se non erro non puoi fare il boot da quella partizione: è necessario fare il boot da una partizione vista nativamente dal sistema (FAT o NTFS) e poi puoi accedere ad un'altra partizione, stavolta in ext2.
Penso che ciò sia proprio perché non è supportata nativamente, ma forse mi sbaglio.

folle_invasato
Posts: 134
Joined: Thu Jan 13, 2005 9:11 pm
Location: Pordenone, Italy

Post by folle_invasato »

Sergio Neddi wrote:Altra considerazione: Windows ha il kernel fuso con l'interfaccia grafica, non separato come Linux.
Non è assolutamente vero.. windows ha una HAL, un kernel e un'interfaccia grafica.
Sergio Neddi wrote:Altra considerazione: Windows ha il kernel fuso
In particolare explorer fa sia da barra delle applicazioni che da browser per le risorse, per cui, se si inchioda qualcosa s'inchioda tutto e non ri riesce più a controllare niente.

Ad esempio se io faccio start -> esegui e poi \\pippo, se esiste in rete un PC di nome pippo mi verrà aperta una finestra che mostra le condivisioni del PC. E fin qui va bene.
Mettiamo caso che \\pippo non esista... tutto si blocca, non si riesce più ad operare con la barra finché non c'è il timeout ed appare la finestra che ci informa che pippo non è stato trovato.
Non è che funzionerebbe meglio separare la barra di explorer dal resto? E magari darle una priorità di esecuzione leggermente superiore in modo da poterne sempre mantenere il controllo?
C'è un'impostazione che permette di eseguire ogni finestra di explorer in un processo separato. basta abilitarla..
Sergio Neddi wrote: Che dite, sarebbe utile una cosa del genere o sto semplicemente dicendo cavolate?
:D In win c'è già...in reactos arriverà :P

Sergio Neddi
Posts: 6
Joined: Mon Jan 30, 2006 1:21 am

Post by Sergio Neddi »

folle_invasato wrote:C'è un'impostazione che permette di eseguire ogni finestra di explorer in un processo separato. basta abilitarla..
Non è esattamente così, purtroppo, come dagli esperimenti che ho fatto: se attivi quell'opzione XP crea UN SOLO processo separato anche se apro parecchie finestre ed in più a questo processo da una priorità alta.

Se una finestra si blocca, quindi, blocca tutte le altre finestre e pure la barra non reagisce perché questa continua ad avere una priorità normale mentre il processo bloccato si ciuccia tutto il tempo CPU.

Il barbatrucco che ho descritto più sopra mi consente appunto di dare una priorità maggiore alla barra rispetto alle finestre.

L'opzione di tenere i processi separati devo in ogni caso lasciarla attiva sennò la baracca mi da comunque un unico processo che comprende sia barra che finestre e non posso differenziare.

In ogni caso mi sa che stiamo andando off topic dato che stiamo parlando di ReactOS e non di XP, il discorso che ho fatto sulla barra è solo un esempio di come NON vorrei facesse ReactOS, insomma un brutto esempio da NON imparare! :D

folle_invasato
Posts: 134
Joined: Thu Jan 13, 2005 9:11 pm
Location: Pordenone, Italy

Post by folle_invasato »

Chiedo scusa sull'impostazione di explorer. Hai perfettamente ragione. Esegue le finestre in un solo processo separato.

Cmq non dimentichiamo che il maggiore obbiettivo di design di ReactOS resta la compatibilità con windows...innovando troppo secondo me si rischia di andare a precludere a parecchi software la possibilità di girare su reactos.

E' solo la mia opinione.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest