UNIX filsystem Sikkerhet

Denne artikkelen vurderinger grunnleggende filsystem og privilegium konsepter.

Når det gjelder inn-og utgang, behandler UNIX alt som en fil. Faktisk har begrepet filen flere betydninger i UNIX-det kan være en

· Regular fil. En sekvens av data byte samlet sett av operativsystemet som en fil.

· Directory fil. En liste over filnavn og pekere til filen meta informasjon (som er en fancy måte å si «informasjon om en fil"). Hvis du har lesetilgang til en katalog, betyr det at du kan lese innholdet i katalogen med andre ord, få en katalogoppføring (a la ls (1)). Imidlertid har bare UNIX kernel evne til å endre innholdet i denne filen (for eksempel sette inn en ny oppføring).

· Symbolsk lenke. Inneholder navnet på en annen fil. Når en symbolsk lenke er åpnet, gjenkjenner kjernen filen som sådan ved å undersøke dens arkiv-type. Det står da innholdet i fila. Kjernen åpner filen med navnet som er lagret i symbolsk lenke. Systemansvarlige bruker ofte symbolske linker å flytte data til et annet filsystem og samtidig opprettholde banen til den overordnede katalogen. Angripere, derimot, bruker symbolske linker for mer nefarious formål, som vi skal dekke senere.

· Character spesiell. Representerer en byte-orientert enhet. Det er UNIX-grensesnittet til enheter som opererer på en byte-for-byte basis, som en terminal enhet.

· Block spesiell. Fungerer som et tegn spesiell fil, men for blokk-orienterte enheter, for eksempel diskstasjoner.

· Socket. Lar en prosess for å kommunisere med en annen prosess, enten på det lokale systemet (via Inter Process Communication) eller en ekstern maskin. Programmer, for eksempel Telnet, rlogin og FTP bruker alle stikkontakter.

· Navngitt datakanal. Støtter lokale Inter Process Communication (IPC). På grunn av den type kø brukt det noen ganger referert til som en FIFO (First In First Out).

Hver av disse objektene er lagret i filsystemet. Protecting filsystemet fra misbruk er kritisk til den pågående integriteten til operativsystem, programmer og data.

Filattributter

UNIX-filsystem støtter et standard sett av filattributter eller egenskaper. Disse attributtene er lagret i en datastruktur kalt Inode (indeks node)-hver fil har en Inode. På Solaris, er Inode datastruktur for den tradisjonelle UNIX-filsystemet (UFS) er definert i / usr / include / sys / fs / ufs_inode.h.

Fra et sikkerhetsperspektiv, de viktigste egenskapene inkluderer

· Eieren id. Den numeriske bruker-ID som eier filen.

· Gruppen id. Den numeriske gruppe-ID som eier filen.

· Tillatelser. Kombinert med eieren id og gruppe id disse bestemme tilgangskontroll på filen.

· Størrelse. Målt i byte.

· Tidspunkt for siste tilgang. Den gang filen sist ble åpnet, i sekunder siden 1970.

· Tidspunkt for siste endring. Den gang filen sist ble endret, i sekunder siden 1970.

· Tidspunkt for siste Inode endring. Tiden filen ble opprettet, i sekunder siden 1970.

· Antall harde lenker. Antall filer som "peker" på denne filen.

Tillatelsene attributtet definerer tilgang rettighetene til filen eier gruppen eier, og alle andre brukere på systemet. Rotbrukeren og arkiv eieren kan kontrollere tilgang til en fil ved å sette rettigheter på filen og på den overordnede kataloger.

I standard implementering av UNIX, er roten brukeren ikke gitt tillatelse til å sjekke-root kan lese, skrive, eller kjøre en hvilken som helst fil. Merk at i UNIX, skrivetilgang tilsvarer slette-per definisjon, hvis du kan skrive til filen, kan du slette innholdet i filen.

Leserne kjent med filsystemet tillatelser oppfordres til å lese chmod man-siden. For videre lesning, jeg anbefaler Videregående programmering på UNIX Environment, Addison-Wesley, 1992, ISBN 0-201-56317-7.

Tillatelser in Practice

Å åpne en fil ved navn, må en bruker ha execute privilegium i hver katalog i filen banen, samt riktig tilgang til selve filen. Når det gjelder filer i gjeldende katalog, må en bruker execute privilegium for den aktuelle katalogen.

For å kunne opprette en fil i en katalog, må en bruker ha execute tillatelse på hver mappe i banen, samt skrivetilgang i målet katalogen.

Når det gjelder å slette en fil, er det faktisk ikke nødvendig å være filen eier eller har skrivetilgang til filen. Ved å skrive og kjøretillatelser på den overordnede katalogen, kan du slette filer. Dette kan være en "fikser" hvis du ikke er forsiktig.

For å forstå hvordan de ulike tillatelsene er kontrollert når en bruker forsøker å åpne en fil, må du forstå hvordan prosessen privilegier arbeid.

Enkelt sagt, når du kjører et program, en prosess er opprettet. Knyttet til en prosess som er minst seks IDer:

· Real Bruker-ID. Det numeriske bruker-ID på påloggingskonto

· Real Group ID. Det numeriske gruppe-IDen til din primære gruppe (gruppen definert i / etc / passwd entry)

· Effektiv Bruker-ID. Den numeriske brukernavn brukes under filtilgang tillatelse sjekker

· Effektiv Group ID. Den numeriske gruppe-ID brukes under filtilgang tillatelse sjekker

· Lagrede Set User ID. En kopi av numeriske bruker-ID lagret av exec funksjonen når du kjører et program

· Lagrede Set Group ID. En kopi av numeriske gruppe-ID reddet av exec funksjonen når du kjører et program

I tillegg, hvis du er medlem av mer enn en UNIX-gruppen, et tilsvarende antall supplerende gruppe IDer settes.

Ved første øyekast kan dette virke overcomplicated. Å sette pris på hvorfor så mange IDer er nødvendig, må vi snakke om en viktig sikkerhetsmekanisme for UNIX, set-uid / set-gid privilegium.

The Set-uid / Set-gid Privilege

Normalt, når du kjører et program, en prosess skapt som kjører med rettighetene knyttet til bruker-ID. Dette er fornuftig, du skal ikke kunne påvirke filer eller prosesser som tilhører en annen bruker. Noen programmer trenger for å utføre privilegerte operasjoner. De kan ikke gjøre dette hvis de kjører under bruker-ID-en svakstilte ringer. Å lage et program privilegert, kan programmet eieren (eller root) tildele set-uid eller set-gid bit til programmet via kommandoen chmod.

I motsetning til vanlige programmer, en set-uid programmet kjører med rettighetene til programmet eier ikke den som ringer. Ved å lage et program set-uid, lar du den til å utføre handlinger med autoritet av programmet eier, på dine vegne.

Set-gid fungerer på samme måte, men ikke overraskende, for grupper. En set-gid programmet kjører med rettighetene til å eie gruppen stedet med rettighetene knyttet til gruppen av bruker-IDen som kalte programmet.

Set-gid kan også settes på en katalog. Filer senere opprettet i en set-gid katalogen vil ha sin gruppe eierskap sett den samme som set-gid katalogen. Vanligvis gruppen eier vil være satt til users'primary gruppen. På denne måten kan en gruppe brukere dele data på tross av å være i ulike primære grupper.

Et eksempel på en set-uid programmet er passwd program. Når du endre passordet, må systemet en måte å endre passordet ditt inn i / etc / shadow. Denne filen er bare tilgjengelig med rot fordi den lagrer passord, men dette hindrer deg fra legitimt å endre passordet. Ved å gjøre det passwd program set-uid, lar du et nonprivileged bruker-ID for å oppdatere sine passord. Uten set-uid bit, ville brukerne måtte ringe opp administrator for å få passord endret.

I vårt eksempel, er sikkerheten i skyggen filen på nåde av passwd program. Hvis brukeren kjører passordet programmet kan en eller annen måte påvirke programmet på en måte programmerer ikke vurdere, kan hun være i stand til å direkte endre skyggen filen!

Derfor set-uid programmene må programmeres defensivt å unngå deres blir undergravd av en angriper til å få ekstra privilegier. I tilfelle av en set-uid rot programmet, innsatsen er svært høy en utnyttbare feil betyr game over-angriperen blir rot privilegier.

The umask

Vår gjennomgang av filrettigheter vil være ufullstendig uten studere umask. The umask bestemmer tillatelser som vil gjelde for en nyopprettet fil hvis ingen tillatelser er uttrykkelig angitt ved opprettelse tid. Med andre ord er det standardfilen tillatelse.

The umask er representert som den inverse av filrettigheter. For eksempel, hvis våre standard umask er 022, alle filer vi skaper som vi ikke eksplisitt angitt filtillatelsene ville være skapt med 755 tillatelser, som har bruker-ID lese, skrive og utføre tillatelser, mens gruppe-ID og Andre har lest og kjøretillatelser. Bare husk at umask bør settes til en verdi motsatte av tillatelsene du vil bruke.

En felles standard umask verdi er 022. Dette er vanligvis satt i et system-wide påloggingsskript for eksempel / etc / profile. Dette kan overstyres av en bruker som angir en annen (vanligvis mer restriktiv) verdi i hans lokale påloggingsskript (for eksempel ~ bruker /. Profil). The umask-kommandoen er en innebygd skallkommando, den kan kjøres på shell prompt, for eksempel som 022 umask.

Hver prosess på et UNIX-system har en umask innstilling-det ikke bare påvirke brukere som logger på interaktivt. Når systemet støvlene og utfører systemet oppstart skript er en rekke nettverk daemoner (tjenester) startet. De arver umask verdien av sine foreldre prosess init-regel 022. Eventuelle filer de senere oppretter vil bli gitt tillatelser satt av umask mindre programmerer uttrykkelig angir tillatelser.

The umask innstillingen er derfor utrolig viktig-hvis den er satt for løst, kan andre brukere kunne lese, eller i noen tilfeller, skriver over filene dine. Til tross for sin betydning, blir den ofte oversett av programmerere.

en artikkel presentert av Andreas Schmidt