SELinux overview and example

1. SELinux
Security Enhancement Linux

2. Cos’è SELinux

3. Cos’è SELinux
• Un progetto della National Security Agency

4. Cos’è SELinux
• Un progetto della National Security Agency
• Un modulo del framework Linux Security
Module

5. Cos’è SELinux
• Un progetto della National Security Agency
• Un modulo del framework Linux Security
Module
• L’implementazione di un Flexible Mandatory
Access Control

6. Cos’è SELinux
• Un progetto della National Security Agency

7. Cos’è SELinux
• Un progetto della National Security Agency
• Il cui scopo era quello di dimostrare
l’efficienza di un sistema a controllo
d’accesso vincolato

8. Cos’è SELinux
• Un progetto della National Security Agency
• Il cui scopo era quello di dimostrare
l’efficienza di un sistema a controllo
d’accesso vincolato
• Ha poi lasciato ai vari contributori il
compito di continuare a supportarlo

9. Cos’è SELinux
• Un progetto della National Security Agency
• Un modulo del framework Linux Security
Module

10. Cos’è SELinux
• Un progetto della National Security Agency
• Un modulo del framework Linux Security
Module
• È un framework che consente di inserire a
livello kernel dei moduli per il controllo
degli accessi

11. Cos’è SELinux
• Un progetto della National Security Agency
• Un modulo del framework Linux Security
Module
• L’implementazione di un Flexible Mandatory
Access Control

12. Cos’è SELinux
• Un progetto della National Security Agency
• Un modulo del framework Linux Security
Module
• L’implementazione di un Flexible Mandatory
Access Control
• Per comprendere meglio cos’è partiamo
prima dal Discretionary Access Control

13. Discretionary Access
Control

14. Discretionary Access
Control
• È il sistema del controllo degli accessi
classico di Linux
-rwxr-x--x utente gruppo

15. Discretionary Access
Control
• È il sistema del controllo degli accessi
classico di Linux
-rwxr-x--x utente gruppo
• Perché non va bene?

16. Discretionary Access
Control
• È il sistema del controllo degli accessi
classico di Linux
-rwxr-x--x utente gruppo
• Perché non va bene?
• Perché è Discretionary

17. Discretionary Access
Control
• È il sistema del controllo degli accessi
classico di Linux
-rwxr-x--x utente gruppo
• Perché non va bene?
• Perché è Discretionary
• Come fare allora?

18. Discretionary Access
Control
• È il sistema del controllo degli accessi
classico di Linux
-rwxr-x--x utente gruppo
• Perché non va bene?
• Perché è Discretionary
• Come fare allora?
• Ci viene in aiuto il concetto di Reference
Monitor

19. Reference Monitor

20. Reference Monitor
• Concetto di una macchina astratta che si
interpone agli oggetti controllandone gli
accessi in base ai soggetti

21. Reference Monitor
• Concetto di una macchina astratta che si
interpone agli oggetti controllandone gli
accessi in base ai soggetti
• ReferenceValidation Mechanism

22. Reference Monitor
• Concetto di una macchina astratta che si
interpone agli oggetti controllandone gli
accessi in base ai soggetti
• ReferenceValidation Mechanism
• Modello di implementazione hardware e
software del concetto di Reference
Monitor con le seguenti caratteristiche:

23. Reference Monitor
• Concetto di una macchina astratta che si
interpone agli oggetti controllandone gli
accessi in base ai soggetti
• ReferenceValidation Mechanism
• Modello di implementazione hardware e
software del concetto di Reference
Monitor con le seguenti caratteristiche:
- a prova di manomissione

24. Reference Monitor
• Concetto di una macchina astratta che si
interpone agli oggetti controllandone gli
accessi in base ai soggetti
• ReferenceValidation Mechanism
• Modello di implementazione hardware e
software del concetto di Reference
Monitor con le seguenti caratteristiche:
- a prova di manomissione
- sempre interrogato

25. Reference Monitor
• Concetto di una macchina astratta che si
interpone agli oggetti controllandone gli
accessi in base ai soggetti
• ReferenceValidation Mechanism
• Modello di implementazione hardware e
software del concetto di Reference
Monitor con le seguenti caratteristiche:
- a prova di manomissione
- sempre interrogato
- verificabile

26. Mandatory Access
Control

27. Mandatory Access
Control
• Implementazione del ReferenceValidator
Mechanism interamente a livello software

28. Mandatory Access
Control
• Implementazione del ReferenceValidator
Mechanism interamente a livello software
• Basa la sua politica di controllo degli accessi
su un mandato predefinito

29. Mandatory Access
Control
• Implementazione del ReferenceValidator
Mechanism interamente a livello software
• Basa la sua politica di controllo degli accessi
su un mandato predefinito
offrendo così una maggiore solidità

30. Mandatory Access
Control
• Implementazione del ReferenceValidator
Mechanism interamente a livello software
• Basa la sua politica di controllo degli accessi
su un mandato predefinito
offrendo così una maggiore solidità
a discapito della flessibilità

31. Flexible Mandatory
Access Control

32. Flexible Mandatory
Access Control
• È quindi un controllo degli accessi che
anch’esso si basa su un mandato, ma questo
mandato è flessibile ed adattabile

