The Hidden Resources Detector for GNU/Linux

(1)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INTELIGENTN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS

DETEKTOR UTAJOVAN ´

YCH PROST ˇ

REDK ˚

U

PRO GNU/LINUX

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

RADEK NE ˇ

CAS

AUTHOR

(2)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INTELIGENTN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS

DETEKTOR UTAJOVAN ´

YCH PROST ˇ

REDK ˚

U

PRO GNU/LINUX

THE HIDDEN RESOURCES DETECTOR FOR GNU/LINUX

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

RADEK NE ˇ

CAS

AUTHOR

VEDOUC´I PR ´

ACE

Ing. BORIS PROCH ´

AZKA

SUPERVISOR

(3)

Abstrakt

Tato práce se zabývá detekován´ım skrytých prostˇredk˚u v prostˇred´ı operaˇcn´ıch systém˚u GNU/Linux. Souˇcasnˇe analyzuje nástroje, které toto skrýván´ı provádˇej´ı (tzv. rootkity). Práce je rozdˇelena na teoretickou a praktickou ˇcást. Teoretická ˇcást se zamˇeˇruje pˇredevˇs´ım na zp˚usob správy a reprezentace prostˇredk˚u v operaˇcn´ım systému, reˇzimy bˇehu a systémová volán´ı. Praktiká ˇcást se zabývá návrhem a implementac´ı obecného detektoru, kterému jsou jednotlivé metody detekce pˇredány formou zásuvných modul˚u. Nˇekteré z tˇechto metod jsou realizovány jako moduly jádra operaˇcn´ıho systému. Úˇcinnost detektoru je porovnána oproti reálným rootkit˚um.

Abstract

The main goal of this thesis was to detect hide resources in GNU/Linux operating systems and analyse tools so called rootkits, which are used to hide system resources. This thesis is devided into two parts, theoretical and practical one. Theoretic part focusses on resource managment, representation, privilege levels and system calls. Practical part covers design and implementation of an abstract detector. Each new detection method is implemented as a plugin. Some of those methods are realized as linux kernel modules. The usability of the detector is compared against real rootkits.

Kl´ıˇ

cov´

a slova

poˇc´ıtaˇcová bezpeˇcnost, operaˇcn´ı systém, Linux, systémová volán´ı, virtuáln´ı souborový systém, proces, soubor, s´ıt’ová spojen´ı, rootkit, detektor

Keywords

computer security, operating system, Linux, system call, virtual filesystem, process, file, network connection, rootkit, detector

Citace

Radek Neˇcas: Detektor utajovan´ych prostˇredk˚u

(4)

Detektor utajovan´

ych prostˇ

redk˚

u

pro GNU/Linux

Prohl´

aˇ

sen´ı

Prohlaˇsuji, ˇze jsem tuto bakaláˇrskou práci vypracoval samostatnˇe pod veden´ım pana Ing. Borise Procházky. Uvedl jsem vˇsechny literárn´ı prameny a publikace, ze kterých jsem ˇ

cerpal.

. . . . Radek Neˇcas 14. kvˇetna 2013

Podˇ

ekov´

an´ı

T´ımto bych rád podˇekova panu Ing. Borisi Procházkovi za jeho veden´ı, zájem, ochotu a ˇcas, který mi vˇenoval a v neposledn´ı ˇradˇe za schopnost mˇe vˇzdy navést správným smˇerem.

c

Radek Neˇcas, 2013.

Tato práce vznikla jako ˇskoln´ı d´ılo na Vysokém uˇcen´ı technickém v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Práce je chránˇena autorským zákonem a jej´ı uˇzit´ı bez udˇelen´ı oprávnˇen´ı autorem je nezákonné, s výjimkou zákonem definovaných pˇr´ıpad˚u.

(5)

Obsah

´

Uvod 3

1 Operaˇcn´ı syst´em 5

1.1 Operaˇcn´ı syst´em a jeho role . . . 5

1.2 J´adro operaˇcn´ıho syst´emu . . . 6

1.2.1 Typy jader . . . 6

1.2.2 J´adro Linux . . . 7

1.3 Urovnˇ´ e opr´avnˇen´ı . . . 7

1.3.1 Pˇrechod mezi reˇzimy opr´avnˇen´ı . . . 8

1.4 Implementace systémových volán´ı . . . 10

2 Reprezentace a spr´ava prostˇredk˚u 11 2.1 Reprezentace a spr´ava proces˚u . . . 11

2.1.1 Z´akladn´ı pojmy . . . 11

2.1.2 Reprezentace proces˚u . . . 12

2.1.3 ˇZivotn´ı cyklus procesu . . . 13

2.1.4 Pl´anov´an´ı proces˚u . . . 15

2.2 Reprezentace a spr´ava soubor˚u . . . 17

2.2.2 Virtuáln´ı souborový systém . . . 17

2.2.3 Reprezentace VFS . . . 18

2.3 Reprezentace a spr´ava s´ıt’ov´ych spojen´ı . . . 21

2.3.2 Reprezentace s´ıt’ov´ych spojen´ı . . . 22

3 Rootkity a metody ´utok˚u 23 3.1 Z´akladn´ı pojmy . . . 23

3.2 Typy rootkit˚u . . . 23

3.2.1 Rootkity bˇeˇz´ıc´ı v uˇzivatelsk´em reˇzimu . . . 23

3.2.2 Rootkity bˇeˇz´ıc´ı v reˇzimu j´adra . . . 24

3.3 Metody ´utok˚u v reˇzimu j´adra . . . 25

3.3.1 Napaden´ı obsluhy pˇreruˇsen´ı . . . 26

3.3.2 Napaden´ı výbˇeru systémové funkce . . . 26

3.3.3 Napaden´ı syst´emov´e funkce . . . 27

3.4 Testovan´e rootkity . . . 29

3.4.1 Kbeast-v4 . . . 29

3.4.2 Adore-ng . . . 29

(6)

3.4.4 Jynx2 . . . 29

3.4.5 DR . . . 29

3.4.6 Override . . . 30

4 Programován´ı modul˚u pro jádro 31 4.1 Základn´ı principy . . . 31

4.2 Datov´e typy v j´adˇre . . . 32

4.2.1 Implementace datov´ych typ˚u . . . 32

4.3 Komunikace modulu s uˇzivatelskou aplikac´ı . . . 33

4.4 Tvorba a spr´ava modul˚u . . . 33

5 Detekce skryt´ych prostˇredk˚u a implementace detektoru 34 5.1 Detekce skryt´ych proces˚u . . . 34

5.2 Detekce skryt´ych spojen´ı . . . 37

5.3 Detekce skryt´ych soubor˚u . . . 38

5.4 N´avrh a implementace detektoru . . . 40

6 Testov´an´ı 42 6.1 Postup testov´an´ı . . . 42

6.2 V´ysledky testov´an´ı . . . 42

Z´avˇer 44

Seznam pˇr´ıloh 47

A Ukázkové výstupy programu 48

(7)

´

Uvod

ˇ

Zijeme v modern´ı dobˇe plné technologi´ı. Poˇc´ıtaˇce jsou dnes bˇeˇznou souˇcást´ı vˇsech domácnost´ı, stejnˇe jako televize, lednice ˇci praˇcka. Význam poˇc´ıtaˇc˚u s´ıl´ı s fenoménem dneˇsn´ı doby – Internetem. Uˇz nám neslouˇz´ı jen pro práci ˇci zábavu, ale stávaj´ı se vstupn´ı branou do virtuáln´ıho svˇeta, který nám v mnohém zjednoduˇsuje ˇzivot v tom skuteˇcném. M´ısto postáván´ı ve frontách obchod˚u si m˚uˇzeme objednat zboˇz´ı z domu, návˇstˇevu banky na-hrad´ıme zadán´ım pˇr´ıkazu z pohodl´ı vlastn´ıho gauˇce. Kaˇzdá mince má ale i druhou stranu. V poˇc´ıtaˇc´ıch uchováváme spoustu citlivých informac´ı, které m˚uˇzou být zneuˇzity. Internet je poté prostˇredn´ıkem, který umoˇzˇnuje útoˇcn´ık˚um infiltrovat váˇs poˇc´ıtaˇc. Z tˇechto d˚uvod˚u se vyvýjej´ı stálé nové a dokonalejˇs´ı bezpeˇcnostn´ı mechanismy. Stejnˇe s nimi se ale zdokonaluj´ı i metody útok˚u. Útoˇcn´ıci se v prvn´ı ˇradˇe snaˇz´ı skrýt svoji ˇcinnost na napadené stanici. K této ˇcinnosti jim právˇe slouˇz´ı rootkity.

Pˇri tvorbˇe rootkit˚u je potˇreba detailnˇe znát strukturu napadeného systému. My se v této práci seznám´ıme s rodinou operaˇcn´ıch systém˚u GNU/Linux. Tyto systémy jsou dnes pouˇz´ıvané pˇredevˇs´ım na servrech, d´ıky ˇcemuˇz jsou pro útoˇcn´ıky velmi zaj´ımavé. Linuxové systémy zastávaj´ı politiku otevˇreného kódu. Útoˇcn´ıci tedy mohou nahlédnout do jejich zdrojových kód˚u a hledat zranitelná m´ısta. Podobnou filozofii zastávaj´ı i autoˇri veˇrejných rootkit˚u. M˚uˇzeme tedy pouˇz´ıt stejný postup, analyzovat kód operaˇcn´ıch systém˚u i rootkit˚u a jejich srovnán´ım nalézt zp˚usob, jak odhalit útoˇcn´ıkovu nekalou ˇcinnost. O tento postup jsem se pokusil i já pˇri tvorbˇe této práce.

V prvn´ı kapitole jsem se pokusil srozumitelnˇe podat základn´ı pojmy oblasti operaˇcn´ıch systém˚u, které dále vyuˇz´ıvám ve zbytku práce. Také jsem zde rozebral úrovnˇe oprávnˇen´ı a implementaci systémových volán´ı, jejichˇz znalost je nezbytná pro pochopen´ı funkce root-kit˚u. V druhé kapitole jsem se zamˇeˇril na reprezentaci a správu prostˇredk˚u operaˇcn´ıch systém˚u pˇredevˇs´ım proces˚u, soubor˚u a s´ıt’ových spojen´ı. Popsal jsem zp˚usoby, jak tyto prostˇredky vznikaj´ı, jak jsou reprezentovány, a jak jsou ruˇseny. V tˇret´ı kapitole se pr˚ubˇeˇznˇe dostáváme k praktické ˇcásti této práce. Pro jej´ı sestaven´ı jsem detailnˇe prozkoumal ˇsest veˇrejnˇe dostupných rootkit˚u a provedl jsem analýzu systémových volán´ı i virtuáln´ıho sou-borového systému. Pro pˇrehlednost jsem rozdˇelil rootkity do základn´ıch skupin. Kritériem tohoto dˇelen´ı byly metody, jakými rootkity skrývaj´ı prostˇredky operaˇcn´ıho systému, ˇci adre-sový prostor, ve kterém se kód rootkitu nacház´ı. Nakonec jsem zde popsal veˇrejnˇe dostupné rootkity, které byly pouˇzity v této práci.

