CageFS in de dagelijkse hostingpraktijk: isolatie van bestandssystemen tussen klantaccounts

Waarom hostingaccounts isolatie nodig hebben

Bij shared hosting hosten meerdere klanten hun websites op dezelfde server. Als een script in account A wordt gehackt, kan het proberen informatie over de omgeving te verzamelen en toegang te krijgen tot bestanden van andere accounts. Hieronder kunnen configuratiebestanden met inloggegevens of persoonlijke gegevens vallen. De scheiding tussen de accounts is bedoeld om dergelijke toegang te bemoeilijken, ook al wordt de infrastructuur gezamenlijk gebruikt.

Daarbij zijn Zichtbaarheid en toegangsrechten verschillende kwesties. Een mapnaam kan zichtbaar zijn, ook al wordt het lezen van de inhoud ervan door bestandsrechten geweigerd. Omgekeerd volstaat een beperkte weergave op zich niet als vervanging voor zorgvuldig ingestelde rechten: wat binnen de omgeving toegankelijk is, moet nog steeds op passende wijze worden beveiligd.

CageFS voegt aan de rechten een gebruikersspecifieke bestandssysteemomgeving toe. Een proces in de beoogde context krijgt niet zomaar hetzelfde overzicht van de host als een beheerder. Dit is bedoeld om te voorkomen dat een script vanuit account A zomaar de mappen van andere accounts kan verkennen. Welke gebieden daadwerkelijk zichtbaar zijn, hangt af van de configuratie.

Voor exploitanten is dit een extra Scheidingslaag, geen garantie dat er geen gevolgen zijn voor andere klanten. Fouten in gedeelde diensten, te ruime machtigingen of een onvolledige integratie van diensten kunnen de beschermende werking beïnvloeden. Daarom moet de isolatie worden gecontroleerd op de plek waar de programma’s van klanten daadwerkelijk worden uitgevoerd, en niet alleen aan de hand van een instelling in het beheerpaneel.

Ook voor hostingklanten is dit onderscheid belangrijk: het feit dat een eigen applicatie geen externe mappen ziet, zegt in eerste instantie alleen iets over de specifieke uitvoeringscontext ervan. Het zegt niets over de configuratie van alle diensten, noch over de beveiliging van alle andere accounts. De provider blijft verantwoordelijk voor de algemene inrichting en controle.

Hoe CageFS de weergave van het bestandssysteem vormgeeft

CageFS biedt gebruikers een eigen weergave van het bestandssysteem. De basis hiervoor is het Skelet: een sjabloon met bestanden en mappen die voor de betreffende omgeving beschikbaar worden gesteld. De benodigde onderdelen worden geïntegreerd; ook de eigen thuismap van de gebruiker wordt in diens omgeving geïntegreerd. De zichtbare mappenstructuur is dus niet zomaar een ongewijzigde kopie van de hostweergave.

De integratie kan worden geïllustreerd aan de hand van een voorbeeld: een beheerder installeert een programma op de host, maar een klantproces kan het niet vinden in zijn omgeving. Dit is niet automatisch een installatiefout. Het programma kan op de host aanwezig zijn zonder dat het in het skelet of via de daarvoor bestemde integraties beschikbaar is voor de klant.

Omgekeerd breidt elk extra beschikbaar gesteld bestand de omgeving uit die een proces kan zien. Hetzelfde geldt voor een gekoppelde map. Beheerders moeten daarom de functionele behoeften afwegen tegen de extra zichtbaarheid: een toepassing heeft mogelijk een bepaald hulpprogramma en de bijbehorende afhankelijkheden nodig, maar niet per se een hele map van de host.

De Mount-configuratie bepaalt mede welke onderdelen van het bestandssysteem in de omgeving worden weergegeven. Het bepaalt echter niet op zichzelf of een proces een zichtbaar bestand mag lezen, wijzigen of uitvoeren. Daarvoor blijven onder andere eigendom en machtigingen van belang. Een zichtbaar pad is dus niet hetzelfde als toegestane schrijftoegang.

