L'aggressore può scappare dalla prigione di apparmor con il seguente profilo?

5

Di seguito è riportato un profilo di esempio che ho creato per le app Web, in cui ho limitato i file / i comandi ai quali può accedere. Include profili a nginx, php-fpm and mysql , nessun comando è consentito, solo poche directory / file per l'accesso in lettura / scrittura / flock e socket di rete.

(Il resto si trova in mio repository github )

/usr/bin/php-fpm {
  #include <abstractions/base>

  capability chown,
  capability kill,
  capability setgid,
  capability setuid,

  # Suppress the "DENY" error logs
  deny /usr/bin/bash x,

  /etc/php/** r,
  /run/php-fpm/ r,
  /run/php-fpm/php-fpm.* w,
  /usr/bin/php-fpm mr,
  /usr/lib/php/modules/* mr,

  /var/html/{**,} r,

  # logs
  /var/log/ r,
  /var/log/php*.log w,

  # Web folders that need write access
  /var/html/icy/{cache,logs,files,images,downloads}/{**,} rwk,
}

In questo momento, credo che dopo un exploit remoto riuscito, l'utente malintenzionato possa influire solo sulla cartella dell'app Web e non possa compromettere ulteriormente il sistema,

Quindi la mia domanda è, c'è ancora una possibilità che l'aggressore possa uscire da questo?

E come?

    
posta daisy 21.05.2013 - 16:41
fonte

1 risposta

1

Naturalmente. Il tuo profilo (e nessun profilo apparmore) non fa nulla per limitare la superficie di attacco del kernel. Un utente malintenzionato può sfruttare il kernel, sganciare l'apparmor ed essere fuori.

only few directories / files for read / write / flock access, and network socket.

Notalo? Questo aggiunge centinaia di altri file al tuo profilo. Anche se il tuo profilo può sembrare abbastanza stretto, in realtà consente un accesso molto ampio.

Detto questo, non ci sono problemi enormi. No UX, nessun accesso in scrittura a cose veramente importanti. Queste capacità fanno schifo - sei sicuro che siano necessarie? Probabilmente lo sono.

    
risposta data 24.12.2013 - 23:58
fonte

Leggi altre domande sui tag