Ve ˇctvrté kapitole jsem popsal pár základn´ıch poznatk˚u ohlednˇe vytváˇren´ı, správy a zavádˇen´ı modul˚u pro jádro. Popsal jsem i rozd´ıly oproti uˇzivatelským aplikac´ım, které by mˇel m´ıt kaˇzdý programátor jaderných modul˚u na pamˇeti. Poté uˇz následovala ˇcistˇe praktická kapitola vˇenuj´ıc´ı se detekci skrytých prostˇredk˚u. V této kapitole jsem navrhl sadu metod jakými mohou být identifikovány skryté prostˇredky. Zamˇeˇril jsem se pˇredevˇs´ım na detekci skrytých proces˚u, která nab´ızela nejv´ıce prostoru pro r˚uzné zkoumán´ı a expe-rimentován´ı. Implementoval jsem tˇri detektory skrytých proces˚u. Jeden bˇeˇz´ıc´ı kompletnˇe v uˇzivatelském reˇzimu a dva vyuˇz´ıvaj´ıc´ı pro detekci modul˚u jádra. Abych mohl zajistit

(8)

komunikaci detektoru s tˇemito moduly, musel jsem prozkoumat, jak´e kan´aly pro tento typ

komunikace Linux nab´ız´ı, a naimplementovat jednoduch´y protokol. D´ale jsem

implemen-toval detektor skrytých spojen´ı a popsal dva návrhy detekce skrytých soubor˚u. V ˇsesté kapitole popisuje testován´ı detektoru a analyzuji výsledky tˇechto test˚u.

Vˇsechny kapitoly jsem se snaˇzil podat srozumitelnˇe i pro nepˇr´ıliˇs zasvˇecené ˇctenáˇre, proto jsem je obohatil o sadu ilustraˇcn´ıch obrázk˚u. Výsledný detektor byl testován oproti analyzovaným rootkit˚um. Srovnán´ı tˇechto rootkit˚u je dodáno v pˇr´ıloze spoleˇcnˇe s ukázkovými výstupy detektoru. Detektor jsem navrhl s ohledem na moˇznosti budouc´ıho rozˇs´ıˇren´ı. V práci lze pokraˇcovat zaˇrazován´ım nových metod detekce. Lze implementovat nˇekteré z uvedených metod ˇci pokraˇcovat v odhalován´ı nových. Mohou být zaˇrazeny detekce dalˇs´ıch prostˇredk˚u jako napˇr´ıklad skrytých modul˚u ˇci text˚u ukrytých uvnitˇr souboru. Nakonec by mohl být program pˇretvoˇren do kompletn´ıho detektoru rootkit˚u, který by mohl být zaˇrazen do anti-virového systému.

(9)

Kapitola 1

Operaˇ

cn´ı syst´

em

Tato úvodn´ı kapitola se zamˇeˇruje na základn´ımi pojmy teorie operaˇcn´ıch systém˚u. Bu-dou zde popsány pojmy jako operaˇcn´ı systém, jeho jádro a reˇzimy oprávnˇen´ı. Na tˇechto informac´ıch je postaven výklad zbylých kapitol. Take jsou zde obsaˇzeny informace o pr˚ubˇehu provádˇen´ı systémových volán´ı, které jsou základn´ı pro pochopen´ı funkce rootkit˚u.

1.1 Operaˇ

cn´ı syst´

em a jeho role

Nejdˇr´ıve se seznám´ıme s výpoˇcetn´ım systémem.Výpoˇcetn´ı systém se skládá z uˇzivatel˚u, aplikaˇcn´ıch program˚u, operaˇcn´ıho systému1 a hardwarových komponent (obr. 1.1)[1]. M˚uˇze zajiˇst’ovat ˇsirokou ˇskálu r˚uzných operac´ı a funkc´ı od zobrazován´ı videi, komunikaci po inter-netu aˇz po sloˇzité simulace. Tyto moˇznosti se mohou znaˇcnˇe mˇenit ˇci rozˇsiˇrovat pˇridáván´ım

nových program˚u a hardwarových komponent. Uˇzivatelé komunikuj´ı se zbytkem systému

skrze uˇzivatelská rozhrann´ı aplikaˇcn´ıch program˚u. Veˇskerá ˇcinnost je nakonec vykonána za pomoc´ı hardwaru (procesor, pamˇet’, vstupnˇe/výstupn´ı zaˇr´ızen´ı aj.). Operaˇcn´ı systém tento hardware ˇr´ıd´ı a umoˇzˇnuje jeho uˇzit´ı pro r˚uzné aplikace. Aplikace zase d´ıky funkci operaˇcn´ıho systému nemusej´ı znát pˇresnou implementaci hardwaru ani detaily jeho komunikaˇcn´ıho roz-hrann´ı, a pˇresto jsou schopny vyuˇz´ıvat jeho sluˇzeb.

Operaˇcn´ı systém (zkrácenˇe OS) je softwerovou ˇcást´ı výpoˇcetn´ıho systému, jenˇz tvoˇr´ı mezivrstvu mezi hardwarem a uˇzivatelskými ˇci systémovými programy. Zat´ımco program˚u m˚uˇze souˇcasnˇe bˇeˇzet celá ˇrada, operaˇcn´ı systém bˇeˇz´ı vˇzdy jen jeden. Dalo by se ˇr´ıci, ˇze je základnou na které stav´ı a které vyuˇz´ıvaj´ı ostatn´ı aplikace2. Pln´ı dvˇe základn´ı role [2]:

1. Rozˇs´ıˇren´ı stroje – Poskytuje mnoˇzinu operac´ı pomoc´ı kterých lze komunikovat s hardwarem na vyˇsˇs´ı úrovni pomoc´ı pˇr´ıvˇetivˇejˇs´ıho komunikaˇcn´ıho rozhran´ı [2]. Apli-kace tedy mohou vyuˇz´ıvat r˚uzné typy hardwaru, anichˇz by znali jejich pˇresnou im-plementaci. Tv˚urci tˇechto aplikac´ı zase mohou vyuˇz´ıvat standardizované komunikaˇcn´ı rozhran´ı, coˇz jim umoˇzˇnuje psát jednoduˇsˇs´ı, ˇcitelnˇejˇs´ı a pˇrenositelnˇejˇs´ı programy. 2. Správce zdroj˚u – V této roli OS pˇridˇeluje výpoˇcetn´ı prostˇredky (procesor, pamˇet’,

vstupnˇe/výstupn´ı zaˇr´ızen´ı) a umoˇzˇnuje jejich sd´ılen´ı co nejefektivnˇejˇs´ım zp˚usobem. Zároveˇn zajiˇst’uje zabezpeˇcen´ı pˇr´ıstupu a práce s tˇemito komponentami.

1

Rozsah pojmu operaˇcn´ı systém nen´ı striktnˇe definován a v r˚uzných literaturách se liˇs´ı. V nˇekterých je

chápán v uˇzˇs´ım smyslu pouze jako jádro. V jiných je tento pojem rozˇs´ıˇrený i na vˇsechny systémové programy.

V této práci bude pouˇzita druhá definice.

(10)

Uživatel 1 Uživatel 2 Uživatel 3 Uživatel n

Aplikace

Operační systém

Hardware

Obrázek 1.1: Výpoˇcetn´ı systém

Mezi nejpouˇz´ıvanˇejˇs´ı souˇcasné operaˇcn´ı systémy patˇr´ı Microsoft Windows, Mac OS X a systémy GNU/Linux [3]. GNU/Linux je sp´ıˇse rodinou operaˇcn´ıch systém˚u sd´ılej´ıc´ı stejné

j´adro (Linux). K dispozici je ve formˇe distribuc´ı jako napˇr.: Debian, Cent OS, Ubuntu,

Arch Linux a mnoho jiných. Distribuce se snaˇz´ı být komplexn´ım a snadno pouˇzitelným

poˇc´ıtaˇcovým systémem. Obsahuj´ı tedy kromˇe samotného OS i uˇzivateli bˇeˇznˇe vyuˇz´ıvaný dodateˇcný software jako internetový prohl´ıˇzeˇc, textový editor aj. Disponuj´ı rozsáhlými databázemi tohoto softwaru tzv. zdroji, jenˇz umoˇzˇnuj´ı jeho snadné z´ıskáván´ı napˇr´ıklad prostˇrednictv´ım Internetu.

1.2 J´

adro operaˇ

cn´ıho syst´

emu

Operaˇcn´ı systém je sloˇzitým a komplexn´ım programem. Skládá se z mnoha komponent zajiˇst’uj´ıc´ıch r˚uzné ˇcásti jeho funkcionality. Základn´ı a zˇrejmˇe nejpodstatnˇejˇs´ı komponentou jejádro. Jádro bˇeˇz´ı od zaveden´ı operaˇcn´ıho systému aˇz po jeho ukonˇcen´ı. V jeho pamˇet’ovém prostoru jsou uloˇzena veˇskerá data, pomoc´ı kterých zajiˇst’uje jádro základn´ı funkce nutné pro plnˇen´ı výˇse uvedených rol´ı OS. Typickými ˇcinnostmi kterými se jádro zabývá jsou napˇr´ıklad správa pˇreruˇsen´ı, proces˚u ˇci pamˇeti. Nad jádrem jsou poté vystavˇeny dalˇs´ı kom-ponenty jako je okenn´ı manaˇzer, jenˇz poskytuje uˇzivatel˚um základn´ı uˇzivatelské rozhran´ı vykreslován´ım a rozm´ıstˇen´ım oken, správce sezen´ıaj.

1.2.1 Typy jader

Dle pˇr´ıstupu k implementaci m˚uˇzeme j´adra rozdˇelit do tˇechto z´akladn´ıch skupin [4]:

• Mikrojádro – Pouze základn´ı funkcionalita je implementována pˇr´ımo v jádˇre tzv.

mikrojádˇre. Ostatn´ı funkcionalita je delegována do samostatných proces˚u zvaných

servery, které komunikuj´ı s jádrem skrze striktnˇe definované komunikaˇcn´ı rozhrann´ı (napˇr.: souborový systém, správce pamˇeti, aj.). Výhodou tohoto pˇr´ıstupu je snadná rozˇsiˇritelnost jádra a moˇznost mˇenit, spouˇstˇet ˇci zastavovat jeho d˚uleˇzité komponenty za bˇehu systému. Nevýhodou tohoto pˇr´ıstupu je velmi ˇcastá a nároˇcná komunikace

(11)

jednotlivých server˚u mezi sebou ˇci s jádrem, pˇri které mus´ı docházet k pˇrep´ınán´ı kontextu.

• Monolytická jádra – Veˇskerá funcionalita vˇcetnˇe podsystém˚u je implementována jako souˇcást jádra. Kaˇzdý podsystém má k dispozici pˇr´ıstup ke vˇsem ostatn´ım ˇcástem jádra. D´ıky tomu, ˇze celý kód bˇeˇz´ı ve stejném adresovém prostoru (v systémovém reˇzimu), je ˇcinnost jádra velmi efektivn´ı a pˇrep´ınán´ı kontextu minimáln´ı. Problémem tohoto pˇr´ıstupu m˚uˇze být jeho niˇzˇs´ı bezpeˇcnost. Pˇri napaden´ı systému staˇc´ı útoˇcn´ıkovi nabourat jeho libovolnou ˇcást a m˚uˇze t´ım z´ıskat pˇr´ıstup k celému jádru.

