SfideDiProgrammazioneUniVR / PortafoglioVoti

0 stars 9 forks source link

Sistema di backup automatico del lavoro dello studente nel sistema esami UniVR #6

Open Flipper97 opened 6 years ago

Flipper97 commented 6 years ago

Alcuni corsi di ateneo si avvalgono di un sistema esami UniVR che il docente parametrizza dal portale Dove gli studenti accederanno con credenzali "esame" e pwd "esame" da schermata iniziale delle macchine in uno dei laboratori di ateneo. A volte succede che una macchina si impalli durante l'esame e allora lo studente perde tutto quanto realizzato (non è piacevole per nessuno).

Un paio di anni or sono avevamo richiesto che il sistema esami UniVR consentisse di accedere a siti da una whitelist impostata e curata dal docente, il che, per il corso di Algoritmi della magistrale, ci ha consentito l'impiego del CMS per una valutazione contestuale con feedback immediato sul lavoro dello studente durante l'esame. Col senno di poi, questo ha anche consentito che in certe situazioni lo studente possa recuperare il suo lavoro (quantomeno quello sottomesso al CMS), una bella novità che suggerisce l'opportunità di un servizio da curare meglio e valido per tutti i corsi. E' ora chiaro che esiste questa possibilità, e che essa, in certe modalità, può essere realizzata senza arricchire il servizio erogato dal server esami UniVR.

Si avvede pertanto l'opportunità immediata di progettare e realizzare un sistema per un servizio di backup gestito dallo studente che lavori dentro l'account esame UniVR. Il recupero deve essere consentito solo allo studente affiancato dal docente (in questo modo non pesiamo sugli erogatori del servizio esami UniVR). Nota: a volte la macchina si impalla come connessione al portale esami ma rimane possibile operare al di fuori di esso.

Proprietà Descrizione
Punti preventivati 2
Restrizioni Nessuna
Aree di interesse Ateneo, esamiUniVR
platipo commented 6 years ago

Sarei interessato a sviluppare uno script che gestisca il backup automatico attraverso l'uso di git. Lo script sarà strutturato come una piccola utility che potrà essere lanciato su una directory e si occuperà di salvare automaticamente le modifiche e pusharle verso un "server" locale.

Purtroppo git non integra nessuna nozione di permessi e utenze pertanto è necessario utilizzare un servizio che garantisca che ogni studente possa accedere solamente al proprio lavoro. Il servizio di gestione potrebbe essere gitolite. A livello di configurazione è possibile generare per ogni utente

repo  vrXXXXXX
     RW   =   prof
     W    =   vrXXXXXX

che fa riferimento ad una repository memorizzata sul server nella directory vrXXXXXX (lato server) a cui possono accedere solo studente e professore. Il docente può leggere (clone e fetch) e scrivere (push), mente allo studente è consentito solo il scrivere.

Così l'intervento del professore sarà necessario per il recupero del lavoro e lo studente non dovrà preoccuparsi di nulla se non di lanciare lo script all'inizio dell'esame.


Possibile proposta extra

Lo script esegue l'azione di salvataggio ogni n secondi (al momento 30) quindi ogni repository conterrà un quantitativo non indifferente di commit. Penso che sarebbe utile un piccolo tool grafico per navigare tra i commit, magari fatto a modello di ranger, Python con libreria curses, che permetta di spostarsi utilizzando i soli tasti freccia e che visualizzi dei diff visuali.

platipo commented 5 years ago

Lo sviluppo dello script con git non sembra un'alternativa viabile perché git non fornisce nativamente una gestione permessi con granularità fine.

Riducendo la complessità del backup è possibile adottare una soluzione più semplice. Infatti, riducendo il volume della ridondanza dall'intera storia (git) ad un singolo snapshot, è possibile adottare una soluzione più semplice. La soluzione manterrebbe ancora la strutturazione in due script: uno client (studente) e uno server.

Lo script client avrà il compito di lanciare un daemon che ogni 30/60 secondi comprimerà il contentuto della cartella di backup e lo invierà al server. Dall'altro lato, lo script server riceverà le richieste e memorizzerà i file mediante un identificativo che contraddistinguerà il PC mittente.

Per quanto riguarda il client è possibile delinearlo come uno script bash che utlizzi wget/curl (sono pacchetti default in Ubuntu 14.04) per inviare i file. Inoltre lo script potrebbe anche integrare alcune funzionalità per rendere più agevole al docente il recupero, come un alias. Però uno script che implementi quest'ultima funzionalità sarebbe pericoloso se lasciato in chiaro, per cui sarebbe necessario offuscarlo (ad esempio con shc, che trasforma il bash in un eseguibile).

