Forum Debian Users Gang

Logi Apparmora masz w zazwyczaj w [b]/var/log/kern.log[/b] albo w DMESG, dla akcji AA są rozstrzygające.

Jeżeli AA coś blokuje, to tam powinno pisać co i dlaczego.

Przykład logu AA:

[26049.302488] audit: type=1400 audit(1492977794.213:4049): apparmor="DENIED" operation="mkdir" profile="/usr/lib64/firefox/firefox" name="/home/pacjent.nv/" pid=12155 comm="Compositor" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

Logi z PHP nie rozróżniają blokowania z AA od blokowania przez błędy CHMOD/ACL.

PS:
Na przywołanym w sznurku profilu AA Presta działa na Nginx+PHP-FPM
bez większych problemów.

Ostatnio edytowany przez Jacekalex (2017-04-23 22:10:23)

Apparmor na pewno włączony?
Co to w ogóle za system operacyjny i jaki kernel?
Program Audit masz przypadkowo zainstalowany? (niezbędny do AA nie jest, za to przechwytuje logi AA i SELinuxa do swojego logu).
Jeśli tak, to zobacz w

/var/log/audit/*

Poza tym pokaż wyniki:

grep -i apparmor /boot/config-$(uname -r)

aa-status

cat /sys/module/apparmor/parameters/audit

Ja sobie do przełączania trybu logowania AA (tryb cichy, normalny) zrobiłem takiego skrypta -przełącznik:
Zwie się:

cat /usr/local/sbin/aalog

a zawiera:

#!/bin/bash

AUDIT="/sys/module/apparmor/parameters/audit"

 grep quiet $AUDIT 2>&1 >/dev/null && echo -n normal > $AUDIT || echo -n quiet > $AUDIT;
 
 STATUS=`cat $AUDIT `;
 
 echo "Status AUDIT zmieniony na  $STATUS ;)";
 exit 0;

Pozdro

Ostatnio edytowany przez Jacekalex (2017-04-24 05:42:22)

Jeżeli Audit jest włączony, a w /var/log/audit* nie ma logów AA, to go lepiej skonfiguruj  albo odinstaluj, bo widocznie wysyła logi AA  do /dev/null.

Poza tym zobacz, czy proces PHP jest faktycznie chroniony, robi się to tak:

cat /proc/$PID/attr/current

np:

for PID in `pgrep php`; do cat /proc/$PID/attr/current; done;
/usr/lib*/php5.*/bin/php-fpm (enforce)
/usr/lib*/php5.*/bin/php-fpm (enforce)

Ostatnio edytowany przez Jacekalex (2017-04-25 01:07:31)

[b]deny owner[/b] jest po to, żeby po ewentualnym załadowaniu przez dziurę np w WP beckdoora c99.php serwer nie mógł go uruchomić.

Dlatego php-fpm może otwierać tylko te pliki, które do niego nie nalezą.

To takie małe, ale bardzo praktyczne rozwiązanie.

Jak koniecznie chcesz aktualizować WP czy coś innego przez panel administracyjny, to zawsze możesz za Nginxem (w trybie proxy albo na innym porcie, chroniony za http-auth albo lepiej certyfikatem PKCS#12) ustawić Lighttpd czy Apacha, który będzie pracował jako inny user systemowy, i będzie miał prawo zapisu plików php, natomiast publiczny Nginx będzie je mógł tylko otwierać.

To wszystko jest do zrobienia,  chociaż jest z tym trochę zabawy.
Ale przede wszystkim, jak długo nie potrafisz się dostać do logów AA, to się za Apparmora nie zabieraj w ogóle.

Niby twierdzisz, że AA coś blokuje, ale wyniku polecenia z roota:

aa-status

jakoś nie potrafisz podać o logach w ogóle nie wspominając.

Jeżeli nie ma śladu w logach, to skąd wiesz, że to AA coś zablokował?

Ostatnio edytowany przez Jacekalex (2017-04-26 04:17:38)

Apr 27 00:08:11 hostname kernel: [  699.195518] audit: type=1400 audit(1493165493.400:43): apparmor="DENIED" operation="mknod" profile="/usr/sbin/php5-fpm" name="/v
ar/lib/php5/sessions/sess_blabla" pid=1823 comm="php5-fpm" requested_mask="c" denied_mask="c" fsuid=111 ouid=111

Spróbuj, czy pójdzie:
/var/lib/php5/sessions/** rwkl,

Co do /var/www/presashop, to troszkę nie dogadaliśmy się z koncepcją.
Zobacz bez Apparmora, czy to wchodzi czysto, bo profil AA ma zamknąć php-fpm z w klatce, żeby wobec jakiegoś błędu w PHP nie zrobił rzeczy zabronionej.

Dlatego do aktualizacji i instalacji Presty zaproponowałem jakiś schowany za Nginxem lekki serwer typu Lighttpd, który będzie chodził bez restrykcji,
i będzie właśnie do aktualizacji i administracji skryptem CMS.

Jeżeli natomiast AA  blokuje Prestę przy normalnym działaniu strony (nie backendu administracyjnego), to pokaż logi z AA z tych akcji w lokalizacjach:

/var/www/prestashop/app/cache/prod/doctrine/** rw,
  /var/www/prestashop/app/cache/prod/translations/** rw,