P˚uvodnˇe byl celý kód jádra obsaˇzen v jednom bal´ıˇcku. Jádro nemˇelo ˇzádnou vnitˇrn´ı strukturu a veˇskerá ˇcinnost prob´ıhala v jednom reˇzimu. Dokonce i uˇzivatelské procesy byly spouˇstˇeny jako podprogramy jádra. V literatuˇre je tento pˇr´ıstup uvádˇen jako mo-nolytická jádra typu monitor. V dneˇsn´ı dobˇe je vˇetˇsina monolytických jader vytváˇrena smodulárn´ı strukturou. Funkˇcnost jádra je rozdˇelena do jednotlivých podsystém˚u tzv.

jádrových modul˚u, které spolu úzce spolupracuj´ı. Tyto moduly bˇeˇz´ı v systémovém reˇzimu, zat´ımco uˇzivatelské procesy v reˇzimu uˇzivatelském. Pro pˇrechod mezi reˇzimi je zavedeno striktn´ı rozhran´ı. Tento pˇr´ıstup pˇrináˇs´ı vyˇsˇs´ı bezpeˇcnost systému a umoˇzˇnuje modifikaci jádra za bˇehu zavádˇen´ım jednotlivých modul˚u. Pˇr´ıkladem tohoto typu jádra je Linux.

• Ostatn´ı – Existuj´ı i jiné typy jader OS. Pˇr´ıkladem mohou být napˇr´ıklad Hybridn´ı jádra, jenˇz se snaˇz´ı zkombinovat dobré vlastnosti pˇredchoz´ıch variant,Exojádra jenˇz vˇetˇsinu funkcionality pˇresouvaj´ı do uˇzivatelského reˇzimu a poskytuj´ı jen velmi jedno-duché rozhrann´ı pro komunikaci s jádrem aj. Hybridn´ıch jader vyuˇz´ıvaj´ı systémy jako

Mac OS X ˇci Windows NT [5].

1.2.2 J´adro Linux

Linux je jádrem operaˇcn´ıho systému GNU/Linux. Jde omonolytické jádro s modulárn´ı strukturou. Pˇri manuáln´ı instalaci jádra lze pˇri konfigurován´ı instalace nastavit jaké moduly chceme nainstalovat, pˇr´ıpadnˇe jakou funkcionalitu chceme zavést pˇr´ımo do jádra a jakou

poskytnout skrze moduly (Loadable Kernel Module - LKM)[6]. Linux se vyvyj´ı pod GPL

licenc´ı3. Na jeho vývoji se pod´ıl´ı vývojáˇrská komunita vˇcetnˇe Linuse Torvaldse jeho za-kladatele. Tato dalo by se ˇr´ıc´ı ˇcistá jádra se nazývaj´ıvanilla jádra a jsou volnˇe k dispo-zici prostˇrednictn´ım Internetu. Dále je pˇreb´ıraj´ı tv˚urci jednotlivých distribuc´ı, testuj´ı je, pˇr´ıpadnˇe upravuj´ı a zaˇrazuj´ı poté do svých systém˚u.

R˚uzné distribuce vyuˇz´ıvaj´ı r˚uzné verze Linuxu. Aby byla zachována pˇrehlednost jed-notlivých verz´ı, byl zaveden systém ˇc´ıslován´ı verz´ı jádra (obr. 1.2). Majoritn´ı spolu s mino-ritn´ım ˇc´ıslem verze udávaj´ı sérii jádra. Ta se mˇen´ı vˇzdy aˇz pˇri razantn´ıch zmˇenách systému. Ostatn´ı se mˇen´ı s vydáván´ım r˚uzných aktualizac´ı a záplat [6]. Nˇekteré distribuce se snaˇz´ı vyuˇz´ıvat nových trend˚u a instaluj´ı nové verze jádra. Jiné jsou sp´ıˇse ortodoxn´ı a drˇz´ı se starˇs´ıch stabiln´ıch a ovˇeˇrených verz´ı.

1.3 Urovnˇ

´

e opr´

avnˇ

en´ı

Linux disponuje dvˇemy ´urovnˇemi opr´avnˇen´ı [1, 5]:

3

V dobˇe psan´ı pr´ace byla vyv´ıjena pod GPLv2 licenc´ı. V´ıce na http://vanillaforums.org/docs/

(12)

2.6.32.1

Majoritní verze

Minoritní verze Revize

Stabilní verze

Obrázek 1.2: ˇC´ıslován´ı verze jádra Linuxu

• Uˇzivatelský reˇzim(neprivilegovaný reˇzim) – Je reˇzim v nˇemˇz bˇeˇz´ı uˇzivatelské procesy. V tomto reˇzimu má proces k dispozici pouze uˇzivatelský pamˇet’ový prostor

a disponuje pouze omezenou sadou instrukc´ı.

• Reˇzim jádra(privilegovaný ˇci systémový reˇzim)– V tomto reˇzimu je k dispozici celý pamˇet’ový prostor vˇcetnˇepamˇet’ového prostoru jádra a kompletn´ı instrukˇcn´ı sada. Bˇeˇz´ı v nˇem jádro a jeho moduly.

Pokud se uˇzivatelský proces pokus´ı pˇristoupit mimo sv˚uj pamˇet’ový prostor ˇci bude cht´ıt pouˇz´ıt instrukci nepovolenou v jeho reˇzimu, bude tento stav zachycen operaˇcn´ım systémem a ˇcinnost bude zakázana. Uˇzivatelské procesy ale velmi ˇcasto potˇrebuj´ı právˇe takové operace provádˇet. Z tohoto d˚uvodu je umoˇznˇen pˇrechod mezi jednotlivými reˇzimy. Tento pˇrechod je pˇr´ısnˇe monitorován a je provádˇen skrze striktn´ı komunikaˇcn´ı rozhran´ı. Tento pˇr´ıstup je základn´ım bezpeˇcnostn´ım principem který nejen stˇeˇzuje práci potencionáln´ım útoˇcn´ık˚um, ale také chrán´ı systém pˇred moˇznými dopady chybnˇe napsaných uˇzivatelských aplikac´ı.

Provádění uživatelského procesu Vyvolání systémového volání Návrat ze systémového volání Uživatelský prostor

Provedení systémového volání Prostor jádra U ži va te ls ký r ež im R ež im já dr a

Obr´azek 1.3: Pˇrechod mezi reˇzimy opr´avnˇen´ı

1.3.1 Pˇrechod mezi reˇzimy opr´avnˇen´ı

Pˇrechod mezi reˇzimy oprávnˇen´ı je umoˇznˇen dvˇema zp˚usoby. Prvn´ı moˇznost´ı je vyuˇzit´ı rozhran´ı systémových volán´ı. Kaˇzdé systémové volán´ı má své identifikaˇcn´ıˇc´ıslo a návratovou

(13)

hodnotu. Aplikace poˇzaduj´ıc´ı operaci k n´ıˇz bˇeˇznˇe nemá opravnˇen´ı spust´ı systémové volán´ı. Dojde k pˇrechodu z uˇzivatelského reˇzimu do reˇzimu jádra. V nˇem se provedou funkce jádra jenˇz obslouˇz´ı dané volán´ı. Po dokonˇcen´ı tˇechto funkc´ı se vrát´ı ˇr´ızen´ı uˇzivatelské aplikaci do m´ısta spuˇstˇen´ı systémového volán´ı a je navrácena hodnota (obr. 1.3).

Aplikace vˇetˇsinou nespouˇst´ı systémová volán´ı pˇr´ımo, ale vyuˇz´ıvaj´ı k tomu knihovny. Pro vykonán´ı dané operace vyuˇzij´ı knihovn´ı funkci. Ta v rámci svého bˇehu m˚uˇze vyvolat jedno ˇ

ci v´ıce systémových volán´ı. Pˇrebere jejich hodnoty, které m˚uˇze dále spracovat a výsledek navrac´ı uˇzivatelské aplikaci. Tento princip usnadˇnuje psan´ı uˇzivatelských program˚u [6].

Posledn´ı moˇznost´ı jak vyvolat pˇrechod mezi reˇzimi je vyuˇzit´ı pˇreruˇsen´ı.Pˇreruˇsen´ıslouˇz´ı pˇredevˇs´ım pro komunikaci jádra s hardwarem. Hardwarové zaˇr´ızen´ı vyvolá elektrický signál. Ten pˇreruˇs´ı bˇeh procesoru a spust´ı obsluˇznou rutinu pro dané pˇreruˇsen´ı. Pˇri tomto pˇreruˇsen´ı docház´ı k záloze stavu systému (registr˚u, zásobn´ıku, atd.). Po dokonˇcen´ı pˇreruˇsen´ı je stav systému obnoven a jeho bˇeh m˚uˇze pokraˇcovat dále.

Pˇreruˇsen´ı se mohou vyskytovat synchronnˇe ˇci asynchronnˇe.Softwarová pˇreruˇsen´ı(nˇekdy nazývanévyj´ımky) vznikaj´ı synchronnˇe v procesoru jako následek vykonávané funkce (napˇr. dˇelen´ı nulou). Hardwarová pˇreruˇsen´ı(pˇreruˇsen´ı) vznikaj´ı asynchronnˇe a slouˇz´ı pˇredevˇs´ım pro komunikaci s periferiemi(disk, s´ıt’, atd.). Nˇekterá pˇreruˇsen´ı lze po urˇcitou dobu za-maskovat a ignorovat jejich pˇr´ıjem. Jiná jsou nemaskovatelná a tato operace pro nˇe nen´ı povolena [7, 5].

Jednotliv´a komunikaˇcn´ı rozhrann´ı jsou zobrazena na obr. 1.4.

G N U /L in ux U živ ate ls ký p ro sto r P ro sto r já dr a Uživatelské aplikace

GNU C knihovna (glibc)

Rozhraní systémových volání

Jádro

Rozhraní pro obsluhu výjimek a přerušení

Hardware

Obr´azek 1.4: J´adro Linux jeho rozhran´ı a reˇzimy

Za bˇehu Linuxu se tedy kaˇzd´y procesor nach´az´ı v jednom z tˇechto tˇr´ı stav˚u [6]:

• V uˇzivatelském reˇzimu vykonává kód uˇzivatelského procesu.

• V reˇzimu jádra vykonává kód jádra ve prosbˇech bˇeˇz´ıc´ıho procesu. Po spuˇstˇen´ı syst´ emo-vého volán´ı a pˇrechodu do reˇzimu jádra.

(14)

• V reˇzimu jádra pˇri obsluze pˇreruˇsen´ı. Zde nen´ı spˇraˇzen s ˇzádným uˇzivatelským pro-cesem.

1.4 Implementace syst´

emov´

ych vol´

an´ı

V Linuxu jsou systémová volán´ı realizovaná jako softwarové pˇreruˇsen´ı s identifikaˇcn´ım ˇ

