Profilo dell'Apparmor che nega l'accesso in lettura con flag r

Naviga le tue risposte
2

Ho generato un profilo di apparmor per il tor binario che viene fornito in Ricochet: 

# Last Modified: Sun Apr  2 2017
#include <tunables/global>

/ricochet/*-ricochet/tor {
  #include <abstractions/base>

  deny /etc/ld.so.preload r,

  deny /proc/sys/kernel/random/uuid r,
  /ricochet/*-ricochet/config/tor/ rwk,
  /ricochet/*-ricochet/config/tor/ r,
  /ricochet/*-ricochet/config/tor/cached-certs r,
  /ricochet/*-ricochet/config/tor/cached-microdesc-consensus r,
  /ricochet/*-ricochet/config/tor/cached-microdescs r,
  /ricochet/*-ricochet/config/tor/cached-microdescs.new r,
  /ricochet/*-ricochet/config/tor/control-port w,
  /ricochet/*-ricochet/config/tor/control-port.tmp rw,
  /ricochet/*-ricochet/config/tor/default_torrc r,
  /ricochet/*-ricochet/config/tor/lock rwk,
  /ricochet/*-ricochet/config/tor/state rw,
  /ricochet/*-ricochet/config/tor/state.tmp rw,
  /ricochet/*-ricochet/config/tor/torrc r,
  /ricochet/*-ricochet/tor mr,
  deny /sys/devices/system/cpu/ r,
  /usr/share/tor/geoip r,
  /usr/share/tor/geoip6 r,

}

Non sono sicuro di quanto sia sensibile /proc/sys/kernel/random/uuid così li ho negati. Ricochet si apre bene con loro negato. Dimmi se dovrei consentire loro però ...

La mia più grande preoccupazione è /usr/share/tor/geoip . L'ho impostato per la sola lettura, ma sto ancora ricevendo lamentele su journalctl: 

$ journalctl -af
Apr 02 <uname removed> kernel: audit: type=1400 audit(1491170231.720:200): apparmor="DENIED" operation="open" profile="/ricochet/<removed>-ricochet/tor" name="/usr/share/tor/geoip" pid=2563 comm="tor" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Apr 02 <uname removed> kernel: audit: type=1400 audit(1491170231.720:201): apparmor="DENIED" operation="open" profile="/ricochet/<removed>-ricochet/tor" name="/usr/share/tor/geoip6" pid=2563 comm="tor" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Qualcuno può aiutarmi a eseguire il debug di questo? Perché l'apparmor nega l'accesso r ?

    
posta user143794 03.04.2017 - 15:36
fonte

1 risposta

1

Entrambi avete ricaricato AppArmor e riavviate l'applicazione? Il semplice ricaricamento di AppArmor non significa che le modifiche alla politica avranno effetto immediato. Se ciò non funziona, puoi autorizzare la totalità di /usr/share/tor . È scrivibile solo da root, quindi non c'è alcun problema con i programmi maligni che lo modificano e non contiene alcuna informazione sensibile. Non è scrivibile, quindi non trarrai vantaggio da un controllo più preciso su di esso. Semplicemente lasciare che Tor legga qualcosa al suo interno è perfettamente sicuro: 

/usr/share/tor/ r,
/usr/share/tor/** r,

Per quanto riguarda /proc/sys/kernel/random/uuid , non è sensibile. Tutto ciò che fa è restituire dati casuali formattati come UUID. Non fornisce più informazioni di quante% fa/dev/urandom. Da proc(5) : 

/proc/sys/kernel/random/uuid (since Linux 2.4)
    Each read from this read-only file returns a randomly generated
    128-bit UUID, as a string in the standard UUID format.
    
risposta data 30.11.2017 - 05:17
fonte

Leggi altre domande sui tag

Sicurezza del client tramite UDP UAC o accesso all'account amministratore prima di installare il software?