De eigen thuismap blijft van groot belang voor het dagelijkse gebruik van de hosting: daar bevinden zich doorgaans de bestanden van de betreffende account. Door deze integratie is toegang mogelijk binnen de beoogde context, terwijl de rest van de weergave wordt beperkt. Of een specifieke toepassing alle benodigde bestanden kan bereiken, hangt echter af van de configuratie ervan en de daadwerkelijk beschikbare paden.

CageFS, LVE en gemeenschappelijke risico's

CageFS en LVE bieden een oplossing voor verschillende problemen. CageFS bepaalt het bestandssysteembeeld en de uitvoeringscontext van een gebruiker; LVE dient voor het registreren en beperken van bronnen zoals CPU, geheugen en invoer en uitvoer. Een proces met een beperkt zicht op het bestandssysteem kan nog steeds bronnen verbruiken. Omgekeerd voorkomt een bronlimiet op zichzelf geen toegang tot ten onrechte vrijgegeven bestanden.

Een hosting-controlepaneel vervult nog een andere taak: het beheert onder andere accounts en kan CloudLinux-componenten integreren. Uit de loutere installatie van een paneel volgt echter niet dat elk webproces, elke shell en elke geplande taak in de daarvoor bestemde CageFS-context draait. Beheerders moeten controleren of de integratie geschikt is voor hun specifieke platform.

CageFS is geen afzonderlijke virtuele machine voor elk account. De accounts blijven gebruikmaken van een gemeenschappelijke kernel en kunnen afhankelijk zijn van gezamenlijk beheerde diensten. Een kwetsbaarheid of verkeerde configuratie in deze gezamenlijke componenten blijft daarom deel uitmaken van het dreigingsmodel. De isolatie van het bestandssysteem beperkt een deel van de zichtbare omgeving, maar is geen vervanging voor de beveiliging en het onderhoud van de host.

Zelfs binnen een correct geïsoleerde account blijven er risico’s bestaan. Een kwetsbare toepassing kan bijvoorbeeld haar eigen gegevens prijsgeven; gestolen inloggegevens kunnen een aanvaller toegang verschaffen tot het betreffende account. CageFS corrigeert noch onveilige applicatiecode, noch te ruime rechten op bestanden die binnen dit account toegankelijk zijn.

Voor een robuuste beveiligingsstrategie moeten de lagen daarom op elkaar aansluiten: accounts en diensten correct integreren, bestandsrechten controleren, de juiste limieten voor bronnen instellen en applicaties up-to-date houden. Welke beschermende werking hieruit voortvloeit, hangt af van de daadwerkelijke configuratie en de diensten die worden uitgevoerd. De naam van een afzonderlijke component is geen vervanging voor deze controle.

Rekeningen en websites apart bekijken

Twee klantaccounts op dezelfde server is iets anders dan twee websites binnen één account. CageFS biedt een gebruikersspecifieke omgeving en beperkt zo het zicht van een account op het bestandssysteem. Daaruit volgt echter niet dat elke website binnen dit account een eigen bestandssysteemgrens krijgt.

Als een bureau meerdere projecten onder hetzelfde hostingaccount beheert, kunnen de applicaties daarvan, afhankelijk van de uitvoeringscontext en de machtigingen, toegang krijgen tot bestanden van andere projecten. Als een aanvaller via een kwetsbare plug-in toegang krijgt tot een website, moet daarom worden gecontroleerd welke configuratiebestanden en toegangsgegevens onder dit account bereikbaar zijn. Het feit dat er een scheiding is met een tweede klantenaccount biedt hierop geen antwoord.

