Tijdens deze serie hebben we in detail minstens twee toegangscontrole methoden onderzocht: standaard ugo/rwx machtigingen (Beheer Gebruikers en Groepen – Deel 3) en toegangscontrolelijsten (Configureer ACL’s op Bestandssystemen – Deel 7).
Hoewel nodig als eerstelijns machtigingen en toegangscontrolemechanismen, hebben ze enkele beperkingen die worden aangepakt door Security Enhanced Linux (ook wel SELinux genoemd).
Een van dergelijke beperkingen is dat een gebruiker een bestand of map bloot kan stellen aan een beveiligingslek door een slecht uitgewerkte chmod opdracht en daardoor een onverwachte verspreiding van toegangsrechten kan veroorzaken. Als gevolg hiervan kan elk proces gestart door die gebruiker doen wat het wil met de bestanden in eigendom van de gebruiker, waarbij uiteindelijk kwaadaardige of anderszins gecompromitteerde software root-level toegang tot het hele systeem kan krijgen.
Met deze beperkingen in gedachten, heeft de Amerikaanse National Security Agency (NSA) als eerste SELinux bedacht, een flexibele verplichte toegangscontrole methode, om de mogelijkheid van processen om toegang te krijgen tot of andere bewerkingen uit te voeren op systeemobjecten (zoals bestanden, mappen, netwerkpoorten, enz.) te beperken tot het minst machtigingsmodel, dat later indien nodig kan worden gewijzigd. In weinig woorden krijgt elk element van het systeem alleen de toegang die nodig is om te functioneren.
In RHEL 7, SELinux is opgenomen in de kernel zelf en is standaard ingeschakeld in Enforcing-modus. In dit artikel zullen we kort de basisconcepten uitleggen die verband houden met SELinux en de werking ervan.
SELinux Modi
SELinux kan op drie verschillende manieren werken:
- Enforcing: SELinux weigert toegang op basis van SELinux-beleidsregels, een set richtlijnen die de beveiligingsengine controleren.
- Permissive: SELinux weigert geen toegang, maar weigeringen worden gelogd voor acties die zouden zijn geweigerd als ze in afdwingende modus zouden worden uitgevoerd.
- Disabled (zelfverklarend).
De getenforce-opdracht geeft de huidige modus van SELinux weer, terwijl setenforce (gevolgd door een 1 of een 0) wordt gebruikt om de modus te wijzigen naar Enforcing of Permissive, respectievelijk, alleen tijdens de huidige sessie.
Om persistentie te bereiken bij uitloggen en herstarten, moet u het bestand /etc/selinux/config bewerken en de SELINUX-variabele instellen op enforcing, permissive of disabled:
# getenforce # setenforce 0 # getenforce # setenforce 1 # getenforce # cat /etc/selinux/config
Meestal zult u setenforce gebruiken om tussen SELinux-modi te schakelen (van afdwingend naar toegeeflijk en terug) als eerste probleemoplossingsstap. Als SELinux momenteel is ingesteld op enforcing terwijl u een bepaald probleem ervaart, en hetzelfde verdwijnt wanneer u het instelt op permissive, kunt u er zeker van zijn dat u naar een SELinux-machtigingsprobleem kijkt.
SELinux-contexten
A SELinux context consists of an access control environment where decisions are made based on SELinux user, role, and type (and optionally a level):
- A SELinux user complements a regular Linux user account by mapping it to a SELinux user account, which in turn is used in the SELinux context for processes in that session, in order to explicitly define their allowed roles and levels.
- Het concept van rol fungeert als een tussenpersoon tussen domeinen en SELinux-gebruikers, omdat het bepaalt welke procesdomeinen en bestandstypen toegankelijk zijn. Dit zal uw systeem beschermen tegen kwetsbaarheid voor aanvallen op privilege-escalatie.
- A type defines an SELinux file type or an SELinux process domain. Under normal circumstances, processes are prevented from accessing files that other processes use, and and from accessing other processes, thus access is only allowed if a specific SELinux policy rule exists that allows it.
Laten we eens kijken hoe dit allemaal werkt aan de hand van de volgende voorbeelden.
VOORBEELD 1: Het standaardpoort wijzigen voor de sshd-daemon
In Beveiliging van SSH – Deel 8 hebben we uitgelegd dat het wijzigen van de standaardpoort waarop sshd luistert, een van de eerste beveiligingsmaatregelen is om uw server te beschermen tegen externe aanvallen. Laten we het bestand /etc/ssh/sshd_config bewerken en de poort instellen op 9999:
Port 9999
Sla de wijzigingen op en herstart sshd:
# systemctl restart sshd # systemctl status sshd
Zoals je kunt zien, is sshd niet gestart. Maar wat is er gebeurd?
A quick inspection of /var/log/audit/audit.log indicates that sshd has been denied permissions to start on port 9999 (SELinux log messages include the word “AVC” so that they might be easily identified from other messages) because that is a reserved port for the JBoss Management service:
# cat /var/log/audit/audit.log | grep AVC | tail -1
Op dit punt zou je SELinux kunnen uitschakelen (maar doe dat niet!) zoals eerder uitgelegd en opnieuw proberen sshd te starten, en het zou moeten werken. De semanage utility kan ons echter vertellen wat we moeten veranderen om sshd te kunnen starten op welke poort we ook kiezen zonder problemen.
Voer uit,
# semanage port -l | grep ssh
om een lijst te krijgen van de poorten waarop SELinux sshd toestaat om op te luisteren.
Laten we dus de poort in /etc/ssh/sshd_config veranderen naar Poort 9998, voeg de poort toe aan de ssh_port_t-context, en herstart vervolgens de service:
# semanage port -a -t ssh_port_t -p tcp 9998 # systemctl restart sshd # systemctl is-active sshd
Zoals je kunt zien, is de service deze keer succesvol gestart. Dit voorbeeld illustreert het feit dat SELinux de TCP-poortnummer controleert naar zijn eigen poorttype interne definities.
VOORBEELD 2: Toestaan dat httpd toegang heeft tot sendmail
Dit is een voorbeeld van SELinux dat een proces beheert dat toegang heeft tot een ander proces. Als je mod_security en mod_evasive samen met Apache op je RHEL 7 server implementeert, moet je httpd toegang geven tot sendmail om een e-mailmelding te sturen in het geval van een (D)DoS-aanval. In het volgende commando, laat de -P vlag weg als je niet wilt dat de wijziging persistent blijft na herstarten.
# semanage boolean -1 | grep httpd_can_sendmail # setsebool -P httpd_can_sendmail 1 # semanage boolean -1 | grep httpd_can_sendmail
Zoals je kunt zien in het bovenstaande voorbeeld, zijn SELinux-booleans instellingen (of gewoon booleans) ware / valse regels die zijn ingebed in SELinux-beleid. Je kunt alle booleans weergeven met semanage boolean -l, en het eventueel doorsturen naar grep om de uitvoer te filteren.
VOORBEELD 3: Het serveren van een statische site vanuit een andere map dan de standaardmap
Stel dat je een statische website serveert vanuit een andere map dan de standaardmap (/var/www/html), zeg /websites (dit kan het geval zijn als je bijvoorbeeld je webbestanden opslaat op een gedeeld netwerkstation en het moet koppelen aan /websites).
a). Create an index.html file inside /websites with the following contents:
<html> <h2>SELinux test</h2> </html>
Als je dit doet,
# ls -lZ /websites/index.html
Je zult zien dat het bestand index.html is gelabeld met het type default_t SELinux, waar Apache geen toegang toe heeft:
b). Change the DocumentRoot directive in /etc/httpd/conf/httpd.conf to /websites and don’t forget to update the corresponding Directory block. Then, restart Apache.
c). Browse to http://<web server IP address>, and you should get a 503 Forbidden HTTP response.
d). Next, change the label of /websites, recursively, to the httpd_sys_content_t type in order to grant Apache read-only access to that directory and its contents:
# semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"
e). Finally, apply the SELinux policy created in d):
# restorecon -R -v /websites
Herstart nu Apache en ga opnieuw naar http://<webserver IP-adres> en je zult zien dat het html-bestand correct wordt weergegeven:
Samenvatting
In dit artikel hebben we de basisprincipes van SELinux doorgenomen. Merk op dat vanwege de omvang van het onderwerp een gedetailleerde uitleg niet mogelijk is in één artikel, maar we geloven dat de principes die in deze gids worden uiteengezet, je zullen helpen om verder te gaan naar meer geavanceerde onderwerpen als je dat wilt.
Als ik mag, laat me dan twee essentiële bronnen aanbevelen om mee te beginnen: de NSA SELinux-pagina en de RHEL 7 SELinux Gebruikers- en Beheerdershandleiding.
Aarzel niet om ons te laten weten als je vragen of opmerkingen hebt.
Source:
https://www.tecmint.com/selinux-essentials-and-control-filesystem-access/