CageFS i den daglige hostingdrift: Isolering af filsystemer mellem kundekonti

Hvorfor hostingkonti har brug for isolation

Ved shared hosting kører flere kunder deres hjemmesider på den samme server. Hvis et script på konto A bliver kompromitteret, kan det forsøge at indsamle oplysninger om miljøet og få adgang til filer på andre konti. Dette kan omfatte konfigurationsfiler med adgangsoplysninger eller personlige data. Adskillelsen af kontiene skal gøre sådanne adgangsforsøg vanskeligere, selvom infrastrukturen deles.

Her er Synlighed og adgangsrettigheder Forskellige spørgsmål. Et mappenavn kan være synligt, selvom adgangen til at læse dets indhold er blokeret af filrettigheder. Omvendt er en begrænset visning alene ikke tilstrækkelig som erstatning for omhyggeligt indstillede rettigheder: Det, der er tilgængeligt i miljøet, skal fortsat beskyttes på passende vis.

CageFS udvider rettighederne med et brugerspecifikt filsystemmiljø. En proces i den påtænkte kontekst får ikke blot samme overblik over værten som en administrator. Dette skal forhindre, at et script fra konto A uden videre kan udforske andre kontos mapper. Hvilke områder der rent faktisk er synlige, afhænger af opsætningen.

For operatørerne er dette en yderligere Adskillelseslag, ingen garanti mod eventuelle konsekvenser for andre kunder. Fejl i fælles tjenester, for vidtgående tilladelser eller en ufuldstændig tjenesteintegration kan påvirke beskyttelseseffekten. Derfor skal isoleringen kontrolleres dér, hvor kundeprogrammerne rent faktisk kører, og ikke blot på baggrund af en indstilling i administrationsområdet.

For hostingkunder er denne skelnen ligeledes vigtig: At en egen applikation ikke kan se et eksternt bibliotek, beskriver i første omgang blot dens konkrete kørselskontekst. Det beviser hverken konfigurationen af alle tjenester eller beskyttelsen af alle andre konti. Udbyderen er fortsat ansvarlig for den overordnede opsætning og kontrol.

Hvordan CageFS udformer filsystemets visning

CageFS giver brugerne deres eget overblik over filsystemet. Grundlaget er Skelet: en skabelon med filer og mapper, der stilles til rådighed for det pågældende miljø. De nødvendige dele indlæses; også brugerens egen hjemmemappe integreres i brugerens miljø. Den synlige mappestruktur er således ikke blot en uændret kopi af værtsvisningen.

Integrationen kan illustreres ved hjælp af et værktøj: En administrator installerer et program på værten, men en kundeproces kan ikke finde det i sit miljø. Det er ikke nødvendigvis en installationsfejl. Programmet kan findes på værten uden at være tilgængeligt i Skeleton eller via de integrationer, der er beregnet til kunden.

Omvendt udvider hver ekstra fil, der stilles til rådighed, det miljø, som en proces har adgang til. Det samme gælder for et indlæst katalog. Administratorer skal derfor afveje funktionsbehovet mod den ekstra synlighed: Et program har muligvis brug for et bestemt værktøj og dets afhængigheder, men ikke nødvendigvis en hel mappe på værten.

Die Mount-konfiguration bestemmer, hvilke dele af filsystemet der vises i miljøet. Den afgør dog ikke alene, om en proces må læse, ændre eller køre en synlig fil. Her spiller blandt andet ejerskab og rettigheder stadig en rolle. En synlig sti er altså ikke det samme som tilladt skriveadgang.

Den egne hjemmemappe er stadig særlig vigtig i den daglige drift af hosting: Det er typisk her, filerne til den pågældende konto ligger. Integrationen muliggør adgang i den tilsigtede sammenhæng, mens den øvrige visning begrænses. Om et konkret program kan nå alle de nødvendige filer, afhænger dog af dets opsætning og de faktisk tilgængelige stier.

CageFS, LVE og fælles risici

CageFS og LVE løser forskellige problemer. CageFS strukturerer en brugers filsystemvisning og eksekveringskontekst; LVE bruges til at overvåge og begrænse ressourcer som CPU, hukommelse samt ind- og udlæsning. En proces med begrænset adgang til filsystemet kan stadig kræve ressourcer. Omvendt forhindrer en ressourcebegrænsning i sig selv ikke adgang til filer, der er blevet frigivet forkert.