Voor een fijnere Scheiding van websites CloudLinux documenteert met CloudLinux Isolates een extra domeinspecifieke isolatie van het bestandssysteem. Of deze bruikbaar is, hangt af van de concrete productbeschikbaarheid, versie en paneelintegratie. Controleer deze vereisten voor je eigen hostingstack, in plaats van alleen op basis van de activering van CageFS te concluderen dat er een scheiding tussen de domeinen is.

Ook domeingebonden LVE-limieten vormen een afzonderlijke functie met eigen voorwaarden. Een extra limiet op het bestandssysteem betekent daarom niet automatisch dat de CPU of het geheugen voor elk domein afzonderlijk worden beperkt. Het artikel over CloudLinux-site-isolatie benadrukt het verschil tussen het accountniveau en het websiteniveau; voor de configuratie blijven de vereisten van de gebruikte productvariant doorslaggevend.

Voor de planning is het de moeite waard om eerst een inventarisatie te maken: welke sites delen één account, welke bestanden moeten ze gezamenlijk gebruiken en welke toegangsgegevens moeten gescheiden blijven? Hieruit kan worden afgeleid of afzonderlijke accounts of een beschikbare domeinspecifieke isolatie bij het bedrijfsmodel passen. Beide varianten vereisen een controle van de daadwerkelijke gebruikspaden.

Controleer de status van Pilot en CageFS

Voorafgaand aan een pilot controleer je als beheerder of de gebruikte variant van het besturingssysteem wordt ondersteund, of de benodigde pakketten en de licentie aanwezig zijn en of het configuratiescherm correct is geïntegreerd. Het feit dat ondersteuning voor een configuratiescherm is gedocumenteerd, betekent niet dat elke functie in elke combinatie op dezelfde manier werkt. Noteer ook welke applicaties en tools de geselecteerde testaccounts nodig hebben.

Begin met uitdrukkelijk goedgekeurde testaccounts en een overzichtelijke selectie van typische toepassingen. Controleer hun thuismappen, benodigde programma’s en relevante uitvoeringspaden voordat je verdere accounts toevoegt. Voor de invoering kun je de modus gebruiken waarin CageFS standaard is uitgeschakeld en afzonderlijke accounts worden geactiveerd; als alternatief is er een modus waarin CageFS standaard is ingeschakeld, met uitzonderingen.

De volgende leesopdrachten zijn bedoeld voor bevoegde beheerders op een systeem waarop CageFS is geïnstalleerd. TESTBENUTZER vervang je door een bestaand account dat is vrijgegeven voor de test. De vereiste rechten en de concrete uitvoer zijn afhankelijk van het systeem; de commando’s wijzigen de configuratie niet.

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --display-user-mode
/usr/sbin/cagefsctl --user-status TESTBENUTZER

Het eerste commando geeft de algemene CageFS-status weer, het tweede de Bedrijfsmodus. De derde vraagt de status van de geselecteerde rekening op. De modus en de rekeningstatus moeten in samenhang worden bekeken: een modus die standaard is geactiveerd, kan uitzonderingen bevatten, terwijl in de andere modus afzonderlijke rekeningen uitdrukkelijk worden opgenomen.

Een positieve statusmelding is nog geen bewijs dat elke dienst daadwerkelijk in de beoogde context draait. Leg daarom apart vast wat de administratie meldt en welke uitvoeringspaden met het testaccount zijn gecontroleerd. Pas daarna kan worden besloten of de pilot kan worden uitgebreid naar andere accounts en welke uitzonderingen operationeel noodzakelijk zijn.

Vergelijking van beschermingsbenaderingen

De benaderingen verschillen vooral in de vraag welke grens ze trekken en wie deze beheert. In de tabel worden de beveiligingsdoelstellingen ingedeeld; de gegevens over de exploitatiekosten zijn kwalitatieve richtlijnen voor de planning, geen gemeten waarden. Concrete eisen zijn afhankelijk van het betreffende platform en de configuratie daarvan.