Diversamente, il server potrebbe essere scritto in Python come un semplice web server con autenticazione (qui un breve esempio), in cui si utilizza il POST per inviare file e per richiedere il download dei file attraveso l'autenticazione. Infine il server dovrebbe inoltre implementare un meccanismo di identificazione del mittente attraverso IP/MAC/hostname al fine di permettere al docente di recuperare il backup utilizzando esclusivamente il nome della postazione (es. pcD8 potrebbe essere la postazione 8 in Delta).

romeorizzi commented 5 years ago

On 12/21/18 6:11 PM, platipo wrote:

Lo sviluppo dello script con git non sembra un'alternativa viabile perché git non fornisce nativamente una gestione permessi con granularità fine.

Parli con linguaggio molto tecnico, ma omettendo di specificare. Qui non riesco a decifrarti.

Riducendo la complessità del backup è possibile adottare una soluzione più semplice. Infatti, riducendo il volume della ridondanza dall'intera storia (git) ad un singolo snapshot, è possibile adottare una soluzione più semplice. La soluzione manterrebbe ancora la strutturazione in due script: uno client (studente) e uno server.

Lo script client avrà il compito di lanciare un daemon che ogni 30/60 secondi comprimerà il contentuto della cartella di backup e lo invierà al server.

Grazie per tutte le alternative che hai considerato e per tutti i problemi che ti sei posto. Forte della faticosa esperinza pregressa d'uso del sistema in cui andiamo ad inastonare questo ulteriore servizio, provo a suggerire come sposterei alcune scelte, l'obiettivo è rendere sia più semplice che sicuro il sistema. Ma la vostra conoscenza di cosa fattibile supera di gran lunga la mai (anche perchè curerete poi voi la realizzazione, ma anche perchè ne sapete di più), quindi conviene che rimaniamo fittamente dialoganti.

Ovviamente tutti condivdiamo che la semplicità è un ottimo criterio ed obiettivo.

Quindi eviterei di comprimere. Può solo complicare le cose. In più posti di quelli che al momento possiamo prevedere.

Inoltre porterebbe a degli ingenti sprechi di memoria nel repositori git, che dovrebbe ricopiare (in forma compressa) anche i file che invece in quei 30/60 secondi non hanno subito modifica. Alzerebbe infine il carico computazionale sulla postazione (anche se il trafico potrebbe richiedere più tempo ma quello non sarebbe sottratto dalla postazione, dato che lo script client mi attendo lavorerà in background).

Dall'altro lato, lo script server riceverà le richieste e memorizzerà i file mediante un identificativo che contraddistinguerà il PC mittente.

I range di IP attuali con cui si esce verso l'esterno dall'aula delta sono i seguenti:

ip: 10.220.32.101,10.220.32.102/31,10.220.32.104/29,10.220.32.112/28,10.220.32.128/26,10.220.32.192/28,10.220.32.208/29,10.220.32.216/30,10.220.32.220

Nella whitelist non posso collocare indirizzi https ma solo http, quali ad esempio:

http://esame.cms.di.unipi.it/ http://profs.sci.univr.it/~rrizzi/classes/Algoritmi/modExam/

La ragione è che nella soluzione attuale il proxi deve poter vedere e modificare gli header dei pacchetti in uscita dall'aula.

Un richiamo alla delicatezza del tutto: non abbiamo (nè miriamo alla) sicurezza intrinseca.

Morale, credo non sia impossibile impersonificare di essere un'altra macchina.

Su questo, non dovrebbe pesare, ma chiederei allo studente di inserire la propria matricola anche nel sistema di backup e che essa possa rimanere visibile ad io quando passo a controllare. (Se becco uno con una matricola che non corrisponde).

L'idea è che la sicurezza migliora molto se la si costruisce a più strati, avere sia la matricola che la macchina sottopone a troppi rischi e possibilità di imprevisto chi volesse fare il furbo, e ci darebbe un sistema che poi diviene flessibile nell'uso avendo già predisposto meccanismi su entrambi i fronti.

Per quanto riguarda il client è possibile delinearlo come uno script bash che utlizzi wgethttps://stackoverflow.com/a/17699948/curl (sono pacchetti default in Ubuntu 14.04) per inviare i file. Inoltre lo script potrebbe anche integrare alcune funzionalità per rendere più agevole al docente il recupero, come un alias. Però uno script che implementi quest'ultima funzionalità sarebbe pericoloso se lasciato in chiaro, per cui sarebbe necessario offuscarlo (ad esempio con shchttps://github.com/neurobin/shc, che trasforma il bash in un eseguibile).