Et hosting-kontrolpanel har endnu en funktion: Det administrerer blandt andet konti og kan integrere CloudLinux-komponenter. Det er dog ikke nok blot at installere et panel for at sikre, at hver eneste webproces, hver eneste shell og hver eneste planlagte opgave kører i den tilsigtede CageFS-kontekst. Operatører skal kontrollere, at integrationen passer til deres konkrete platform.

CageFS er ikke en separat virtuel maskine for hver enkelt konto. Kontiene bruger fortsat en fælles kerne og kan være afhængige af fælles tjenester. En sårbarhed eller forkert konfiguration i disse fælles komponenter er derfor fortsat en del af trusselsmodellen. Filsystemisoleringen begrænser en del af det synlige miljø, men erstatter ikke sikringen og vedligeholdelsen af værten.

Selv inden for en korrekt isoleret konto er der stadig risici. En sårbar applikation kan for eksempel afsløre sine egne data; stjålne adgangsoplysninger kan give en angriber adgang inden for rammerne af den pågældende konto. CageFS korrigerer hverken usikker applikationskode eller for generøse rettigheder til filer, der er tilgængelige inden for denne konto.

For at opnå en robust sikkerhedsstrategi skal de forskellige lag derfor passe sammen: Konti og tjenester skal integreres korrekt, filrettigheder skal kontrolleres, ressourcebegrænsninger skal vælges passende, og applikationer skal holdes opdaterede. Den beskyttende effekt, der opnås herved, afhænger af den faktiske konfiguration og de tjenester, der kører. Navnet på en enkelt komponent kan ikke erstatte denne kontrol.

Betragt konti og hjemmesider hver for sig

To kundekonti på samme server er noget andet end to hjemmesider inden for én konto. CageFS stiller et brugerspecifikt miljø til rådighed og begrænser dermed en kontos adgang til filsystemet. Det betyder dog ikke, at hver hjemmeside inden for denne konto får sin egen filsystemgrænse.

Hvis et bureau driver flere projekter under den samme hostingkonto, kan deres applikationer, afhængigt af kørselskonteksten og rettighederne, få adgang til filer fra andre projekter. Hvis en hacker via et sårbart plugin får adgang til et websted, skal man derfor undersøge, hvilke konfigurationsfiler og adgangsdata der er tilgængelige under denne konto. Adskillelsen fra en anden kundekonto besvarer ikke dette spørgsmål.

For en mere fin Adskillelse af hjemmesider CloudLinux dokumenterer med CloudLinux Isolates en yderligere domænespecifik filsystemisolering. Om denne funktion kan benyttes, afhænger af den konkrete produkttilgængelighed, version og panelintegration. Tjek disse forudsætninger for din egen hosting-stack, i stedet for udelukkende at konkludere, at der er tale om en adskillelse af domænerne, blot fordi CageFS er aktiveret.

Domænerelaterede LVE-grænser er også en separat funktion med egne forudsætninger. En yderligere filsystemgrænse betyder derfor ikke automatisk, at CPU eller hukommelse er begrænset separat for hvert domæne. Artiklen om CloudLinux-webstedsisolering uddyber forskellen mellem konto- og webstedsniveau; det er fortsat den anvendte produktvariants krav, der er afgørende for opsætningen.

I forbindelse med planlægningen er det en god idé at starte med at lave en statusopgørelse: Hvilke websteder deler en konto, hvilke filer skal de dele, og hvilke adgangsoplysninger skal holdes adskilt? Ud fra dette kan man afgøre, om separate konti eller en tilgængelig domænebaseret isolering passer til driftsmodellen. Begge varianter kræver en gennemgang af de faktiske anvendelsesforløb.

Kontroller pilot- og CageFS-status

Inden en pilotfase skal du som operatør kontrollere, om den anvendte version af operativsystemet understøttes, om de nødvendige pakker og licensen er til stede, og om kontrolpanelet er integreret korrekt. At et kontrolpanel er dokumenteret som understøttet, betyder ikke, at alle funktioner fungerer på samme måde i alle kombinationer. Notér også, hvilke applikationer og værktøjer de udvalgte testkonti har brug for.

Start med udtrykkeligt godkendte testkonti og et overskueligt udvalg af typiske applikationer. Kontroller deres hjemmemapper, nødvendige programmer og relevante eksekveringsstier, inden du opretter yderligere konti. Til indkøringen kan du benytte den tilstand, hvor CageFS som udgangspunkt er deaktiveret, og hvor enkelte konti aktiveres; alternativt findes der en tilstand, hvor CageFS som udgangspunkt er aktiveret med undtagelser.

