Zoeken op website

Implementatie van verplichte toegangscontrole met SELinux of AppArmor in Linux


Om de beperkingen van de standaard ugo/rwx-machtigingen en toegangscontrolelijsten te overwinnen en de beveiligingsmechanismen te vergroten, heeft de United States National Security Agency (NSA) een flexibel Mandatory Access Control (MAC) methode bekend als SELinux (afkorting van Security Enhanced Linux) om onder andere de mogelijkheid van processen om toegang krijgen tot of andere bewerkingen uitvoeren op systeemobjecten (zoals bestanden, mappen, netwerkpoorten, enz.) met zo min mogelijk toestemming, terwijl latere wijzigingen aan dit model nog steeds mogelijk zijn.

Een andere populaire en veelgebruikte MAC is AppArmor, die naast de functies van SELinux een leermodus bevat waarmee het systeem kan “leren ” hoe een specifieke applicatie zich gedraagt, en om limieten in te stellen door profielen te configureren voor veilig applicatiegebruik.

In CentOS 7 is SELinux in de kernel zelf opgenomen en standaard ingeschakeld in de Enforcing modus (meer hierover in de volgende sectie), in tegenstelling tot openSUSE en Ubuntu die AppArmor gebruiken.

In dit artikel leggen we de essentie van SELinux en AppArmor uit en hoe je een van deze tools voor jouw voordeel kunt gebruiken, afhankelijk van de door jou gekozen distributie.

Inleiding tot SELinux en hoe het te gebruiken op CentOS 7

Security Enhanced Linux kan op twee verschillende manieren werken:

  1. Afdwingen: SELinux weigert toegang op basis van SELinux beleidsregels, een set richtlijnen die de beveiligingsengine controleren.
  2. Toegeeflijk: SELinux weigert geen toegang, maar weigeringen worden geregistreerd voor acties die geweigerd zouden zijn als ze in de afdwingende modus zouden draaien.

SELinux kan ook worden uitgeschakeld. Hoewel het op zichzelf geen bedieningsmodus is, is het nog steeds een optie. Het is echter beter om te leren hoe u deze tool kunt gebruiken dan deze gewoon te negeren. Houd het in gedachten!

Om de huidige modus van SELinux weer te geven, gebruik je getenforce. Als u de bedieningsmodus wilt wijzigen, gebruikt u setenforce 0 (om deze in te stellen op Toegeeflijk) of setenforce 1 (Afdwingen sterk>).

Omdat deze verandering een reboot niet zal overleven, zul je het /etc/selinux/config bestand moeten bewerken en de SELINUX variabele op een van beide moeten instellen afdwingen, permissief of uitgeschakeld om persistentie te bereiken bij opnieuw opstarten:

Even terzijde: als getenforce Disabled retourneert, moet je /etc/selinux/config bewerken met de gewenste bedieningsmodus en opnieuw opstarten. Anders kunt u de bedieningsmodus niet instellen (of schakelen) met setenforce.

Eén van de typische toepassingen van setenforce bestaat uit het schakelen tussen SELinux-modi (van afdwingen naar permissief of andersom) om problemen op te lossen met een applicatie die zich misdraagt of niet werkt zoals verwacht. Als het werkt nadat je SELinux in de Permissieve modus hebt gezet, kun je erop vertrouwen dat je te maken hebt met een SELinux-permissieprobleem.

Twee klassieke gevallen waarin we hoogstwaarschijnlijk met SELinux te maken zullen krijgen zijn:

  1. De standaardpoort wijzigen waarop een daemon luistert.
  2. De DocumentRoot richtlijn instellen voor een virtuele host buiten /var/www/html.

Laten we deze twee gevallen eens bekijken aan de hand van de volgende voorbeelden.

VOORBEELD 1: De standaardpoort voor de sshd-daemon wijzigen

Een van de eerste dingen die de meeste systeembeheerders doen om hun servers te beveiligen, is de poort wijzigen waar de SSH-daemon naar luistert, meestal om poortscanners en externe aanvallers te ontmoedigen. Om dit te doen gebruiken we de Port-richtlijn in /etc/ssh/sshd_config gevolgd door het nieuwe poortnummer als volgt (in dit geval gebruiken we poort 9999):


Port 9999

Nadat we hebben geprobeerd de service opnieuw te starten en de status ervan te controleren, zullen we zien dat deze niet kon worden gestart:


systemctl restart sshd
systemctl status sshd

Als we naar /var/log/audit/audit.log kijken, zien we dat sshd niet kon starten op poort 9999 door SELinux omdat dat een gereserveerde poort is voor de JBoss Management service (SELinux logberichten bevatten het woord “AVC” zodat ze gemakkelijk kunnen worden geïdentificeerd uit andere berichten):


cat /var/log/audit/audit.log | grep AVC | tail -1

Op dit punt zouden de meeste mensen waarschijnlijk SELinux uitschakelen, maar wij niet. We zullen zien dat er een manier is waarop SELinux, en sshd die op een andere poort luistert, in harmonie samen kan leven. Zorg ervoor dat je het policycoreutils-python pakket hebt geïnstalleerd en voer het uit:


yum install policycoreutils-python

Om een lijst te bekijken van de poorten waar SELinux sshd toestaat om op te luisteren. In de volgende afbeelding kunnen we ook zien dat poort 9999 gereserveerd was voor een andere dienst en we deze dus voorlopig niet kunnen gebruiken om een andere dienst uit te voeren:


semanage port -l | grep ssh

Natuurlijk kunnen we een andere poort voor SSH kiezen, maar als we er zeker van zijn dat we deze specifieke machine niet voor JBoss-gerelateerde diensten hoeven te gebruiken, kunnen we dan de bestaande SELinux-regel wijzigen en in plaats daarvan die poort aan SSH toewijzen:


semanage port -m -t ssh_port_t -p tcp 9999

Daarna kunnen we het eerste semanage commando gebruiken om te controleren of de poort correct is toegewezen, of de -lC opties (afkorting van list custom):


semanage port -lC
semanage port -l | grep ssh

We kunnen SSH nu opnieuw opstarten en verbinding maken met de service via poort 9999. Merk op dat deze wijziging een herstart ZAL overleven.

VOORBEELD 2: Een DocumentRoot kiezen buiten /var/www/html voor een virtuele host

Als u een virtuele Apache-host moet instellen met een andere map dan /var/www/html als DocumentRoot (bijvoorbeeld /websrv/sites /gabriel/public_html):


DocumentRoot “/websrv/sites/gabriel/public_html”

Apache zal weigeren de inhoud aan te bieden omdat de index.html is gelabeld met het default_t SELinux type, waartoe Apache geen toegang heeft:


wget http://localhost/index.html
ls -lZ /websrv/sites/gabriel/public_html/index.html

Net als bij het vorige voorbeeld kun je het volgende commando gebruiken om te verifiëren dat dit inderdaad een SELinux-gerelateerd probleem is:


cat /var/log/audit/audit.log | grep AVC | tail -1

Om het label van /websrv/sites/gabriel/public_html recursief te veranderen in httpd_sys_content_t, doe je het volgende:


semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"

Het bovenstaande commando geeft Apache alleen-lezen toegang tot die map en de inhoud ervan.

Om het beleid ten slotte toe te passen (en de labelwijziging onmiddellijk van kracht te laten worden), doet u het volgende:


restorecon -R -v /websrv/sites/gabriel/public_html

Nu zou u toegang moeten hebben tot de map:


wget http://localhost/index.html

Voor meer informatie over SELinux, refereer je naar de Fedora 22 SELinux en Administrator handleiding.