c´ıslem 126 (0x80 hexa). Pˇri provádˇen´ı systémových volán´ı se d˚uleˇzitá data pˇredávaj´ı po-moc´ı registr˚u. D˚uvodem je rychlost a také jednoduchost pˇr´ıstupu. Celý proces vykonán´ı systémového volán´ı je spuˇstˇen, kdyˇz aplikace ˇci knihovna uloˇz´ı do registrueaxidentifikátor systémového volán´ı a vyvolá pˇreruˇsen´ı pˇr´ıkazem int $0x80. V tabulce pˇreruˇsen´ı se na-lezne obsuha pˇreruˇsen´ısystem call (nalezne se odkaz na ni) a zaˇcne se provádˇet jej´ı kód. Nejdˇr´ıve se uloˇz´ı hodnota vˇsech registr˚u, ˇc´ımˇz se uchová stav systému v dobˇe pˇreruˇsen´ı aplikace (tzv. kontext). Z registru eaxse pˇreˇcte ˇc´ıslo systémového volán´ı, otestuje se jeho platnost a vtabulce systémových volán´ıse zjist´ı odkaz na systémovou funkci. Dojde k jej´ımu vyvolán´ı, pˇri nˇemˇz jsou parametry pˇredávány v registrechebx, ecx, edx, esi, edi. Po skonˇcen´ı uloˇz´ı systémová funkce návratovou hodnotu do registrueaxa vrát´ı ˇr´ızen´ı obsluˇzné rutinˇe. Ta obnov´ı kontext systému a vrát´ı ˇr´ızen´ı aplikaci. Celou ˇcinnost znázorˇnuje obr. 1.5.

Aplikace nebo knihovna

Obsluha přerušení pro system_call

(id volání v reg. eax)

0x80 system_call … 0x01 debug 0x00 divide_error Tabulka přerušení ... 2 sys_fork 1 sys_exit 0 sys_restart_syscall Tabulka systémových volání

int 0x80

Systémová funkce

● Parametry v reg.: ebx, ecx, edx, esi, edi

● Vrací hodnotu v reg.: eax

idtr sys_call_table

(symbol)

Registr

(15)

Kapitola 2

Reprezentace a spr´

ava prostˇ

redk˚

u

C´ılem této kapitoly je obeznámit ˇcténáˇre se základn´ımi principy reprezentace a správy prostˇredk˚u v prostˇred´ı operaˇcn´ıch systém˚u GNU/Linux. Budou zde vysvˇetleny základn´ı principy, na kterých stav´ı ostatn´ı kapitoly této práce. Tyto informace jsou nezbytné pˇri tvorbˇe rootkit˚u a jejich detektor˚u.

2.1 Reprezentace a spr´

ava proces˚

u

Tato kapitola pop´ıˇse zp˚usob jakým jsou reprezentovány a spravovány procesy uvnitˇr jádra operaˇcn´ıho systému. Budou zde popsány i základn´ı pojmy z této oblasti.

2.1.1 Z´akladn´ı pojmy

Nejdˇr´ıve se seznám´ıme se základn´ımi pojmy souvisej´ıc´ımi se správou proces˚u. S po-jmemprogram jsme se jiˇz setkali v pˇredchoz´ı kapitole 1.1. Program je posloupnost instrukc´ı uloˇzená v takové formˇe, které je schopen rozumˇet poˇc´ıtaˇc. Aby mohl takový program bˇeˇzet, mus´ı být jeho kód um´ıstˇen v operaˇcn´ı pamˇeti poˇc´ıtaˇce.

Proces je v podstatˇe bˇeˇz´ıc´ı program a s n´ım souvisej´ıc´ı dynamické datové struktury uloˇzené v pamˇet’ovém prostoru jádra. Neplat´ı, ˇze by se k jednomu programu musel vázat vˇzdy jeden proces. Ve skuteˇcnosti m˚uˇze bˇeˇzet v´ıce proces˚u vykonávaj´ıc´ıch jeden a ten stejný program (napˇr. v´ıcekrát spust´ıme stejný textový editor). Program také m˚uˇze pˇri svém bˇehu vyuˇz´ıvat v´ıce proces˚u, ˇcehoˇz se ˇcasto vyuˇz´ıvá, pokud program potˇrebuje vykonat v´ıce ˇ

cinnost´ı souˇcastnˇe1.

Bˇeˇzné procesy vyuˇz´ıvaj´ı za svého bˇehu jedno vlákno ˇr´ızen´ı. Jde o tzv. jednovláknové procesy. S kaˇzdým procesem souvis´ı zdroje jako napˇr. kód uloˇzený v pamˇeti, globáln´ı data, otevˇrené soubory, zásobn´ık a registry. Pokud chce program souˇcasnˇe provédˇet v´ıce ˇ

c´ınnost´ı, mus´ı vytvoˇrit v´ıce jednovláknových proces˚u. Modern´ı operaˇcn´ı systémy dispo-nuj´ı prostˇredky pro poskytován´ı tzv. v´ıcevláknových proces˚u. Takové procesy obsahuj´ı v´ıce vláken pro ˇr´ızen´ı svého chodu. Kaˇzdé vlákno bˇeˇz´ı samostatnˇe2, obsahuje sv˚uj vlastn´ı zásobn´ık ˇ

ci sadu registr˚u. Sd´ılý ale stejný kód a nˇekteré zdroje (napˇr. globáln´ı data ˇci otevˇrené sou-bory), coˇz jim umoˇzˇnuje mezi sebou velmi rychle komunikovat. D´ıky sd´ılen´ı prostˇredk˚u se

1_Pˇ_{r´ıkladem m˚}_uˇ_{ze b´}_{yt server. Jeden proces naslouch´}_{a na urˇ}_cit´_{em portu a pro obsluhu kaˇ}_zd´_{eho pˇ}_ripojen´ı

vytvoˇr´ı nov´y proces. M˚uˇze tedy souˇcasnˇe obsluhovat v´ıce poˇzadavk˚u i ˇcekat na nov´a pˇripojen´ı.

(16)

Vlákno Zásobník Registry Data Kód Soubory Proces s jedním vláknem Vlákno Registry Data Kód Soubory Zásobník Zásobník Zásobník Registry Registry Proces s více vlákny

Obr´azek 2.1: Deskriptor procesu a seznam task list

s vlákny efektivnˇe manipuluje a ˇsetˇr´ı se pamˇet’ poˇc´ıtaˇce. Proto jsou nˇekdy nazývána od-lehˇcené procesy. Linux je implementuje a zacház´ı s nimi stejnˇe jako s procesy. Rozd´ıl mezi procesy s jedn´ım a v´ıce vlákny je zobrazen na obr. 2.1 [1].

2.1.2 Reprezentace proces˚u

Základn´ı datovou strukturou kaˇzdˇeho procesu jestruct task struct, která uchovává vˇsechny potˇrebné informace o daném procesu. Tato struktura je nazývána deskriptor pro-cesu. Popisovaˇce vˇsech proces˚u jádro sdruˇzuje v obousmˇernˇe vázaném seznamu zvaném

task list. Tyto základn´ı struktury a jejich vztah lze vidˇet na obr. 2.2. Popisovaˇc procesu je pomˇernˇe rozsáhlou strukturou obsahuj´ıc´ı velké mnoˇzstv´ı informac´ı jako napˇr´ıklad [4]:

• Základn´ı informace nutné pro bˇeh procesu.PID, signály ˇcekaj´ıc´ı na obsluhu, odkazy na rodiˇce, priority procesu, jeho stav apod.

• Informace o alokované virtuáln´ı pamˇeti a uˇz´ıvané soubory (soubor s binárn´ım kódem, informace souborového systému uˇz´ıvaných soubor˚u).

• Data potˇrebná pro plánován´ı. Tˇr´ıdu plánovaˇce a sched entity(viz kapitola 2.1.4), r˚uzné statistiky atd.

• Opr´avnˇen´ı souboru, identifikaˇcn´ı ˇc´ısla uˇzivatele a skupiny.

• Informace o vláknech uˇz´ıvaných procesem, data potˇrebná pro spolupráci s dalˇs´ımi procesy aj.

Mnoho z tˇechto poloˇzek nen´ı pˇr´ımo souˇcást´ıtask struct, ale jsou uchovány v dalˇs´ıch strukturách provázaných pomoc´ı odkaz˚u.

V dˇr´ıvˇejˇs´ıch verz´ıch Linuxu (pro architektury x86) byla strukturatask structuloˇzena vˇzdy na koncijádrového zásobn´ıku kaˇzdého procesu. V dneˇsn´ı dobˇe se na tomto m´ıstˇe m´ısto n´ı ukládá struktura struct thread info, jenˇz poté natask structodkazuje. Pˇri progra-mován´ı modul˚u jádra máme k dispozici vˇzdy pˇr´ıstup k poloˇzce thread info aktuáln´ıho

(17)

task_struct 1 task_struct 2 task_struct 3 task_struct n

task_struct

unsigned long state; int prio;

unsigned long policy; struct task_struct *parent; pid_t pid;

...

task list

Obsahuje

Deskriptor procesu

Obr´azek 2.2: Deskriptor procesu a seznam task list

procesu skrze funkci current thread info(). Pokud chceme z´ıskat deskriptor aktu´aln´ıho

procesu, je to moˇzn´e skrze pˇr´ıkaz current threat info()->task. Protoˇze je tato operace ˇ

casto vyuˇz´ıvána, existuje pro ni makro current. Ukázka popisovaných poloˇzek a z´ıskán´ı pˇr´ıstupu k nim je znázornˇena na obr. 2.3 [6].

2.1.3 Zivotn´ı cyklus procesuˇ

Tvorba nov´ych proces˚u v Linuxu prob´ıh´a ve dvou kroc´ıch [6, 4]:

init

cron

terminal firefox

csh bash

Obr´azek 2.4: Hiearchie proces˚u.

1. Vytvoˇren´ı identické kopie aktuáln´ıho procesu – Je provádˇeno pomoc´ı volán´ı funkce

fork(). Tato funkce alokuje potˇrebné da-tové struktury jako jádrový zásobn´ık procesu,

task struct a threat info. Jejich hodnoty

nastav´ı identicky k aktu´aln´ımu procesu.

Na-stav´ı se údaje, jenˇz mus´ı být jedineˇcné pro kaˇzdý proces jako pid. Duplikuj´ı ˇci sd´ılý se

zdroje (jako napˇr. adresov´y prostor procesu,

sd´ılené otevˇrené soubory, informace soubo-rového systému apod.). Vlákna tyto zdroje ty-picky sd´ılý, jinak jsou vˇetˇsinou poˇr´ızeny kopie (viz copy-on-write dále v kapitole). Nakonec je proces spuˇstˇen.

2. Nahrán´ı nového kódu a jeho spuˇstˇen´ı – Nový proces volá funkci exec(), ˇc´ımˇz do svého pamˇet’ového prostoru nahraje nový kód a spust´ı jeho provádˇen´ı.

(18)

Nejvyšší adresa Ukazatel zásobníku (stack pointer) Začátek zásobníku thread_struct S m ěr rů stu z ás ob ník u Nejnižší adresa

Jádrový zásobník každého procesu

thread_info

struct task_struct *task; __u32 flags; __u32 status; ... Obsahuje Odkazuje task_struct ... current_thread_info(); Získáme current_thread_infor()->task; Získáme current; Získáme

