Dzisiaj na kilku stronach działających na WordPressie wdrażaliśmy pewną wtyczkę. Niby nic nadzwyczajnego, ale wtyczka ta nie pochodzi(ła) z np. z repozytorium WordPress.org, a bezpośrednio z serwisu GitHub. Tym samym jej aktualizację trzeba było oprzeć nie o standardowe mechanizmy aktualizacji WordPressa, ale o mechanizmy Gita. A, że strony te działały na jednym serwerze, to, zamiast multiplikować kod wtyczki (i tym samym procedurę aktualizacji) postanowiłem skorzystać z linków symbolicznych.

Polecenie chattr (change attribute) w systemie Linux

I nie byłoby w tym nic dziwnego, gdyby nie to, że jest to (pozornie) sprzeczne z bezpieczeństwem stron znajdujących się na tym serwerze. Strony wprawdzie działają na jednym serwerze, ale są od siebie izolowane za pomocą kilku mechanizmów, takich jak PHP Pools, czy „open_basedir” (tak, katalog z plikami wtyczki jest wskazany jako dozwolony).

A w opisywanym przypadku – współdzielone pliki wtyczki – teoretycznie skuteczny atak na jedną stronę mógłby oznaczać skuteczny atak na pozostałe strony, które korzystają ze współdzielonej wtyczki (teoretycznie, bo jest jeszcze PHP Pools, ale to nie uchroni przed wszystkimi operacjami).

I tutaj z pomocą przychodzi polecenie chattr (change attribute), które powinno być dostępne w większości (porządnych) dystrybucji Linuksa (w razie co można doinstalować), a które pozwala w prosty sposób zabezpieczyć pliki/katalogi przed ich (nieuprawnioną) modyfikacją.

Załóżmy, że nasza współdzielona wtyczka (za pomocą linków symbolicznych) znajduje się w katalogu:

/var/www/biblioteka/wtyczka-z-githuba

W tym momencie, by zablokować możliwość wykonywania zmian w tym katalogu, wystarczy skorzystać z polecenia:

sudo chattr -R +i /var/www/biblioteka/wtyczka-z-githuba

By odblokować katalog, tak by można było dokonywać modyfikacji, korzystamy z polecenia:

sudo chattr -R -i /var/www/biblioteka/wtyczka-z-githuba

Teoretycznie jest to dodatkowe utrudnienie, bo przed np. aktualizacją plików wtyczki przy pomocy Git trzeba odbezpieczyć katalog, a po aktualizacji wypadałoby go ponownie zabezpieczyć. Jest to jednak utrudnienie chyba tylko teoretyczne, bo zakładam, że większość osób korzystających z Gita/GitHuba (itp.) raczej proces aktualizacji plików w taki czy inny sposób sobie automatyzuje, np. za pomocą skryptu. Wtedy wystarczy dopisać odpowiednie linijki do tego skryptu.