HollowGamer schreef op zondag 28 mei 2017 @ 17:31:
SELinux voegt niet veel toe in dit verhaal naar mijn mening.
Je kunt hetzelfde bereiken zonder SELinux of met andere tools.
Verder is de /home directory niet bedoeld voor het geen wat @Verwijderd wilt doen.
De /home directory is voor elke aparte aangemaakte gebruiker op het systeem (als je deze meegeeft). Het is niet de bedoeling gewoon maar wat folders toe te voegen onder /home.
Maak gewoon de gebruiker aan met home-directory, zet de juiste permissies, laat de software verwijzen naar /home for user-data, and that's it.
Wil je nog verdere controle en echt gescheiden systeem dan kun je beter gaan kijken naar VM's.
Ik denk dat je toch echt even dieper in de materie van SELinux moet duiken om het volle potentieel te vatten.
Het voegt echt wel een dikke laag toe, mits goed geimplementeerd.
Naast scheiding in losse users, wat trouwens zeker goed is om te doen, legt SELinux er een hele fijne laag bovenop.
Denk je dit in: De Shellshock bug is nog relevant en je kan een webserver hacken door te knoeien met de user-agent-string van je browser.
In dat geval wordt er dus code uitgevoerd uit naam van het de Apache user, vanuit het daemon proces.
Die user heeft rechten op alle websites die draaien op het systeem.
Je kan alle sites in 1 klap exploiten op die manier.
Echter, als SELinux er tussen zit, dan kan dat op eens niet meer, omdat daemons niet mogen schrijven naar directories die zijn aangemerkt als web-content.
Ander voorbeeld: MySQL
CVE-2016-6662. Remote code execution in MySQL (en klonen, zoals Percona en MariaDB) doordat je via een speciale SQL query diverse shared libraries kan muteren (omdat MySQL er toegang toe heeft)
Onder SELinux werkt dat niet, omdat MySQL's daemon proces geen shared libs mag aanpassen van SELinux. Ook niet als root.
Dit zijn twee voorbeelden waarvan bekend is dat systemen die SELinux draaien, niet vatbaar waren voor deze exploits.
Dus ja, voegt het wat toe? absoluut!
Juist bij systemen die constant requests van buiten moeten verwerken, is het een prachtig systeem om rechten verder in te perken tot het strict noodzakelijke.
Er kleven uiteraard ook nadelen aan. Stel dat je een CMS hebt staan die via een web-portal plaatjes in een Media directory wil plaatsen.
Dat werkt dan ook niet out-of-the-box met SELinux. Dan zal je de Media directory moeten taggen als schrijfbaar voor daemonprocessen die in de categorie 'webserver en aanverwanten' thuis horen (en daar vallen dan diverse webservers en scriptparsers onder, maar niks anders)
Edit:
Nog een ander voorbeeld, waar ik zo geen bestaande exploit bij weet, maar die opzich prima zou kunnen:
Stel, je systeem raakt geinfecteerd met een of ander stuk botnet malware.
Die malware kan dankzij SELinux niet naar buiten communiceren omdat hij (de malware) een onbekend proces is en dus geen TCP poort mag claimen.
Dat is ook één van de features van SELinux. Beheer van poortnummers. By default kan je b.v. ook niet Apache (of andere webservers) draaien op andere poorten dan 80, 443 en 8080, tenzij je dat expliciet zelf zo instelt in de SELinux configuratie.
Nadeel is dus wel dat je daar extra werk aan hebt om in te stellen. Voordeel is dat je hele stricte controle er over hebt en er minder ruimte is voor hacks/exploits.
De nadelen is ook waarom SELinux best wel een bitch kan zijn.
Het instellen er van is niet altijd even straight-forward, en het debuggen als iets niet zo gaat als je dat wil/verwacht, is ook niet altijd even simpel.
Gelukkig bestaat er inmiddels aardige tooling, zoals Audit2Allow. Daarmee kan je isoleren wat er mis gaat en op basis van wat er gelogd is over wat er mis ging, kunnen er nieuwe rules worden gemaakt. Dat kan tegenwoordig redelijk automatisch voor je worden gedaan.
Verdient alleen wel even wat tijd om je in te lezen in hoe die tooling precies werkt en hoe je het toepast.
Veel mensen gooien de handdoek in de ring omdat er gewoon nog veel te weinig goede stukken uitleg zijn. En dat terwijl het inmiddels al zo'n 15jaar bestaat en het kernel-side gedeelte al 10 jaar by default in de Linux kernel zit.
Ik weet dat er op Pluralsight een videoserie over staat die vrij goed uitlegt hoe het werkt.
Als ze weer eens een X dagen gratis periode hebben, loont het zeker om die videoset eens op te zoeken en te bekijken (is ongeveer 2 uur lang)
Blokker_1999 schreef op zondag 28 mei 2017 @ 19:20:
Volgens de geldende afspraken is /home bedoeld voor persoonlijke bestanden van een gebruiker. De data waar de webserver aan dient te kunnen hoort daar in de basis niet onder te staan. Deze wordt meestal onder /var geplaatst. Daarom ook dat Debian per default naar /var/www zal gaan voor websites (ongeacht welke webserver je installeert).
Als je schrik hebt voor hacking dan wordt security al snel een stuk complexer en hangt veel af van welke scriptingtalen je gebruikt en hoe geautomatiseerd je je configuratie wenst te laten verlopen. 1 van de sites (met vele subsites) die ik host heeft bijvoorbeeld elke subsite in een aparte VM draaien en aan de publieke kant 1 gateway die gewoon alle verkeer doorstuurd naar de correcte VM. Veel beter dan dat kan je sites niet isoleren. Je zou het ook zonder VMs kunnen doen door elke site zijn eigen webserver te geven, maar als er dan een exploit met privilege escalation komt heb je alsnog dat een hacker aan alle data op de server kan (tenzij je weer kan gaan chrooten en er weer geen manier bestaat om daar uit te breken). Maw: wat wil je exact bereiken/voorkomen en hoeveel tijd wil je er in steken?
Wat betreft de mappen, klopt. Maar in de praktijk boeit het opzich niet zo veel welke route je kiest.
Volgens conventie zet je de website alleen in de home-dir als het gaat om individuele users die hun eigen website willen hebben.
B.v. voor Shared Hosting platformen of de webspace die je vroeger bij je internet provider kreeg (
www.provider.nl/~jmetdekorteachternaam/index.html enzo).
Opzich combineert dat natuurlijk wel prima met het idee om sites te scheiden in apparte users.
Je moet je users dan uiteraard wel aanmaken met een eigen home-dir, maar dat is standaard.
En dan geef je ze geen login shell, zodat je niet op die users kan inloggen via SSH b.v.
En leg je daar dan ook nog SELinux bovenop, dan kan een ge-exploite website niet aan de non-website bestanden komen (dus de ruimte binnen home/user maar buiten home/user/publichtml)
De VM oplossing is opzich ook wel een goeie om dingen in afgescheiden containers te zetten.
Afhankelijk van de oplossing die je kiest, kan dat wel wat grotere systeem overhead eisen.
Maargoed, er is inmiddels ook al een tijd een lichtere variant onder de naam Docker.
Lullige aan Docker is alleen dat databases worden gewiped op het moment dat je je docker container restart. Dus dan is een database driven website weer onhandig. Of je moet de database direct op je host draaien, los van de docker containers.
[
Voor 56% gewijzigd door
McKaamos op 28-05-2017 22:07
]
/u/644454/crop55c1ad5e79c27_cropped.png?f=community)
:strip_icc():strip_exif()/u/50085/reaperavatar.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/289675/crop6401bf2c85501_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/78725/train-icon3.jpg?f=community)
:strip_exif()/u/160115/small.gif?f=community)