Obrázek 2.3: Základn´ı struktury proces˚u a z´ıskán´ı pˇr´ıstupu k nim.

Jak jde vidˇet, nový proces vzniká vˇzdy z jiného, jiˇz bˇeˇz´ıc´ıho procesu. T´ım vzniká stro-mová hiearchie rodiˇc–potomek, jenˇz je zobrazena na obr. 2.4. Proces, který vytvoˇril nový proces, je nazývánrodiˇc. Novˇe vzniklý procespotomek. Procesy vzniklé ze stejného procesu jsou zvány sourozenci. Na vrcholu hiearchie stoj´ı proces init, jenˇz je spuˇstˇen jiˇz bˇehem zavádˇen´ı operaˇcn´ıho systému [4].

Tradiˇcnˇe jsou po volán´ı fork() vˇsechny zdroje rodiˇce duplikovány a jejich kopie je pˇredána potomkovi. ˇCasto je po této operaci okamˇzitˇe volán exec(). V takovém pˇr´ıpadˇe docház´ı ke zbyteˇcné kopii dat rodiˇce, které jsou ihned pˇrepsány. Tento problém se ˇreˇs´ı

pomoc´ı pˇr´ıstup copy-on-write. Data nejsou potomkovi kop´ırov´ana, ale pouze nazd´ılena v

reˇzimu pro ˇcten´ı. Ke kopii docház´ı aˇz tehdy, kdyˇz potomek zaˇsle pˇr´ıkaz pro zápis do je-jich oblasti. Pokud je tedy okamˇzitˇe po fork() volán exec(), nedocház´ı ke zbyteˇcnému kop´ırován´ı dat, ale jsou ihned nahrána nová. Této technologii nepodléhá tabulka stránek a deskriptor procesu, který je duplikován vˇzdy [6].

Za svého ˇzivota proces procház´ı r˚uznými stavy znázornˇenými na obr. 2.5 [6]:

• RUNNING – Proces je spuˇstˇen a bˇeˇz´ı, nebo ˇcek´a ve frontˇe, neˇz mu bude pˇridˇelen procesor.

• INTERRUPTIBLE– Proces je uspán a ˇceká na výskyt urˇcité události ˇci na pˇr´ıjem signálu.

• UNINTERRUPTIBLE– Proces je uspán a probud´ı se pouze pˇri výskytu specifické události (signál jej neprobud´ı).

Proces je ukonˇcen zavolán´ım systémového volán´ıexit(), pˇrijet´ım signálu ˇci vyj´ımky, jenˇz nelze obslouˇzit ˇci ignorovat. Nastav´ı se do zvláˇstn´ıho stavu ZOMBIE, v nˇemˇz ˇceká,

(19)

RUNNING (připravený ale ještě neběží) RUNNING (běžící) INTERRUPTABLE nebo UNINTERRUPTIBLE (čekající) Vytvoření

nového procesu Proces je zrušen

fork() schedule() nebo context_switch() schedule() (přepnut kvůli procesu s vyšší prioritou) do_exit()

Proces je uspán a čeká na specifickou událost Nastala událost

a proces je probuzen

Obr´azek 2.5: Stavy procesu.

neˇz rodiˇc pˇrijme jeho návratový kód. Pokud je rodiˇc ukonˇcen dˇr´ıv neˇz potomek, je novým rodiˇcem automaticky procesinit. Potom jsou odstranˇeny vˇsechny nesd´ılené datové poloˇzky a uvolnˇeno pid procesu [6].

2.1.4 Pl´anov´an´ı proces˚u

Aby mohl proces vykonávat sv˚uj kód, mus´ı mu být pˇridˇelen procesor. V dneˇsn´ıch systémech je ˇcasté, ˇze bˇeˇz´ı v´ıce proces˚u souˇcasnˇe. Tomuto principu se ˇr´ıká multitasking. Procesy ˇci vlákna se mus´ı o procesor dˇelit neboli mus´ı sd´ılet ˇcas procesoru. Odebrán´ı pro-cesoru jednomu procesu a pˇridˇelen´ı druhému se nazývá pˇrepnut´ı kontextu. Tuto ˇcinnost ˇr´ıd´ıplánovaˇc na základˇe svéhoplánovac´ıho algoritmu. Plánovaˇc zacház´ı s procesy a vlákny stejným zp˚usobem. Proto se nˇekdy souhrnˇe nazývaj´ı term´ınemúloha 3_.

Z hlediska zp˚usobu, jakým je soubˇeˇzného provádˇen´ı úloh dosaˇzeno, dˇel´ıme multitasking do dvou skupin [6]:

• Kooperativn´ı multitasking– Procesu nen´ı odebrán procesor dokud se k tomu sám nerozhodne. ˇCinnosti, kdy se proces sám vzdá procesoru se ˇr´ıká yielding. V dneˇsn´ı dobˇe se témˇeˇr nepouˇz´ıvá. Vyuˇz´ıvali jej dˇr´ıvˇejˇs´ı verze Windows ˇci Mac OS.

• Preemptivn´ı multitasking – Plánovaˇc rozhoduje, kdy bude procesu odebrán pro-cesor. Aktu nedobrovolného odebrán´ı procesoru a pˇriˇrazen´ı jej novému procesu se ˇr´ıká preempce. Doba po které dojde k preempci se nazývá timeslice. Tohoto pˇr´ıstupu vyuˇz´ıvá Linux i vˇetˇsina modern´ıch operaˇcn´ıch systém˚u.

Pro kaˇzdý proces je výhodný jiný zp˚usob pˇridˇelován´ı procesoru. Proto se procesy ˇcasto rozdˇeluj´ı do následuj´ıc´ıch kategori´ı [7].

3

Pro popis plánován´ı budu v této kapitole vyuˇz´ıvat sp´ıˇse pojmu proces, který bude ve skuteˇcnosti

(20)

• I/O-bound – Tráv´ı spoustu ˇcasu ˇcekán´ım na dokonˇcen´ı vstupnˇe/výstupn´ı operace (napˇr. stisk klávesy uˇzivatelem). Pokud by jim byl pˇridˇelován procesor pˇr´ıliˇs ˇcasto, trávil by spoustu svého ˇcasu ˇcekán´ım. Na druhou stranu je u tˇechto proces˚u potˇreba okamˇzité interakce. Pˇr´ıkladem m˚uˇze být textový editor.

• CPU-bound (processor-bound) – Provád´ı sloˇzité algoritmy a výpoˇcty na které potˇrebuj´ı spoustu ˇcasu procesoru (napˇr. dekodér videa).

Nejedná se vˇsak o pˇr´ıliˇs striktn´ı zp˚usob dˇelen´ı. Mnohé procesy projevuj´ı chován´ı z obou dvou skupin souˇcasnˇe nebo v urˇcitých ˇcástech svého bˇehu se chovaj´ı jako I/O-bound a v jiných jako CPU-bound. Tento zp˚usob dˇelen´ı poukazuje sp´ıˇse na kriteria, které mus´ı být v plánovac´ım algoritmu zohlednˇena.

Nejjednoduˇzˇs´ı principy plánovac´ıch algoritm˚u jsou zaloˇzeny na udˇelován´ı priorit pro-ces˚um. Proces s vyˇsˇs´ı prioritou dostává pˇrednost pˇred procesy s niˇzˇs´ı prioritou. Procesy mohou být vyb´ırány na základˇe dvou plánovac´ıch algoritm˚u:

• FCFS(First Come, First Serve)– Procesy se ˇrad´ı veFIFO frontách4. Pˇri spuˇstˇen´ı se procesy ˇrad´ı na konec fronty. Pˇri pˇrep´ınán´ı kontextu je spuˇstˇen proces ze zaˇcátku fronty. Tento proces bˇeˇz´ı dokud se sám nevzdá procesoru nebo dokud nezaˇcnˇe ˇcekat na událost.

• Round-robin – Princip je podobný FCFS, akorát je jeˇstˇe vyuˇz´ıván timeslace. Po jeho uplynut´ı tedy dojde k preempci.

Pˇri realizován´ı priorit dostávaj´ı procesy s vyˇsˇs´ı prioritou ve frontách pˇrednost pˇred procesy s niˇzˇs´ı prioritou. Druhou a ˇcastˇejˇs´ı moˇznost´ı je vyuˇz´ıván´ı pol´ı front. Kaˇzdá fronta má jinou prioritu, která odpov´ıdá prioritám proces˚u, které se do n´ı chtˇej´ı zaˇradit. Plánovaˇc procház´ı fronty dle jejich priorit a zastav´ı se u prvn´ı zaplnˇené fronty.

Linux vyuˇz´ıvá dvou typ˚u priorit.Bˇeˇzné procesyvyuˇz´ıvaj´ı hodnotynice, která je z rosahu od -20 do 19. ˇC´ım niˇzˇs´ı hodnota nice t´ım vyˇsˇs´ı je priorita procesu. Druhým typem je

real-time priorita, jenˇz vyuˇz´ıvá rozsahu od 0 do 99 kde vyˇsˇs´ı hodnotˇe odpov´ıdá vyˇsˇs´ı priorita procesu. Procesy jenˇz tento typ priorit vyuˇz´ıvaj´ı se nazývaj´ıreal-time procesy5 a vˇsechny maj´ı automaticky vyˇsˇs´ı prioritu neˇz bˇeˇzné procesy [6].

Od verze Linuxu 2.6.32 byl do jádra zaˇrazen plánovaˇcCFS (Completely Fair Scheduler). Ten odstranil pole front a m´ısto nich ukládá procesy do strukturyred-black tree(rbtree). Jde o vyváˇzený binárn´ı strom, který ukládá své uzly na základˇe hodnoty kl´ıˇce. Kl´ıˇcem je hod-nota vruntime(Virtual Runtime). Ta se poˇc´ıtá na základˇe doby bˇehu daného procesu vyváˇzenou poˇctem bˇeˇz´ıc´ıch proces˚u. Jakmile má doj´ıt k pˇrepnut´ı kontextu, pˇriˇrad´ı se pro-cesor procesu s nejniˇzˇs´ı hodnotou vruntime, coˇz je nejlevˇejˇs´ı uzel stromu. Jak lze vidˇet,

CFS nevyuˇz´ıvá pˇr´ımo priorit. Priority ovlivˇnuj´ı nár˚ust hodnotyvruntime. Procesy s výˇsˇs´ı prioritou zvyˇsuj´ıvruntime pomaleji, s niˇzˇs´ı prioritou ˇcastˇeji [6].

Plánovaˇc v Linuxu jemodulárn´ıˇcehoˇz je dosahováno na základˇetˇr´ıd plánovaˇc˚u. Kaˇzdá tˇr´ıda plánovaˇce vyuˇz´ıvá jiného algoritmu plánován´ı a má jinou prioritu. Hlavn´ı plánovaˇc

4

FIFO(First In First Out) – Procesy jsou ˇrazeny ve frontˇe v poˇrad´ı, v jak´em do n´ı vstupuj´ı. Z jednoho

konce do fronty vstupuj´ı, z druh´eho konce jsou vyb´ır´any

5

Real-time procesy nejsou bˇeˇznˇe pˇr´ıliˇs vyuˇz´ıvány. Vyuˇz´ıvá se jich sp´ıˇse ve vestavˇených systémech, robotice