Bestandsrechten en een beperkt zicht zijn geen onderling uitwisselbare begrippen: zelfs een zichtbaar pad hoeft niet leesbaar te zijn, en een beschikbaar gesteld pad moet op de juiste wijze worden beveiligd. CageFS vult deze rechten aan met een gestructureerde omgeving. LVE richt zich daarentegen op het verbruik van systeembronnen; voor gezamenlijk gebruik moeten beide lagen op de juiste manier worden geconfigureerd.

A eigen VM verschuift de beheersgrens ten opzichte van een gebruikersspecifieke omgeving: het gastsysteem moet zelf worden onderhouden en blijft afhankelijk van het virtualisatieplatform. Een aparte server verandert de gedeelde infrastructuur nogmaals. Welke variant geschikt is, hangt af van het dreigingsmodel, de benodigde rechten en de beschikbare bedrijfsmiddelen.

Een algemene veiligheidsranglijst zou daarom misleidend zijn. Voor een vergelijking van andere mechanismen en hun respectieve toepassingsgebieden biedt het overzicht van de Procesisolatie bij hosting. Vervolgens is de concrete toetsing van cruciaal belang: welke grens moet welke toegang verhinderen, welke diensten overschrijden deze grens en wie houdt toezicht op de configuratie?

Uitvoeringspaden gecontroleerd testen

Het feit dat een account is geactiveerd, betekent nog niet dat elk bijbehorend proces ook daadwerkelijk in CageFS wordt gestart. Doorslaggevend is de betreffende Uitvoeringspad: SSH-aanmelding, webservers en geplande taken kunnen gebruikmaken van verschillende integraties. Beheerders moeten daarom voor elke relevante dienst nagaan hoe deze processen aan het account en de bijbehorende omgeving toewijst.

Voor een gecontroleerde test richt de beheerder een geautoriseerd testaccount in en gebruikt uitsluitend eigen, uitdrukkelijk goedgekeurde testbestanden. Een bestand binnen de daarvoor bestemde omgeving kan aantonen of de verwachte toegang werkt; een afzonderlijk voorbereid bestand buiten het daarvoor bestemde bereik dient om de afbakening te controleren. Externe klantmappen zijn hiervoor geen geschikt testmateriaal.

Controleer eerst via SSH welke omgeving het testaccount daadwerkelijk krijgt en of de beoogde testbestanden zoals verwacht toegankelijk zijn. Herhaal de controle met een daarvoor geconfigureerde webapplicatie en een geplande taak. De resultaten kunnen verschillen als diensten anders zijn geïntegreerd of onder een andere gebruikerscontext draaien.

Noteer voor elke poging de dienst, het account, het pad en het resultaat. Een geweigerde toegang bewijst alleen de waargenomen beperking in precies deze context; het bewijst noch de correcte isolatie van alle diensten, noch de veiligheid van de gehele host. Omgekeerd moet een onverwacht succesvolle toegang worden onderzocht voordat er meer accounts in gebruik worden genomen.

Als hostingklant kun je je eigen uitvoeringscontext en gedeelde bestanden controleren. Globale CageFS-instellingen, andere accounts en de integratie van alle diensten kun je normaal gesproken niet zelfstandig controleren. De beheerder is verantwoordelijk voor deze zaken; geef bij afwijkingen de betreffende dienst en het exacte pad aan.

Ontbrekende tools en onderhoud van Skeleton

Als een tool op de host is geïnstalleerd, maar niet in het klantaccount te vinden is, controleer dan eerst de uitvoeringscontext. Een aanroep via SSH hoeft niet dezelfde omgeving te gebruiken als een webapplicatie of een geplande taak. Controleer vervolgens het zoekpad en de specifieke foutmelding voordat je ervan uitgaat dat er een pakket ontbreekt.

Vervolgens onderzoekt de exploitant het Skelet en de mount-configuratie. Het skeleton bepaalt mede welke bestanden en mappen in CageFS beschikbaar worden gesteld. Een programma kan dus op de host aanwezig zijn en toch ontbreken in de gebruikersspecifieke omgeving; ook moet bij het beschikbaar stellen rekening worden gehouden met benodigde bibliotheken en andere afhankelijkheden.

