====== Q/A ======

==== 10/10/2023 ====

SELinux: \\
    D: Multi Level Security può essere una buona tecnologia per il nostro Use case?\\
    R: Multi Level Security è una modalità di utilizzo di SELinux in cui le possibilità di configurazione esplodono: ad ogni soggetto (processo) e ogni oggetto (file, socket, ...) viene assegnato un livello o un range di segretezza. \\
    Altamente configurabile, di solito viene utilizzato in organizzazioni in cui è necessario un altissimo livello di segregazione tra livelli (FBI, CIA, DOD). Sconsigliato perché ha bisogno di un alto grado di configurazione iniziale e aggiunga una difficoltà nella manutenzione del sistema in evoluzione.\\
    \\
    A partire da questo punto, è emersa la modalità di utilizzo Multi Category Security (MCS) che implementa un sottoinsieme del MLS e permette di trattare entità dello stesso processo (esempio, docker) come se fossero entità separate. Questo viene molto utile per segregare ad esempio due container di docker che, nella modalità d'uso di default, avrebbero gli stessi privilegi e quindi potrebbero comunicare tra di loro.\\
    \\
    \\
    \\
    D: è possibile implementare una sorta di RAM security?\\
    R: SELinux definisce alcune policy che proteggono la lettura della RAM. Abbiamo diversi casi:\\
    - Utente non privilegiato sull'host: non ha accesso a nessun dato della RAM;\\
    - Utente che ha ottenuto root sull'host: ha accesso solo ai dati dei processi che appartengono a se stesso, quindi un sottoinsieme non privilegiato;\\
    - Utente root (protetto da password): riesce ad accedere ad un sottoinsieme dei dati dei processi. Non è chiaro l'insieme di processi visibili a questa tipologia di utente, possibilità di indagare e nel caso implementare ulteriori policy di sicurezza in fase di integrazione di SELinux con BoxOS\\
    \\
    Un ulteriore livello di sicurezza contro il dump della RAM è quello nascondere a tutti gli utenti se non root la lista di processi in esecuzione. Implementazione semplice e senza impatto utilizzando il flag hidepid di procfs (https:%%//%%linux-audit.com/linux-system-hardening-adding-hidepid-to-proc/)\\
    \\
    \\
Architettura:\\
    D: Test catalog / test execution: Possono essere sviluppati in parallelo?\\
    R: Dopo un'analisi con il resto del team, non sono emerse forti dipendenze che non permettano lo sviluppo in parallelo dei due moduli.\\