(21)

iteruje nad vˇsemi tˇr´ıdami plánovaˇc˚u v poˇrad´ı dle jejich priorit. Prvn´ı tˇr´ıda, jenˇz má proces pˇripravený k bˇehu je spuˇstˇena. CFS napˇr´ıklad obsluhuje bˇeˇzné procesy. Real-time procesy jsou obvykle obsluhovány tˇr´ıdami plánovaˇc˚u pracuj´ıc´ıch na principu algoritm˚u FCFS ˇci

round-robin, jenˇz maj´ı vyˇsˇs´ı prioritu [6].

2.2 Reprezentace a spr´

ava soubor˚

u

V této ˇcásti práce budou vysvˇetleny pojmy z oblasti reprezentace a správy soubor˚u. Zvláˇstn´ı pozornost bude vˇenována virtuáln´ımu souborovému systému.

Za bˇehu m˚uˇze aplikace uchovávat data ve svém pamˇet’ovém prostoru. Velikost tohoto prostoru je vˇsak znaˇcnˇe omezená. Nav´ıc po ukonˇcen´ı aplikace jsou data ztracena. Tyto problémy jsou ˇreˇseny pomoc´ı souborového systému.Souborý systémumoˇzˇnuje permanentn´ı uchován´ı dat na disku ˇci jiném médiu. Soubor je nejmenˇs´ı jednotkou, jenˇz m˚uˇze být na tˇechto nosiˇc´ıch uloˇzena. V dneˇsn´ı dobˇe je na disk bˇeˇznˇe ukládáno velké mnoˇzstv´ı soubor˚u. Aby se mezi nimi zachoval pˇrehled, byl zaveden systém adresáˇr˚u.Adresáˇr (sloˇzka) je entita, která umoˇzˇnuje uchovávat jednotlivé soubory nebo jiné adresáˇre. T´ım vzniká hiearchie adresáˇr˚u a soubor˚u znázornˇena na obr. 2.6 [2].Souborový systémseskupuje vˇsechny soubory a adresáˇre. Umoˇzˇnuje jejich vytváˇren´ı, mazán´ı, modifikaci a jiné operace.

/ bin home dev pepa radek soubor.txt Kořenový adresář Cesta k souboru: /home/radek/soubor.txt

Obr´azek 2.6: Hiearchie soubor˚u a cesta k souboru.

V Linuxu je adresáˇr implementován jako speciáln´ı typ souboru. Koˇrenem stromové hiearchie je speciáln´ı adresáˇr

”/“. Kaˇzdý adresáˇr lze identifikovat na základˇe cesty. Ta odpov´ıdá cestˇe od koˇrenového adresáˇre k c´ılovému adresáˇri ˇci souboru. Jednotlivé uzly jsou

oddˇeleny znakem

”/“ (viz obr. 2.6).

2.2.2 Virtuáln´ı souborový systém

Virtuáln´ı souborový systém (Virtual Filesystem – VFS) je podsystémem jádra, který tvoˇr´ı mezivrstvu mezi uˇzivatelskými procesy a implementac´ı souborového systému (obr. 2.7). Poskytuje jednotné rozhran´ı systémových volán´ı, pomoc´ı kterých mohou tyto procesy ko-munikovat s r˚uznými typy souborových systém˚u uloˇzených na r˚uzných medi´ıch [4].

(22)

Aplikace Aplikace Aplikace

Standardní knihovna (libc)

Virtuální souborový systém (VFS)

Uživatelský prostor Prostor jádra Rozhranní systémových volání

Ext3 Reiserfs Ext2

Obrázek 2.7: Pozice virtuáln´ıho souborového systému.

Souborové systémy m˚uˇzeme rozdˇelit do dvou základn´ıch skupin [4]:

• Diskové – Klasické souborové systémy uloˇzené na pevných disc´ıch poˇc´ıtaˇce ˇci na r˚uzných pˇrenosných medi´ıch (CD, DVD, flash disk, aj.). Pˇr´ıkladem jsou souborové

syst´emyNTFS, ext4, FAT32, ISO 9660 aj.

• S´ıt’ové– Umoˇzˇnuj´ı pˇr´ıstup k dat˚um uloˇzených na jiném zaˇr´ızen´ı skrze poˇc´ıtaˇcovou s´ıt’. Patˇr´ı mezi nˇe NFS, SMB a dalˇs´ı.

• Speciáln´ı – Virtuáln´ı systémy, vytvoˇrené v jádˇre, které poskytuj´ı jednoduché ko-munikaˇcn´ı rozhran´ı aplikac´ım ˇci uˇzivatel˚um. Do této skupiny patˇr´ı napˇr. sysfs ˇci

procfs.

2.2.3 Reprezentace VFS

VFS je implementován pomoc´ı objektovˇe orientovaného pˇr´ıstupu. Jednotlivé objekty jsou reprezentovány pomoc´ı dvou základn´ıch struktur. Prvn´ı uchovává ˇclenská data ob-jektu. Jeho metody jsou uloˇzené ve zvláˇstn´ı struktuˇre, na kterou datová struktura odka-zuje. Struktura s metodami je nazývánatabulka operac´ıa obsahuje ukazatele na jednotlivé funkce (viz obr. 2.8).

file …

struct file_operations *f_op;

...

file_operations …

int(*open) (struct inode *, struct file *); ssize_t (*read) (...);

size_t (*write) (...);

...

int open (struct inode *i, struct file *f) {

... }

(23)

VFS tvoˇr´ı n´asleduj´ıc´ı z´akladn´ı sada objekt˚u [6]:

• Superblock– Reprezentuje konkrétn´ı souborový systém. Odpov´ıdá superbloku sou-borového systému (kontroln´ımu bloku), který bývá uchován na speciáln´ım sektoru disku. Pro jiné neˇz diskové souborové systémy (napˇr. speciáln´ı souborové systémy -procfs) je superblok generován a uloˇzen v pamˇeti. Realizuje jej strukturasuper block. Uchovává informace jako napˇr. typ souborového systému, pˇr´ıpojný bod, maximáln´ı

velikost souboru, bezpeˇcnostn´ı informace aj. Jeho tabulka operac´ısuper operations

poskytuje funkce pro pˇripojen´ı ˇci odpojen´ı souborového systému, jeho zmrazen´ı ˇci jiné. Objekt vzniká pˇri pˇripojen´ı souborového systému a zaniká pˇri jeho odpojen´ı.

• Inode– Obsahuje veˇskeré metainformace, které jádro potˇrebuje k manipulaci se sou-borem. Unixové souborové systémy oddˇeluj´ı soubory a jejich metainformace, které ukládá jakoinody (iuzly) na disku. Jiné souborové systémy uchovávaj´ı tyto informace jako souˇcást souboru ˇci ve speciáln´ı databázi na disku. Objekt reprezentuje struk-tura inode. Obsahuje informace jako jsou id vlastn´ıka souboru a skupiny, velikost souboru, ˇcasové údaje (doba pˇr´ıstupu, posledn´ı zmˇeny) aj. Skrze tabulku operac´ı

inode operations poskytuje funkce k vytváˇren´ı a ruˇsen´ı pevných ˇci symbolických odkaz˚u, umoˇzˇnuje pracovat s adresáˇri nebo mˇenit oprávnˇen´ı pˇr´ısluˇsného souboru a mnoho dalˇs´ıch. Ke kaˇzdému souboru, s n´ımˇz se pracuje, je vázán právˇe jeden objekt inode.

• File– Reprezentuje soubor otevˇrený procesem. Jeden fyzický soubor m˚uˇze být otevˇren v´ıce procesy. V takovém pˇr´ıpadˇe vzniká s kaˇzdým otevˇren´ım nový objekt file. Po

uzavˇren´ı souboru objekt zanik´a. Objekt reprezentuje struktura file. Obsahuje

in-formace o aktu´aln´ı pozici v souboru, reˇzimu otevˇren´ı, opr´avnˇen´ı aj. Tabulka operac´ı

file operations obsahuje vˇetˇsinu známých funkc´ı jako otevˇren´ı a zavˇren´ı souboru, ˇcten´ı, zápis, nastaven´ı pozice v souboru aj.

• Dentry – Název je zkratkou pojmu Directory Entry Cache (mezipamˇet’ poloˇzek ad-resáˇre). Objekt kontroluje, zda je cesta validn´ı a procház´ı jej´ı jednotlivé poloˇzky. Umoˇzˇnuje na základˇe této cesty vyhledat pˇr´ısluˇsný objekt inode. Tato vyhledáván´ı si uchovává v mezipamˇeti pro pozdˇejˇs´ı vyuˇzit´ı. Objekt je reprezentován skrze strukturu

dentrya tabulku operac´ıdentry operations. Vznik´a jakmile je potˇreba vyhodnotit cestu, kter´a prozat´ım nen´ı v mezipamˇeti uloˇzena.

Objekt dentry jako jediný nesouvis´ı s konkrétn´ımi daty uloˇzenými na disku. Superblok, iuzly ˇci soubory jsou vˇzdy uloˇzeny permanentnˇe na disku, ale jim odpov´ıdaj´ıc´ı objekty se vytváˇr´ı v pamˇeti poˇc´ıtaˇce aˇz za uvedených situac´ı. Pro kaˇzdý soubor, s n´ımˇz pracuje r˚uzný poˇcet proces˚u, je vytvoˇren vˇzdy jen jeden objekt inode. Narozd´ıl od objektu file, který se vytvoˇr´ı s kaˇzdým otevˇren´ım souboru nový.

Výˇse popsané objekty nejsou jediné, které jádro potˇrebuje pˇri práci s VFS. Pro uloˇzen´ı informac´ı o moˇznostech a schopnostech konkrétn´ıho souborového systému (napˇr. ext4 nebo UDE) vyuˇz´ıvá strukturu file system type. Pro kaˇzdý typ souborového systému existuje právˇe jedna instance dané struktury bez ohledu na to, kolikrát je uloˇziˇstˇe s daným sou-borovým systémem pˇripojeno. S kaˇzdým pˇripojen´ım ale vzniká struktura vfsmount, která poskytuje informace o daném pˇr´ıpojném bodu.

S procesy jsou vázány tˇri datové struktury vztahuj´ıc´ı se k VFS. Prvn´ı jefiles struct, která uchovává deskriptory otevˇrených soubor˚u a pomoc´ı nich pˇristupuje k objekt˚um

(24)

file. Tak´e zajiˇst’uje aby si proces neotevˇrel v´ıce soubor˚u neˇz je povolen´y limit. Druhou je

fs struct, která sdruˇzuje informace o souborovém systému, která jsou pro proces potˇrebná (napˇr. koˇrenový nebo pracovn´ı adresáˇr). Posledn´ı jemnt namespace. Ta m˚uˇze poskytovat kaˇzdému procesu unikátn´ı pohled na celou hiearchii pˇripojeného souborového systému. Kla-sické procesy si vytváˇr´ı vlastn´ı strukturyfile structafs struct. Vlákna tyto struktury typicky sd´ılý. Naopak strukturamnt namespace je typicky vˇsemi procesy a vlákny sd´ılena. Nová se vytváˇr´ı pouze pokud si o ni proces pˇri vytváˇren´ı zaˇzádá.