33. Flexible Mandatory
Access Control
• È quindi un controllo degli accessi che
anch’esso si basa su un mandato, ma questo
mandato è flessibile ed adattabile
• Come lo realizza SELinux?

34. I moduli di SELinux

35. I moduli di SELinux
• Tra i moduli che compongono SELinux il più
importante è il Type Enforcement

36. I moduli di SELinux
• Tra i moduli che compongono SELinux il più
importante è il Type Enforcement
• Seguito dal Role-Based Access Control

37. I moduli di SELinux
• Tra i moduli che compongono SELinux il più
importante è il Type Enforcement
• Seguito dal Role-Based Access Control
• Questi due moduli consento di assegnare un
contesto di sicurezza a soggetti (processi) e
oggetti (risorse)

38. Security Context

39. Security Context
E’ costituito da tre campi principali:
utente:ruolo:tipo

40. Security Context
• utente: definisce l’utente SELinux
E’ costituito da tre campi principali:
utente:ruolo:tipo

41. Security Context
• utente: definisce l’utente SELinux
• ruolo: definisce il ruolo dell’utente
E’ costituito da tre campi principali:
utente:ruolo:tipo

42. Security Context
• utente: definisce l’utente SELinux
• ruolo: definisce il ruolo dell’utente
• tipo: assume più significati in base a cosa è
assegnato.
E’ costituito da tre campi principali:
utente:ruolo:tipo

43. Security Context
• utente: definisce l’utente SELinux
• ruolo: definisce il ruolo dell’utente
• tipo: assume più significati in base a cosa è
assegnato.
- soggetto: dominio del soggetto
E’ costituito da tre campi principali:
utente:ruolo:tipo

44. Security Context
• utente: definisce l’utente SELinux
• ruolo: definisce il ruolo dell’utente
• tipo: assume più significati in base a cosa è
assegnato.
- soggetto: dominio del soggetto
- oggetto: tipo dell’oggetto
E’ costituito da tre campi principali:
utente:ruolo:tipo

45. Policy

46. Policy
• Definisce i permessi d’accesso alle risorse

47. Policy
• Definisce i permessi d’accesso alle risorse
• Ne consente una elevata personalizzazione
grazie anche ad una loro maggiore
granularità

48. Policy
• Definisce i permessi d’accesso alle risorse
• Ne consente una elevata personalizzazione
grazie anche ad una loro maggiore
granularità
• E’ costituita da regole che associano un
dominio ad un tipo ed indicano quali accessi
sono consentiti

49. Targeted Policy

50. Targeted Policy
• E’ la policy attiva di default in Fedora

51. Targeted Policy
• E’ la policy attiva di default in Fedora
• Vincola i permessi solamente ad alcuni
servizi “targeted”

52. Targeted Policy
• E’ la policy attiva di default in Fedora
• Vincola i permessi solamente ad alcuni
servizi “targeted”
• Lascia all’utente un accesso completo al
sistema

54. Domande?

55. Domande?
Vediamo qualche esempio.

56. E per gli altri
programmi?

57. • È possibile integrare le policy di default
E per gli altri
programmi?

58. • È possibile integrare le policy di default
aggiungendo delle regole che specificano
quali accessi sono permessi a quale risorse
E per gli altri
programmi?

59. Come specificare le
regole

60. • Si usa il predicato allow seguito da:
Come specificare le
regole

61. • Si usa il predicato allow seguito da:
• tipo sorgente
Come specificare le
regole

62. • Si usa il predicato allow seguito da:
• tipo sorgente
• tipo destinatario
Come specificare le
regole

63. • Si usa il predicato allow seguito da:
• tipo sorgente
• tipo destinatario
• classe dell’oggetto: definisce i tipi di accessi
consentiti
Come specificare le
regole

64. • Si usa il predicato allow seguito da:
• tipo sorgente
• tipo destinatario
• classe dell’oggetto: definisce i tipi di accessi
consentiti
• permessi: seleziona gli accessi consentiti
Come specificare le
regole

65. • Si usa il predicato allow seguito da:
• tipo sorgente
• tipo destinatario
• classe dell’oggetto: definisce i tipi di accessi
consentiti
• permessi: seleziona gli accessi consentiti
allow user_t bin_t : file {read execute getattr}
Come specificare le
regole

66. Esempio

67. Conclusioni

68. SELinux offre una buona protezione contro gli
attacchi “0-day”
Conclusioni

69. SELinux offre una buona protezione contro gli
attacchi “0-day”
Più cose insolite si vogliono permettere di far
fare ai programmi più permessi si ritroverà
l’attaccante nel momento in cui è riuscito a
ottenere il controllo del flusso d’esecuzione
Conclusioni

70. SELinux offre una buona protezione contro gli
attacchi “0-day”
Più cose insolite si vogliono permettere di far
fare ai programmi più permessi si ritroverà
l’attaccante nel momento in cui è riuscito a
ottenere il controllo del flusso d’esecuzione
Occorre raggiungere un buon compromesso
tra “usabilità” e sicurezza.
Conclusioni

71. Domande?