Følgende læsekommandoer er beregnet til autoriserede administratorer på et system, hvor CageFS er installeret. TESTBENUTZER Du erstatter med en eksisterende konto, der er godkendt til testen. De nødvendige rettigheder og den konkrete udførelse afhænger af systemet; kommandoerne ændrer ikke konfigurationen.

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

Den første kommando viser den globale CageFS-status, den anden viser Driftsmodus. Den tredje henter status for den valgte konto. Driftstilstand og kontostatus skal betragtes i sammenhæng: En driftstilstand, der som udgangspunkt er aktiveret, kan have undtagelser, mens der i den anden driftstilstand udtrykkeligt medtages enkelte konti.

En positiv statusmeddelelse er ikke i sig selv et bevis på, at hver enkelt tjeneste rent faktisk kører i den tilsigtede sammenhæng. Dokumenter derfor separat, hvad administrationssystemet rapporterer, og hvilke udførelsesspor der er blevet kontrolleret med testkontoen. Først derefter kan man afgøre, om pilotprojektet kan udvides til yderligere konti, og hvilke undtagelser der er nødvendige af driftsmæssige årsager.

Sammenligning af beskyttelsesmetoder

Tilgangene adskiller sig først og fremmest med hensyn til, hvilke grænser de fastlægger, og hvem der forvalter dem. Tabellen klassificerer deres beskyttelsesmål; oplysningerne om driftsomkostningerne er kvalitative planlægningsretningslinjer, ikke målte værdier. Konkrete krav afhænger af den pågældende platform og dens konfiguration.

Filrettigheder og begrænset adgang er ikke synonyme begreber: Selv en synlig sti behøver ikke at være læsbar, og en tilgængelig sti skal sikres på passende vis. CageFS supplerer disse rettigheder med et struktureret miljø. LVE tager derimod fat på ressourceforbruget; for at kunne bruges sammen skal begge lag være konfigureret korrekt.

En egen VM flytter administrationsgrænsen i forhold til et brugerspecifikt miljø: Gæstsystemet skal vedligeholdes af brugeren selv og forbliver afhængigt af virtualiseringsplatformen. En separat server ændrer den fælles infrastruktur yderligere. Hvilken variant der er passende, afhænger af trusselsmodellen, de nødvendige rettigheder og de tilgængelige driftsressourcer.

En generel sikkerhedsrangliste ville derfor være vildledende. Oversigten over følgende emner er en hjælp til at sammenligne andre mekanismer og deres respektive anvendelsesområder: Procesisolering inden for hosting. Det afgørende er derefter den konkrete vurdering: Hvilken grænse skal forhindre hvilken adgang, hvilke tjenester overskrider den, og hvem overvåger konfigurationen?

Kontrolleret test af udførelsesstier

En aktiveret konto er ikke i sig selv en garanti for, at alle tilknyttede processer rent faktisk starter i CageFS. Det afgørende er den pågældende Udførelsessti: SSH-login, webserver og planlagte opgaver kan benytte forskellige integrationer. Administratorer skal derfor for hver relevant tjeneste undersøge, hvordan den tilordner processer til kontoen og dens miljø.

Med henblik på en kontrolleret test opretter operatøren en autoriseret testkonto og anvender udelukkende egne, udtrykkeligt godkendte testfiler. En fil inden for det forudbestemte miljø kan vise, om den forventede adgang fungerer; en separat forberedt fil uden for det forudbestemte synsfelt bruges til at kontrollere afgrænsningen. Eksterne kundemapper er ikke egnet testmateriale til dette formål.

Kontroller først via SSH, hvilket miljø testkontoen rent faktisk får tildelt, og om de påtænkte testfiler er tilgængelige som forventet. Gentag kontrollen med en webapplikation, der er konfigureret til dette formål, og en planlagt opgave. Resultaterne kan variere, hvis tjenesterne er integreret på en anden måde eller kører under en anden brugerkontekst.

Notér tjeneste, konto, sti og resultat for hvert forsøg. En afvist adgang bekræfter kun den observerede grænse i netop denne sammenhæng; den beviser hverken, at alle tjenester er korrekt isoleret, eller at hele værten er sikker. Omvendt bør en uventet vellykket adgang undersøges, før yderligere konti tages i brug.

Som hostingkunde kan du kontrollere din egen eksekveringskontekst og de delte filer. Globale CageFS-indstillinger, andre konti og integrationen af alle tjenester kan du normalt ikke selv kontrollere. Disse spørgsmål hører under udbyderens ansvarsområde; hvis du opdager uregelmæssigheder, skal du beskrive den pågældende tjeneste og den konkrete sti for udbyderen.