De praktische oplossing is niet om uit voorzorg grote hostmappen te koppelen. Hierdoor zouden mogelijk meer bestanden zichtbaar worden dan voor de taak nodig is. De beheerder moet in plaats daarvan aan de hand van de documentatie van de fabrikant de benodigde programmabestanden en afhankelijkheden selecteren en vervolgens in de daarvoor bestemde servicecontext controleren of de tool werkt.

Naar Onderhoud van het skelet Daarbij hoort ook dat rekening moet worden gehouden met wijzigingen in systeempakketten en in het configuratiescherm. CloudLinux vermeldt dat er periodiek een update plaatsvindt; na bepaalde wijzigingen kan een geforceerde update nodig zijn. Ook na het opnieuw opbouwen van Apache kan dit nodig zijn. Dit betekent echter niet dat na elke update dezelfde handmatige opdracht moet worden uitgevoerd.

Plan de update afgestemd op het gebruikte platform en controleer daarna de betrokken applicaties en tools. Als een applicatie eerder werkte en na een wijziging niet meer functioneert, helpen het tijdstip van de pakketwijziging, de betrokken dienst en de exacte foutmelding bij het opsporen van de oorzaak. Zo kan onderscheid worden gemaakt tussen een implementatieprobleem en een fout in de applicatie.

Veilig werken en weloverwogen beslissingen nemen

Bij de bedrijfsbeslissing gaat het niet alleen om de vraag of CageFS in principe beschikbaar is. De beheerder moet weten welke accounts en diensten moeten worden beveiligd, welke programma’s daarvoor nodig zijn en wie verantwoordelijk is voor de integratie en het onderhoud. Het beperkte zicht op het bestandssysteem vormt een aanvulling op andere beveiligingsmaatregelen; het is geen vervanging voor veilige applicaties of voor de beveiliging van inloggegevens.

Bijzondere aandacht verdienen gemeenschappelijke ruimtes en extra mounts. CloudLinux beschrijft voor /dev/shm een gezamenlijke integratie en een mogelijkheid tot isolatie per gebruiker. Welke variant daadwerkelijk van toepassing is, moet aan de hand van de concrete configuratie worden gecontroleerd. Extra mounts mogen alleen datgene beschikbaar stellen wat applicaties nodig hebben, omdat ze de zichtbare omgeving kunnen uitbreiden.

Ook een fout bij het opstarten van CageFS is van belang voor de veiligheid. CloudLinux beschrijft vanaf CageFS 7.2.0-1 een optie waarmee de uitvoering van processen bij een dergelijke fout kan worden voorkomen. Controleer de geïnstalleerde versie en de daadwerkelijke instelling, in plaats van op basis van het bestaan van deze optie conclusies te trekken over het gedrag ervan bij een specifiek hostingaanbod.

Wijzigingen aan Skeleton, mounts of accounttoewijzingen horen thuis in een afgestemd Onderhoudsprocedure. Houd daarbij rekening met mogelijke herkoppelingen, de betrokken applicaties en een onderhoudsvenster; documenteer bovendien hoe de wijziging bij problemen ongedaan kan worden gemaakt. Vervolgens moeten de relevante uitvoeringspaden en benodigde tools opnieuw worden gecontroleerd met de daarvoor bestemde testaccounts.

Voor klanten is de cruciale vraag welke afscherming de aanbieder daadwerkelijk hanteert en hoe hij deze controleert. Exploitanten moeten daarentegen de behoefte aan bescherming en de daarmee gepaard gaande inspanningen in onderling verband bekijken: een te ruim opgezet milieu kan de afbakening verzwakken, terwijl een te beperkt milieu de benodigde toepassingen kan belemmeren. Beide vereisen een weloverwogen configuratie en regelmatige controle.