Regole obbligatorie per il controllo di accesso, come gestire Python, Bash e altri interpreti?

1

Domanda

(a) C'è? e se sì (b) quale è un modo standard o accettato per i sistemi MAC di trattare software complessi e in particolare con Python, Bash e altri interpreti? (in termini di creazione di regole per questo tipo di software "complesso" e "versatile")

Per esempio con python, mi sembra poco pratico regolare l'accesso che il processo python riceve sulla base degli eseguibili (che saranno sempre gli eseguibili python ecc.). Nel migliore dei casi preferirebbe essere regolato in base all'affidabilità del codice "python-script" coinvolto (dato che questo definiva anche le risorse necessarie).

Sfondo

  • In riferimento a MAC (controllo di accesso obbligatorio) si intende fare riferimento a determinati software come SELinux, grsecurity, TOMOYO, Apparmor e simili. (Sto ancora lottando con il termine giusto per fare riferimento a quei concetti e software, ed è per questo che lo esprimo qui, cercando di evitare l'ambiguità.)

  • Il MAC è concepito qui per essere uno strumento / modo per migliorare la sicurezza che va in qualche modo oltre le cose possibili con il controllo di accesso discrezionale (DAC).

  • Questo "valore di sicurezza aggiuntivo" è causato controllando l'accesso in modo più dettagliato di quanto potrebbe essere possibile con il DAC. Ad esempio, l'accesso che un software riceve può basarsi su più di un semplice USER con cui il processo è iniziato. E naturalmente i file e le risorse che possono essere toccati da un determinato processo sono nel migliore dei casi adattati al limite essenziale di cui il programma ha effettivamente bisogno.

  • Può essere visto come un obiettivo chiave di un MAC per limitare l'accesso al minimo necessario.

  • Se limitare (per questioni di sicurezza) l'accesso di un programma a quelle risorse di cui ha effettivamente bisogno è qualcosa che è richiesto da un sistema MAC, questo sembra più facile / pratico per software che ha un limite molto limitato funzionalità. Allo stesso modo, software molto più versatile e complesso sembra essere molto più difficile essere limitato e limitato.

posta humanityANDpeace 19.12.2012 - 09:51
fonte

2 risposte

1

Per le lingue complete di Turing, non è possibile rilevare ciò che stanno per fare o accedere prima del tempo. Puoi provare per rilevare determinate cose in base all'utilizzo di varie classi e parole chiave specifiche della lingua, ma non è facile.

Supponiamo che tu stia cercando di impedire a qualcuno di chiamare alert() in Javascript. Considera quanto segue:

exec(
  atob('dmFyIHQ9MSx4PTA7eD1NYXRoLmxvZyh0KTsgaWYoeDwxKXthbD9ydCgnZGVycCcpO30=')
    .replace(/\?/g,'t')
);

Puoi davvero scrivere qualcosa che sempre identifica le chiamate di avviso? No!

L'unico modo per ottenere ciò è fornire il controllo a un livello basso, ad es. entro alert() stesso. Ovviamente questo non è l'ideale; puoi collegare tutti i possibili motori JavaScript in ogni browser? Di nuovo, no. Quindi devi andare ancora più in basso, magari collegare tutte le chiamate all'API di sistema utilizzata per creare nuove finestre. Oh, ma ora devi essere in grado di distinguere tra un messaggio alert() e una finestra normale.

Non è facile come potrebbe sembrare, vero?

Questo è esattamente il motivo per cui la maggior parte dei sistemi di controllo accessi obbligatori si focalizzano interamente sull'accesso alle risorse , piuttosto che sulle operazioni. Devi sapere in anticipo cosa stai cercando di proteggere, e devi sapere in che modo sarà possibile accedere a quella risorsa. In quanto tale, non esiste un modo generico per fare ciò che vuoi, anche su una lingua specifica. È necessario configurare manualmente le restrizioni in anticipo.

    
risposta data 19.12.2012 - 11:44
fonte
0

Devi limitare non python all'intero ma particolare script python. (Ad esempio /usr/bin/rdiff-backup ). AFAIK, Smack e TOMOYO (e CaitSith) supportano questo approccio. Quindi, lo script di minaccia ha lanciato direttamente (quindi dovrebbe avere #!/usr/bin/python come prima riga e + x perms) come se avesse il proprio dominio (in TOMOYO) o possedere etichette di sicurezza allegate al file di script stesso (Smack).

Inoltre, TOMOYO supporta il trasferimento manuale del dominio - questo è utile per cose come Apache (con mod_tomoyo). Lo script (se consentito) può passare "manualmente" a un altro dominio di sicurezza, quando si accede, ad esempio, a dati di particolari utenti.

    
risposta data 31.12.2012 - 17:39
fonte

Leggi altre domande sui tag