Nejd˚uleˇzitˇejˇs´ı datové struktury a jejich provázán´ı je znázornˇeno na obr. 2.9.

super_block …

unsigned char s_dirt; struct file_system_type s_type; struct super_operations *s_op; struct list_head s_inodes; struct list_head s_files; ...

Seznam superbloků

inode …

struct list_head i_sb_list; struct list head i_dentry; unsigned long i_ino; struct inode_operations *i_op; struct file_operations *i_fop; ... Seznam inodů inode_operations dentry_operations super_operations file_operations file …

struct file_operations *f_op; struct path f_path; ...

Seznam souborů

dentry …

struct inode *d_inode; struct qstr d_name; struct dentry_operations *d_op; ...

Seznam položek dentry

task_struct …

struct files_struct *files; struct fs_struct *fs; ...

files_struct …

struct files *fd_array[]; ...

fd_array[NR_OPEN_DEFAULT] (pole otevřených souborů

daného procesu)

fs_struct ... f_path.dentry

(25)

2.3 Reprezentace a spr´

ava s´ıt’ov´

ych spojen´ı

C´ılem této kapitoly je seznámit ˇctenáˇre se základn´ımi pojmy s´ıt’ových spojen´ı. Jelikoˇz je tento obor velmi rozsáhlý, budou zde vysvˇetleny pouze pojmy nutné pro pochopen´ı zbylé ˇ

c´asti pr´ace.

Pro realizaci s´ıt’ové komunikaci je zapotˇreb´ı velmi rozsáhle infrastruktury, skládaj´ıc´ı se z mnoha zaˇr´ızen´ı, protokol˚u a aplikac´ı. Pro zjednoduˇsen´ı jej´ıho popisu se zavádˇej´ıvrstvové modely znázornˇené na obr. 2.10:

Fyzická Linková Síťová Transportní Relační Aplikační Prezentační OSI model Vrstva síťového rozhraní Internetová Transportní Aplikační Ethernet, Token Ring, ... IPv4, IPv6 TCP, UDP, ... HTTP, FTP, XMPP, RIP, ... TCP/IP model Rozhraní soketů Uživatelský proces Jádro Síťová karta a její ovladač

Obr´azek 2.10: Vrstvov´e modely

OSI model je sp´ıˇse referenˇcn´ım modelem, kdeˇzto na TCP/IP modelu je v podstatˇe vystavˇen celý Internet. Na obrázku 2.10 jsou znázornˇeny jednotlivé vrstvy tˇechto model˚u a nˇekteré protokoly, které na nich mohou pracovat. Z pohledu této práce je zaj´ımavé, ˇze v jádˇre operaˇcn´ıho systému je implementována funkcionalita vrstvy transportn´ı a interne-tové. Do detail˚u této implementace zab´ıhat nebudeme, sp´ıˇse se zamˇeˇr´ıme na uˇzivatelský pohled na s´ıt’ové komunikace, který je d˚uleˇzitý pro tvorbu rootkit˚u a jejich detektor˚u.

Pˇri vytváˇren´ı s´ıt’ové aplikace v GNU/Linux se vyuˇz´ıvá rozhran´ıBSD Sockets (dále so-kety), znázornˇené na obr. 2.10. Kaˇzdá strana, která chce po s´ıti komunikovat mus´ı vytvoˇrit jeden takový soket. Skrze nˇe je poté komunikace zprostˇredkována. Kaˇzdý soket je jedno-znaˇcnˇe identifikován pomoc´ıIP adresy a ˇc´ısla portu. IP adresa jednoznaˇcnˇe identifikuje poˇc´ıtaˇc v s´ıti6. V dneˇsn´ı dobˇe se vyuˇz´ıvaj´ıIPv4 ˇci IPv6 adresy. ˇC´ıslo portu identifikuje konkrétn´ı aplikaci ˇci sluˇzbu bˇeˇz´ıc´ı na daném poˇc´ıtaˇci. Rozsah ˇc´ısel port˚u je pevnˇe dán od 0 do 65535. Porty od 0 do 1023 jsou tzv.well known ports, které jsou rezervované pro známé sluˇzby. Port od 1024 do 49151 jsou registrované, zbylé se nazývaj´ı dynamické. O správu

6_{Respektive identifikuje rozhran´ı poˇ}_c´ıtaˇ_{ce. Poˇ}_c´ıtaˇ_{c m˚}_uˇ_{ze m´ıt napˇ}_{r. v´ıce s´ıt’ov´}_{ych karet. Kaˇ}_zd´_{e pot´}_{e bude}

(26)

ˇ

c´ısel port˚u se stará organizaceICANN. Nen´ı moˇzné, aby na jedné stanici bˇeˇzelo v´ıce sluˇzeb na stejném portu. Kaˇzdé spojen´ı je identifikované m´ıstn´ı adresou a portem (lokáln´ı soket), vzdálenou adresou a portem (vzdálený soket) a vˇetˇsinou i typem protokolu transportn´ı vrstvy (nejˇcastˇeji TCP ˇci UDP). Sokety se daj´ı vyuˇz´ıt i pˇri lokáln´ı komunikaci mezi pro-cesy ˇci s jádrem. T´ımto typem se ale zde nebudeme zabývat. Znázornˇen´ı komunikace pomoc´ı soket˚u s ukázkou adres m˚uˇzete videt na obr. 2.11. Obrázek znázorˇnuje odchoz´ı komunikaci z poˇc´ıtaˇce PC1 do PC2 a jejich adresy.

PC1 (lokální) (vzdálený)PC2 Lokální adresa: IP adresa: 11.12.58.64 Port: 49160 Vzdálená adresa: IP adresa: 11.12.58.73 Port: 51513 S ok e t S ok e t

Obr´azek 2.11: Komunikace pomoc´ı soket˚u a jejich adresy

2.3.2 Reprezentace s´ıt’ov´ych spojen´ı

V této kapitole se bl´ıˇze seznám´ıme se sokety a s t´ım, jakým zp˚usobem jsou informace o s´ıt’ových spojen´ıch reprezentovány uˇzivateli.

Pro realizaci soket˚u se plnˇe vyuˇz´ıvá moˇznost´ı virtuáln´ıho souborového systému a linu-xového pˇr´ıstupu vˇse je soubor. Soket je speciáln´ım typem souboru. Po jeho vytvoˇren´ı je identifikován pomoc´ı ˇc´ıselného deskriptoru, stejnˇe jako bˇeˇzné otevˇrené soubory. Stejnˇe jako s ostatn´ımi soubory se s n´ım i pracuje a stejnˇe je reprezentován v jádˇre. Proces si deskrip-tor soketu uchovává v seznamu deskriptor˚u, skrze který se m˚uˇze dopracovat ke struktuˇre

file. Ta obsahuje odkaz na tabulku operac´ı soubor˚u, která uˇz je samozdˇrejmˇe specifická pro potˇreby s´ıt’ové komunikace. Na soket se m˚uˇze volat systémové volán´ıread()ˇciwrite()

a tak data pˇrij´ımat ˇci zas´ılat po s´ıti. Plat´ı na nˇej tedy vˇsechny poznatky týkaj´ıc´ı se VFS. Jádro poskytuje uˇzivateli informace o s´ıt’ových rozhran´ıch ˇci spojen´ıch skrze speciáln´ı virtuáln´ı souborový systém /proc/net. V tomto systému jsou um´ıstˇeny textové soubory poskytuj´ıc´ı tyto informace a r˚uzné statistiky. Formát tˇechto soubor˚u je vˇetˇsinou ˇcitelný pro ˇclovˇeka, ale také je upraven pro snadné poˇc´ıtaˇcové zpracován´ı. Pˇr´ıklady tˇechto soubor˚u jsou napˇr. souborytcpˇciudpposkytuj´ıc´ı informace o tcp ˇci udp spojen´ı,routeobsahuj´ıc´ı smˇerovac´ı tabulku poˇc´ıtaˇce, wirelessinformuj´ıc´ı o dostupných wifi s´ıt´ıch aj.

Tohoto souborového systému vyuˇz´ıvá ˇrada standardn´ıch linuxových nástroj˚u posky-tuj´ıc´ıch informace o s´ıt’ovém spojen´ı. Jedn´ım z nejpouˇz´ıvanˇejˇs´ıch jenetstat. Jde o pomˇernˇe komplexn´ı nástroj poskytuj´ıc´ı informace o s´ıt’ových spojen´ı, routovac´ıch tabulkách, roz-hran´ıch a jejich statistikách, ˇclenstv´ı v multicastových skupinách aj. Dalˇs´ım nástrojem je napˇr. lsof, který poskytuje informace o souborech otevˇrených procesy. Jelikoˇz je soket speciáln´ım typem souboru, lze takto vypisovat i informace o s´ıt’ových spojen´ı.

(27)

Kapitola 3

Rootkity a metody ´

utok˚

u

Nyn´ı se seznám´ıme s rootkity, jejichˇz analýza byla jedn´ım z stˇeˇzejn´ıch aspekt˚u této práce. Budou vysvˇetleny základn´ı pojmy této oblasti, rozdˇel´ıme si rootkity do nˇekolika kategorii a seznám´ıme se s r˚uznými metodami skrýván´ı zdroj˚u. Veˇskeré zkoumané rootkity a teorie jsou zamˇeˇreny na architekturu i386 ˇci kompatibiln´ı na niˇz bˇeˇz´ı operaˇcn´ı systém

GNU/Linux. Vyuˇzit´ı metod konkr´etn´ımi rootkity a jejich srovn´an´ı naleznete v pˇr´ıloze B.

3.1 Z´

akladn´ı pojmy

Rootkit je sada program˚u, pomoc´ı kterých lze maskovat pˇr´ıtomnost útoˇcn´ıka na kom-promitovaném poˇc´ıtaˇci. Umoˇzˇnuj´ı skrývat útoˇcn´ıkovy zdroje jako napˇr. procesy, soubory ˇ

ci s´ıt’ová spojen´ı. Mohou obsahovat tzv. zadn´ı vrátka, která zajiˇst’uj´ı snadný pˇr´ıstup k na-padené stanici. Rootkit samotný se nesnaˇz´ı poˇskodit c´ılový poˇc´ıtaˇc, ani vˇetˇsinou nezjiˇst’uje citlivé informace o uˇzivatelých, jenˇz jej pouˇz´ıvaj´ı. Jeho c´ılem je skrýt d˚ukazy o vyuˇzit´ı napadeného stroje útoˇcn´ıkem. Útoˇcn´ıci jej vyuˇz´ıvaj´ı v prvn´ı fázi útoku, aby si pˇripravili prostˇred´ı pro zaveden´ı a spuˇstˇen´ı dalˇs´ıch pracovn´ıch nástroj˚u [5].

3.2 Typy rootkit˚

u