Manglende værktøjer og vedligeholdelse af Skeleton

Hvis et værktøj er installeret på værten, men ikke kan findes på kundekontoen, skal du først kontrollere kørselskonteksten. Et opkald via SSH behøver ikke at bruge det samme miljø som en webapplikation eller en planlagt opgave. Kontroller derefter søgestien og den konkrete fejlmeddelelse, før du antager, at der mangler et pakke.

Derefter undersøger operatøren det Skelet og mount-konfigurationen. Skeletonet er med til at bestemme, hvilke filer og mapper der stilles til rådighed i CageFS. Et program kan derfor findes på værtscomputeren og alligevel mangle i det brugerspecifikke miljø; også nødvendige biblioteker og andre afhængigheder skal tages i betragtning ved tilgængeliggørelsen.

Den praktiske løsning er ikke at indlæse store host-mapper som en sikkerhedsforanstaltning. Det ville muligvis gøre flere filer synlige, end der er behov for til opgaven. Operatøren bør i stedet udvælge de nødvendige programfiler og afhængigheder ved hjælp af producentens dokumentation og derefter kontrollere i den tilsigtede servicekontekst, om værktøjet fungerer.

Til den Vedligeholdelse af skeletet Det er også vigtigt at tage højde for ændringer i systempakker og i kontrolpanelet. CloudLinux beskriver en periodisk opdatering; efter visse ændringer kan det være nødvendigt at udføre en tvungen opdatering. Det kan også blive nødvendigt efter en genopbygning af Apache. Det betyder dog ikke, at den samme manuelle kommando skal udføres efter hver opdatering.

Planlæg opdateringen i overensstemmelse med den anvendte platform, og kontroller derefter de berørte applikationer og værktøjer. Hvis en applikation tidligere fungerede, men nu fejler efter en ændring, kan tidspunktet for pakkeændringen, den berørte tjeneste og den nøjagtige fejlmeddelelse hjælpe med at indsnævre problemet. På den måde kan man skelne mellem et implementeringsproblem og en fejl i applikationen.

Sikker drift og bevidste beslutninger

Når der skal træffes en beslutning om driften, er det ikke kun afgørende, om CageFS generelt er tilgængeligt. Operatøren skal vide, hvilke konti og tjenester der skal beskyttes, hvilke programmer der er behov for, og hvem der har ansvaret for integration og vedligeholdelse. Den begrænsede adgang til filsystemet supplerer andre sikkerhedsforanstaltninger; den erstatter hverken sikre applikationer eller beskyttelsen af adgangsoplysninger.

Følgende fortjener særlig opmærksomhed fællesarealer og yderligere mounts. CloudLinux beskriver for /dev/shm en fælles integration og en mulighed for isolering pr. bruger. Hvilken variant der rent faktisk gælder, skal kontrolleres ud fra den konkrete konfiguration. Yderligere mounts bør kun stille det til rådighed, som applikationerne har brug for, da de kan udvide det synlige miljø.

En fejl ved opstart af CageFS har også betydning for sikkerheden. CloudLinux beskriver fra og med CageFS 7.2.0-1 en indstilling, der gør det muligt at forhindre, at processer kører i tilfælde af en sådan fejl. Kontroller den installerede version og den faktiske indstilling, i stedet for at drage konklusioner om, hvordan denne indstilling vil fungere i forbindelse med et konkret hostingtilbud, blot på baggrund af, at denne indstilling findes.

Ændringer af Skeleton, mounts eller kontotilknytning skal indgå i en godkendt Vedligeholdelsesprocedurer. Tag i den forbindelse højde for eventuelle genmonteringer, berørte applikationer og et vedligeholdelsesvindue; dokumenter desuden, hvordan ændringen kan fortrydes, hvis der opstår problemer. Derefter bør de relevante udførelsessti og de nødvendige værktøjer kontrolleres igen ved hjælp af de planlagte testkonti.

For kunderne er det afgørende spørgsmål, hvilken adskillelse udbyderen rent faktisk gennemfører, og hvordan denne kontrolleres. Udbydere skal derimod afveje beskyttelsesbehovet og den løbende arbejdsbyrde: Et for generøst tilrettelagt miljø kan svække afgrænsningen, mens et for snævert miljø kan hæmme de nødvendige applikationer. Begge dele kræver en bevidst konfiguration og regelmæssig kontrol.