Quando io lancio lo script dalla nuova postazione dello studente, inserisco la matricola dello studente (e, se ne sono in possesso, anche lo IP della macchina su cui era prima. Infine, e rischia di essermi anche la cosa meno costosa, inserisco una mia password che mi tengo solo per mè. Non vedo possibili rischi (la password non viene verificata in locale) )-

Ovviamente la verifica della password (e servizio della richiesta) non avviene in locale ma viene fatto da un servizio nostro in cloud. Tale servizio mi offre anche un riscontro mandandomi una mail coi seguenti vantaggi:

  1. la mail contiene tutti i dati dell'operazione effettuata, IP sorgente, IP destinazione, matricola, ora

  2. contiene anche su ub segreto che è sul nostro server che offre il servizio e non sule repo GitHub del vostro progetto open-source.

Il punto 2 serve per impedire che degli studenti particolarmente malicious possano cercare di dissimulare l'interfaccia del sistema per carpirmi la password.

Diversamente, il server potrebbe essere scritto in Python come un semplice web server con autenticazione (quihttps://gist.github.com/dragermrb/108158f5a284b5fba806 un breve esempio), in cui si utilizza il POST per inviare file e per richiedere il download dei file attraveso l'autenticazione. Infine il server dovrebbe inoltre implementare un meccanismo di identificazione del mittente attraverso IP/MAC/hostname al fine di permettere al docente di recuperare il backup utilizzando esclusivamente il nome della postazione (es. pcD8 potrebbe essere la postazione 8 in Delta).

Mi pare più facile, sicuro, e robusto impostare il mapping sulla matricola. Certo, per una sicurezza a più strati mettiamo anche l'IP (e con questo la matricola viene associata aa un IP come si inizia a fare backup di salvataggio. Quando sarà possibile e comodo, cerchiamo di fare il controllo dell'IP anche quando io richiedo il recupero. Sicuramente inserire la matricola in quel momento non mi costerà nulla, e l'IP della nuova macchina può andare ad inserirsi in automatico senza che io lo debba andare a specificare. Per il vecchio IP se posso inserirlo io è un controllo che faccio su due piedi. In caso contrario abbiamo anceh che ogni info sulla transizione del posseso dei file mi viene recapitata in una mail).

Il sistema può poi fare altri controlli, tipo che non stia venendo usata contemporanemante la stessa matricola per fare backup da due postazioni distinte, e segnalarmi subito (anche per mail l'eventuale anomalia).

Ad una matricola è consentito passar da un IP all'altro solo quando lo richiedo io con quell'atto che dicevamo sopra, immettendo la mia password segreta che non è su GitHub na solo su server.

Quando passo tra i calcolatori posso sempre visualizzare con che matricola uno è loggato al sistema di backup. E' un controllo che faò a campione, quando non sono sotto pressione e mi costa poco farlo, mentre passo per conrollare che le matricole con cui sono entrati nella piattaforma esemi univr coincide con quella sul loro tesserino (quella riportante una foto che corrisponde alla faccia).

A nessuno converà rischiare.

Romeo

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/SfideDiProgrammazioneUniVR/PortafoglioVoti/issues/6#issuecomment-449444645, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALljbneF7R4eAxfYzs7L3fuH3pth4Qd-ks5u7RY1gaJpZM4XxNWY.

--


  \   Romeo Rizzi

____\ http://profs.sci.univr.it/~rrizzi / Romeo.Rizzi@univr.itmailto:Romeo.Rizzi@univr.it Tel: +39.3291780915 (also Whatsapp, but no SMS please) / off: +39.045.8027088 (fax: +39.045.8027068 - only shared)

    Department of Computer Science, University of Verona

Ca' Vignal 2, strada le Grazie 15, I-37134 Verona - VR - Italy


platipo commented 5 years ago

Lo sviluppo dello script con git non sembra un'alternativa viabile perché git non fornisce nativamente una gestione permessi con granularità fine.

Parli con linguaggio molto tecnico, ma omettendo di specificare. Qui non riesco a decifrarti.

Volendo sviluppare il sistema interamente su git, il server è scritto con gli hooks di git-server. Quest'ultimi non hanno nessuna nozione di permessi utente, perciò ogni repository sarebbe accessibile a chiunque. Quindi si dovrebbero gestire i permessi ad un livello superiore usando un software di controllo degli accessi (come gitolite), ma questo strato di controllo implementa feature troppo avanzate per i nostri scopi, compromettendo la semplicità della soluzione.

Quindi eviterei di comprimere. Può solo complicare le cose. In più posti di quelli che al momento possiamo prevedere.

Non potendo più affidarsi al sistema di git per i motivi sopra riportati, la soluzione che semplificherebbe il problema sarebbe il singolo salvataggio di tutto il lavoro. Questo salvataggio, composto da sorgenti dello studente, è più semplice nel trasferimento e nella gestione se è un file unico invece di tanti piccoli file.

Mi pare più facile, sicuro, e robusto impostare il mapping sulla matricola. Certo, per una sicurezza a più strati mettiamo anche l'IP (e con questo la matricola viene associata aa un IP come si inizia a fare backup di salvataggio. Quando sarà possibile e comodo, cerchiamo di fare il controllo dell'IP anche quando io richiedo il recupero. Sicuramente inserire la matricola in quel momento non mi costerà nulla, e l'IP della nuova macchina può andare ad inserirsi in automatico senza che io lo debba andare a specificare. Per il vecchio IP se posso inserirlo io è un controllo che faccio su due piedi. In caso contrario abbiamo anceh che ogni info sulla transizione del posseso dei file mi viene recapitata in una mail).

Il sistema con le matricole potrebbe rivelarsi molto lacunoso poiché consentirebbe agli studenti di "scambiarsi" gli esami senza dare nel'occhio. Ad esempio, supponiamo che in sede di esame, due studenti A (secchione) e B (impreparato) lancino lo script di backup invertendo le matricole (consapevolmente!). Successivamente A e B, simulando più o meno contemporaneamente un guasto alle rispettive macchine, avrebbero modo di sfruttare a loro vantaggio il recupero del salvataggio effettuato dal docente!!! In che modo? A e B esibendo le loro corrette matricole, permetterebbero a B di recuperare le soluzioni prodotte in precedenza da A.

Esiste anche il caso in cui, in buona fede, uno studente potrebbe sbagliare a inserire la matricola impedendo così il futuro recupero delle sue soluzioni d'esame.

Sono dell'opinione che "non bisogna mai fidarsi del client", pertanto preferirei affidarmi solo a dati che posso verificare e che lo studente non possa controllare, in particolare mi riferisco all'indirizzo MAC. Secondo me, il modo più sicuro e meno dipendente dal controllo utente sarebbe creare un mapping tra MAC e un codice posizionale che è spiegato graficamente qui sotto:

(purtroppo mi è scappato un piccolo errore di battitura nelle immagini) Rappresentazione schematica aula Delta

per vedere l'immagine più grande basta cliccarci sopra

Mapping aula Delta

per vedere l'immagine più grande basta cliccarci sopra

Il mapping è abbastanza semplice ed è costituito a tre livelli:

  1. il primo divide l'aula in varie zone, nel caso della Delta avremo ala destra, cntro e ala sinistra (vedi schema sopra)
  2. il secondo comprende le file in cui è suddivisa la zona, nel caso della Delta nella zona centrale avremo sei righe (vedi schema sopra)
  3. il terzo fa riferimento alla posizione (a partire da sinistra) di ogni singolo calcolatore presente in ogni fila

Pertanto il recupero del backup non sarebbe più dipendente dal numero di matricola e dall'IP ma solo dalla posizione del guasto.

Il punto 2 serve per impedire che degli studenti particolarmente malicious possano cercare di dissimulare l'interfaccia del sistema per carpirmi la password.

Il sistema può poi fare altri controlli, tipo che non stia venendo usata contemporanemante la stessa matricola per fare backup da due postazioni distinte, e segnalarmi subito (anche per mail l'eventuale anomalia).

Ha ragione, è necessario un meccanismo di logging.

platipo commented 5 years ago

In seguito a quanto emerso dagli ultimi incontri coi tecnici informatici riassumo i futuri cambiamenti concordati.

La sottostante immagine descrive generalmente il nuovo protocollo di autenticazione. Gli attori all'interno della figura sono: il professore (PROF), il server dell'ateneo, il server di backup, gli studenti (A, B, C...).

auth-proto

Le interazioni sono intese nel seguente ordine

  1. Nero: Il professore inserisce una chiave condivisa tra server che verrà utilizzata per criptare/decriptare i dati dello studente (es. matricola, nome e cognome, IP, timestamp, ecc...) attraverso crittografia simmetrica.
  2. Rosso: Lo studente si autentica presso il server di ateneo che genera una stringa criptata contenete i dati dello studente.
  3. Verde: Lo studente può scaricare l'eseguibile per fare il backup automatico e copiare la stringa criptata.
  4. Blu: Lo studente avvierà lo script utilizzando la stringa come argomento. Questa verrà inviata al server che controllerà che l'IP corrisponda con quello della richiesta e successivamente assocerà la matricola coi i futuri salvataggi.
  5. Giallo: Il server manderà risponderà allo studente con l'esito dei controlli server.