V dneˇsn´ı dobˇe existuje celá ˇrada rootkit˚u bˇeˇz´ıc´ıch na r˚uzných operaˇcn´ıch systémech a hardwarových architekturách. V této kapitole si je rozdˇel´ıme podle zp˚usobu, jakým útoˇc´ı na c´ılovou platformu, a m´ıry, jak hluboko zasahuj´ı do operaˇcn´ıho systému. Obecnˇe se dá ˇr´ıci, ˇze ˇc´ım je rootkit zanoˇren v´ıce do systému, t´ım docház´ı k silnˇejˇs´ımu spˇraˇzen´ı s konkrétn´ı architekturou a roste nároˇcnost jeho tvorby. Stejnˇe tak ale roste obt´ıˇznost odhalen´ı takového rootkitu a zdroj˚u, které skrývá, a také rozsah infikován´ı systému [5].

3.2.1 Rootkity bˇeˇz´ıc´ı v uˇzivatelsk´em reˇzimu

Celý rootkit bˇeˇz´ı v uˇzivatelském reˇzimu. Útok vˇetˇsinou spoˇc´ıvá v nahrazen´ı systémových funkc´ı nebo knihoven. Pokud se napˇr´ıklad rootkit snaˇz´ı skrýt útoˇcn´ık˚uv proces, nahrad´ı se systémové funkce jakops, pstree, top, aj. za jejich upravenou verzi, která skrývaný pro-ces nevyp´ıˇse. Tento typ útoku je velmi jednoduchý avˇsak málo efektivn´ı. K naruˇsen´ı útoku uˇzivateli postaˇc´ı nainstalovat své vlastn´ı programy (vlastn´ı verzepsapod.), ˇci pˇreinstalovat ty stávaj´ıc´ı.

Vˇetˇsina program˚u provád´ı svoji ˇcinost skrze systémové knihovny. Nab´ız´ı se tedy moˇznost je infikovat pˇr´ımo a t´ım upravit funkˇcnost vˇsech program˚u, jenˇz je vyuˇz´ıvaj´ı. Pˇreinstalován´ı

(28)

je v tomto pˇr´ıpadˇe neúˇcinné ani instalace vlastn´ıch verz´ı systémových program˚u ˇcasto ne-pomáhá. Záleˇz´ı zda tyto nové programy vyuˇz´ıvaj´ı infikované knihovny. Pokud programy ke své ˇcinnosti knihovny v˚ubec nepouˇz´ıvaj´ı nebo vyuˇz´ıvaj´ı své vlastn´ı, je tento zp˚usob neúˇcinný. Ukázka pr˚ubˇehu poˇzadavku na ˇcten´ı souboru a lokalizace útoku uvedených root-kit˚u je na obr. 3.1. Aplikace read() Knihovna read() wrapper Obsluha přerušení system_call Systémová funkce sys_read()

Uživatelský prostor Prostor jádra

Rootkit Rootkit Rozhraní Systémových volání Tabulka Systémových volání

Obr´azek 3.1: Rootkity v uˇzivatelsk´em reˇzimu

Nejvˇetˇs´ım problémem výˇse uvedených pˇr´ıstup˚u je z´ıskán´ıadministrátorského oprávnˇen´ı, které je pˇri nahrazován´ı systémových program˚u a knihoven potˇreba. K jeho z´ıskán´ı ˇcasto slouˇz´ı odposlechnut´ı hesla, chyba nˇekterých program˚u ˇci sluˇzeb s administrátorskými opr´ av-nˇen´ımi nebo chyba pˇr´ımo v jádˇre systému [5].

3.2.2 Rootkity bˇeˇz´ıc´ı v reˇzimu j´adra

Veˇskeré programy a knihovny, které jsou pro rootkity zaj´ımavé, vyuˇz´ıvaj´ı sluˇzeb jádra. Logickým krokem je tedy infikovat pˇr´ımo jádro a t´ım ovlivnit vˇsechny programy, které s n´ım komunikuj´ı. Takové rootkity pracuj´ı na velmi n´ızké úrovni, d´ıky ˇcemuˇz mohou ovládnout celý systém a tˇeˇzko se odhaluj´ı i odstraˇnuj´ı. D´ıky tomu ˇcasto setrvávaj´ı déle v systému a dávaj´ı tak útoˇcn´ıkov´ı v´ıce ˇcasu k jeho zneuˇzit´ı. Pˇri vytváˇren´ı kódu na takto n´ızké úrovni se ale nevyhneme nutnosti vyuˇz´ıvat mechanism˚u specifických pro danou platformu. Vytváˇr´ı se tedy rootkity, které jsou c´ılené nejen na daný operaˇcn´ı systém (Windows, GNU/Linux, atd.), ale velmi ˇcasto i na urˇcitou verzi jádra a hardwarovou architekturu (i386, amd64 aj.). Operaˇcn´ı systém mus´ı m´ıt nav´ıc k dispozici prostˇredky pro zavádˇen´ı a spouˇstˇen´ı takového kódu, jako maj´ı napˇr´ıklad monolytická jádra s modulárn´ı strukturou (a tedy i Linux) ve formˇe jádrových modul˚u [6, 5].

Dle ´urovnˇe infiltrace rozliˇsujeme tyto tˇr´ıdy napaden´ı:

• Napaden´ı obsluhy pˇreruˇsen´ı – Rootkit zautoˇc´ı jiˇz bˇehem vyvolán´ı pˇreruˇsen´ı. Za-jist´ı, aby byla pro obsluhu pˇreruˇsen´ı vybrána upravená funkce. Ta se postará o skryt´ı ´

utoˇcn´ıkov´ych zdroj˚u.

• Napaden´ı zámˇenou systémové funkce – Útoˇc´ı se na mechanismus systémových volán´ı takovým zp˚usobem, aby byla nakonec vˇzdy vyvolána útoˇcn´ıkova upravená systémová funkce, která skryje utajované zdroje.

(29)

• Napaden´ı systémové funkce – Pˇri tomto útoku se rootkit posune jeˇstˇe dále v ob-sluze systémového volán´ı a zaútoˇc´ı aˇz bˇehem proveden´ı systémové funkce. Dojde tedy k výbˇeru správné funkce, jej´ıˇz proveden´ı je ale ovlivnˇeno rootkitem, a vrac´ı upravené výsledky, které opˇet skryj´ı poˇzadované zdroje.

Uvedené útoky znázorˇnuje obr. 3.2.

Uživatelský prostor Prostor jádra

Napadení obsluhy přerušení

Napadení záměnou systémové funkce

Napadení systémové funkce

Upravená systémové funkce

Aplikace Knihovna Obsluha přerušení

Původní systémové funkce Tabulka přerušení Přesměrování na upravenou systémovou funkcí Aplikační rozhraní knihovny Rootkit

Aplikace Knihovna Obsluha přerušení

Systémové funkce Tabulka přerušení _{systémových volání}Tabulka

Aplikační rozhraní knihovny Rootkit Aplikace Knihovna Původní obsluha přerušení Systémové funkce Přesměrování na upravenou obsluhu přerušení Tabulka systémových volání Aplikační rozhraní knihovny Rootkit Upravená obsluha přerušení

Obr´azek 3.2: Typy napaden´ı v reˇzimu j´adra

3.3 Metody ´

utok˚

u v reˇ

zimu j´

adra

V této kapitole se podrobnˇeji seznám´ıme s metodami skrýván´ı zdroj˚u v operaˇcn´ım systému. Zamˇeˇr´ıme se na metody vyuˇz´ıváné rootkity, které bˇeˇz´ı v reˇzimu jádra. Pokud se

(30)

´

utoˇcn´ıkovi podaˇr´ı takový rootkit pro kompromitovaný poˇc´ıtaˇc vytvoˇrit a nainstalovat, z´ıská t´ım mnohem rozsáhlejˇs´ı a robustnˇejˇs´ı prostˇredky pro skryt´ı své ˇcinnosti.

Aplikace nebo knihovna

Obsluha přerušení pro system_call

(id volání v reg. eax)

0x80 system_call … 0x01 debug 0x00 divide_error Tabulka přerušení ... 2 sys_fork 1 sys_exit 0 sys_restart_syscall Tabulka systémových volání

int 0x80

Systémová funkce

● Parametry v reg.: ebx, ecx, edx, esi, edi

● Vrací hodnotu v reg.: eax

idtr sys_call_table

(symbol)

Registr

Obrázek 3.3: Schéma proveden´ı systémového volán´ı

Uvedené útoky budou m´ıt spoleˇcné nˇekteré rysy. Vˇetˇsina útok˚u spoˇc´ıvá v pˇrepsán´ı od-kazu na funkci (ˇci tabulku funkc´ı) tak, aby byla nakonec vyvolánaútoˇcnikova funkce (upra-vená funkce), která skryje poˇzadované zdroje. Velmi ˇcasto je na konci provádˇen´ı útoˇcn´ıkovy funkce vyvolána p˚uvodn´ı, origináln´ı funkce, aby bylo zaruˇceno origináln´ı chován´ı. Metody se hlavnˇe liˇs´ı t´ım, jak a v jaké fázy systémového volán´ı jsou aplikovány. Pr˚ubˇeh systémových volán´ı byl popsán v kap. 1.4. Pro pˇrehlednost znovu uvedeme schéma pr˚ubˇehu systémového volán´ı (obr. 3.3).

3.3.1 Napaden´ı obsluhy pˇreruˇsen´ı

V tomto pˇr´ıpadˇe rootkit zaútoˇc´ı jiˇz bˇehem výbˇeru rutiny, která obsluhuje pˇreruˇsen´ı. Existuje v´ıce zp˚usob˚u, jak takovýto útok implementovat. Jedn´ım z nich je útok na tabulku pˇreruˇsen´ı. V této tabulce se uprav´ı odkaz na obsluˇznou rutinu pˇreruˇsen´ısystem call tak, aby odkazoval na útoˇcn´ıkovu funkci [8].

Dalˇs´ı moˇznost´ı je napˇr´ıklad zamˇenˇen´ı tabulky pˇreruˇsen´ı. Ukazatel na tuto tabulku je uchován v registru idtr. Pokud se útoˇcn´ıkovi podaˇr´ı zmˇenit obsah tohoto registru m˚uˇze doc´ılit toho, ˇze pˇri pr˚ubˇehu systémového volán´ı bude vyuˇz´ıvána jeho upravená tabulka pˇreruˇsen´ı, která m˚uˇze odkazovat na jeho vlastn´ı obsluˇzné rutiny. Oba typy útoku se velmi podobaj´ı útok˚um vyuˇz´ıvaných pˇri napaden´ı výbˇeru systémové funkce, které budou popsány dále [5].

3.3.2 Napaden´ı výbˇeru systémové funkce

V této kapitole si pop´ıˇseme dva základn´ı zp˚usoby tohoto typu útoku:

1. Utok na tabulku syst´´ emových volán´ı – Jde o jeden z nejstarˇs´ıch a v˚ubec nej-pouˇz´ıvanˇejˇs´ıch metod útok˚u. Uprav´ı se tabulka systémových volán´ı tak, aby

odka-zovala na upravenou systémovou funkci. Ta poté skryje poˇzadované zdroje a na

konci svého bˇehu ˇcasto vyvolá origináln´ı systémovou funkci, aby se zachovala p˚uvodn´ı funkˇcnost. Popisovaný princip je znázornˇen na obrázku 3.4. Dˇr´ıve byl tento typ útoku snaˇzˇs´ı, jelikoˇz byl programátor˚um k dispozici symbolsys call table, pomoc´ı kterého