Сигурнији оперативни системи (8. део) — сигурносни додаци ГНУ/Линукс систему

Аутор: Петар Симовић

Ваш свакодневни линукс вероватно је већ довољно сигуран сам по себи уколико благовремено ажурирате систем и имате добре различите шифре за различите налоге, али свакако да постоје програми који га могу учинити мање безбедним. Програми који се накнадно инсталирају, преузимају са непроверених сајтова на интернету, лоше конфигурисани програми, судо привилегије додељене програмима и корисницима без потребе, отворени портови, неажурирани систем и системски софтвери, као и све већи број вируса и рањивости који се проналазе и објављују за линукс оперативне системе.

Међутим, сигурност линукс система се може значајно унапредити кроз пар додатака за сам кернел такозваним ЛСМ модулима (енг. LSM – Linux Security Modules), и са одређеним системским софтвером за изолацију програма једних од других.

У претходним бројевима већ смо помињали неке од њих, па смо тако у прошлом делу објаснили укратко Грсек (енг. Grsec) и његове модуле PAX и RBAC, а овде ћемо да детаљније опишемо још неке модуле за већу заштиту самог језгра линукс система, поређење заштитних могућности, као и како да их ви употребите на вашем линуксу.

Кернел је за кориснике „невидљиви” део опративног система без графичког интерфејса. То је део оперативног система који се први учитава након бутлоудера (енг. bootloader), и стално остаје у РАМ меморији у којој је заштићен од других програма. Кернел управља хардвером (меморијом, процесором, дисковима, … ), процесима, и осталим есенцијалним компонентама и својствима оперативног система пружајући другим програмима начин приступа уређајима.

Зависно од дистрибуције коју користите имаћете другачији ниво заштите линукс језгра, тј. другачије модуле за заштиту језгра омогућене на систему. Тако на пример стандардни Убунту систем долази са Апармором (енг. AppArmor) омогућеним, док поменути Хедс (енг. HEADS) у прошлом делу долази са Грсек модулом. Сигурносни модули имају улогу осигуравања да до неовлашћеног приступа не дође, а ако и дође због рањивости самог система и програма да штета по остали део система буде најмања могућа тј. да се штета или упад максимално ограничи. Сигурносни модули би требало да осигурају кернел и изолују апликације једне од других, проверавају интегритет система тј. језгра, омогуће контролу над приступом фајловима и програмима.

Правила управљања приступа фајловима у оперативним системима. Обично линукс дистрибуције долазе са системом управљања фајловима заснованим на привилегијама које имају корисници или групе којима корисници припадају. Тако на пример одређени корисник или група може бити власник неког фајла што власнику/цима даје право да тај фајл мењају. Овакав систем се назива DAC (енг. Discretionary access control). Овај систем се примењује на линуксу од шездесетих година и не пружа заштиту од малициозног софтвера или багова.

За разлику од DAC-a постоји и MAC (енг. Mandatory access control) који поред власника имају и полису за фајлове или директоријуме тј. ниво овлашћења чак и над фајловима које сами креирају. Највидљивија разлика је управо у контроли над фајловима, где код DAC-а корисници сами могу да одлучују о сигурносним атрибутима фајлова тј. њиховој доступности, док су код MAC-а сва сигурносна ограничења имплементирана кроз правила и полисе које одређује само администратор. Друга значајна разлика је у томе што код DAC-а корисник са већим привилегијама може да кориснику са мањим додели више привилегије, док код MAC-а то није могуће.

ACL (енг. Access Controll list) је најједноставнији систем који процесима или корисницима додељује одређена права над фајловима ако што су право читања, писања или извршавања. Више корисника могу имати различита права над истим фајлом.

Следећи систем је RBAC (енг. Role Based Access Control) који је сличан као ACL aли дефинише и операције које су дозвољене ACL-ом. Примера ради ACL може дефинисати да одређени корисници могу да едитују фајл, док RBAC има опцију да дефинише шта то конкретно значи у том случају, тј. шта се сме изменити. Овај систем је проширењe ACL-а примењено у великим корпорацијама где постоји потреба да се прецизније регулише ко шта може изменити и како на дељеним фајловима на основу улога (енг. roles) које имају корисници.

ABAC (енг. Attribute-based access control) је нешто компликованији систем који се сматра новом генерацијом система за контролу приступа. Док RBAC примењује улоге које неки корисник има, ABAC примењује систем дефинисања предуслова на основу полиса и улога корисника преко AKO-ONDA (енг. IF-THEN) булових функција. На пример: Ако је корисник у одеђеној групи која има право приступа, и ако је члан одеђеног одељења у компанији, може приступити са одеђеним предефинисаним привилегијама фајлу само током радног времена.

Више можете прочитати на Википедији или са следећег линка.

Грсекјурити (енг. Grsecurity) – или Грсек служи генералној намени, штити систем који се повезује са несигурним системима преко мреже тј. интернета. Најчешћи пример је за додатну заштиту веб сервера и примењује MAC систем приступа фајловима.

У себи има PAX модул за раздвајање меморије на ону са подацима која не може да се извршава и ону са програмима за извршавање чиме спречава прекорачење бафера (енг. buffer overflow). PAX садржи и насумичан распоред адресног простора (eng. address space layout randomization) како малициозни програми не би могли да предвиде на којој адреси ће се важни програми наћи у РАМ меморији. У оквиру Пакса је развијен и Стеклик (енг. StackLeak) додатак који настоји заштитити меморију коју користи линукс језгро од напада на стек који се могу десити због начина функционисања резервисања и ослобађања системске меморије.

Други саствани део Грсекa је RBAC (енг. Role Based Access Control) који је задужен за контролу и додељивање привилегија корисницима и процесима. Користи се принцип најмање привилегије (енг. Principle of least privilege) који корисницима и процесима даје минималне неопходне привилегије за рад кроз линукс листу за контролу приступа ACL (енг. Access-control list).

Грсек је додатак (енг. patch) за линукс кернел који кроз поменуте своје делове покушава ограничити и умањити штету коју нападач или злонамерни програм могу учинити уколико дођу на систем преко неког корисника или програма.

СЕЛинукс (енг. SELinux, Security Enchanced Linux) је такође сигурносни модул да линукс кернел који имплементира MAC. Развијен од стране НСА (енг. Nacional Security Agency, USA) и објављен крајем 2000. године под ГПЛ лиценцом. СЕлинукс се подразумевано користи у Андроид оперативном систему од верзије 4.3, док је на Федори омогућен подраумевано, на Дебијану и Убунту долази уз кернел али онемогућен подразумевано па га Селинукс по жељи омогућити. Иако је СЕЛинукс MAC систем, DAC полисе се и даље поштују тј. потребно је буду задовољени услови оба система како би се приступило неком фајлу. СЕЛинукс бележава програме, процесе, фајлове, портове, … лабелама, а онда се кроз правила контролише ко има приступ којим лабелама које на крају примењује кернел на цео систем.

Да ли је СЕЛинукс инсталиран можете проверити командом као и статус полисе:

# getenforce

Могуће га је и инсталирати на линуксу командом (за дебијан, АПТ):

apt install selinux-utils

Апармор (енг. AppArmor) је такође сигурносни модул та линукс кернел који имплементира MAC као додатак DAC-у који већ на линуксу постоји. Апармор и СЕЛинукс имају исти циљ али другачије функционишу па тако Апармор представља алтернативу СЕЛинуксу. Док СЕЛинукс користи лабеле за контролу права приступа, Апармор користи пуне путање (путање од коренског директоријума /). Апармор може бити омогућен у два режима рада, режим за логовање свих акција без превенције тзв. режим за жалбе систему (енг. complaining mode) и режим за превенције. Такође логови могу бити веома корисни не само за администраторе као увид у дешавања, већ и за сам Апармор како би кроз логове у фази тестирања могао да „научи” шта треба да блокира и на основу тога направи профиле које ће користити у моду за превенције помоћу aa-logprof команде са којом Апармор може из логова да унапреди своје профиле функционисања са одобрењем администратора. Више на следећа два линка: линк 1 и линк 2. Апармор је објављен под ГПЛ лиценцом.

Својства Апрамора су:

• може се применити на систем без рестартовања,
• не зависи од фајл система као СЕЛинукс који захтева фајл систем који има могућност лабеловања,
• селективно се може применити на поједине апликације или сервисе,

Статус Апармора се може видети командом:

sudo apparmor_status

или

aa-status

Смек (енг. SMACK – Simplified Mandatory Access Control Kernel) ја као и СЕЛинукс и Апармор MAC сигурносни додатак за језгро са идејом на једноставности и лакоћи употребе дизајниран за уграђене (енг. embedded systems). Имао је примену у Миго (енг. MeeGo) и Тизен мобилним системима, док је Линукс фондација овај систем увела као обавезан за линукс апликације за аутомобиле. Смек попут СЕЛинукса захтева фајл систем са подршком за лабеле или атрибуте, али је мање познат и веома ретко се користи на десктоп и серверским линукс системима. Смек је објављен под ГПЛ2 лиценцом.

Томојо (енг. TOMOYO) је још један додатак заснован на MAC полисама са могућношћу анализирања система и слично Апармору примењује осигуравање процеса на основу апсолутних путањи од коренског директоријума. Томојо је сличан Апармору и по могућности надзора система тј. режим учења у коме се апликацијама дозвољава да се извршавају како хоће како би се из тог понашања извукао шаблон понашања сваке појединачне апликације. Када се направе шаблони онда се може омогућити режим примењивања научених полиса. Постоји могућност да се и прави фајервол за сваку појединачно апликацију као и прављења мамца система за рано откривање могућих напада (енг. honeypot), а Томојо покушава да спречи нападе који се могу реализовати преко прекорачења бафера. Томојо је доступан за инсталацију на Дебијан, Центос и Опенсус (енг. OpenSUSE) система кроз програм tomoyo-tools.

Занимљива илустрација како овај систем функционише преузета са њиховог сајта објашњава режим рада система и апликација које се извршавању без Томојо линукса, онда са њим у режиму учења и на крају у режиму примене научених полиса.

Лоудпин (енг. LoadPin) је посебан ЛСМ специфично намењен за верификацију да су све учитане компоненте језгра (модули, драјеври, фирмвери,…) са истог фајл система, са претпоставком да је са уређаја на комје тај фајл система могуће само читати, а не и писати (енг. read only file sytem). Ова сигурносна преоцедура уведена је како би се за уграђене системе (енг. embedded systems) олакшало осигуравање кернела који може бити смешнен на меморију са које је могуће само читати. Лоудпин је саставни део линукс језгра од 4.7 верзије и подразумевано омогућен, може се онемогућити, а инсталира се једино при компајлирању кернела. Више на следећим линковима: линк 1, линк 2 и линк 3.

Јама (енг. Yama) је ЛСМ који служи да ограничи употребу пи-трејс (енг. ptrace) системског позива и саставни део је линукса од верзије 3.4 језгра. Пи-трејс се може користити од стране програмера да дебагују тј. испитају како њихов програм заправо ради и има ли багова, да ли постоји цурење меморије, али се може и злоупотребити јер омогућава једном процесу да контролише и испита други и тако омогућава рецимо извлачење меморијског садржаја контролисаног процеса. Јама није класичан „пунокрвни” ЛСМ по горе наведеним врстама јер обухвата само ограничавање одеђеног системског позива на DAC системима тј. само је додатни сигурностни механизам за пи-трејс системске позиве. Да ли је Јама омогућена код вас на систему можете проверити командом:

sysctl kernel.yama.ptrace_scope

док је значење вредности следеће:

1. kernel.yama.ptrace_scope = 0 – нормално функционисање пи-трејса, сви процеси се могу дебаговати док имају исти СУИД,
2. kernel.yama.ptrace_scope = 1 – само родитељ процеса може бити дебагован,
3. kernel.yama.ptrace_scope = 2 – sамо админ може користити пи-трејс јер захтева CAP_SYS_PTRACE фунционалност,
4. kernel.yama.ptrace_scope = 3 – ни један процес се неможе дебаговати пи-трејсом, фактички пи-трејс је онемогућен и потребно је рестартовати рачунар да би се применио ефекат.

Јама се користи у Хром или Хромијум интернет прегледачу и њен статус можете проверити одласком на линк chrome://sandbox/. Више на следећа два линка: линк 1 и линк 2.

Сејф-сет-ај-ди (eng. SafeSetID) је додатни модул за језгро који се тиче осигуравања преласка програма између корисника различитих привилегија на систему без ескалације на кориснике већих привилегија. Функција која креира нови процес на систему од постојећег за другог корисника или препушта постојећи процес другом кориснику различитих, обично нижих привилегија, се може злоупотребити да подеси ИД процеса на већи тј. на вредност 0 што је коренски процес (енг. root process). Сејф-Сет-АјДи спречава овај сценарио и настоји да више изолује процесе једне од других и саставни део је линукс језгра од 5.1 верзије. Више на следећем линку.

Локдаун (eng Lockdown) је најновији ЛСМ који би требало да омогући бољу заштиту самог језгра од корисничких програма и приступ који би нападач могао да има уколико се компромитује и рут корисник. Локдаун има и још једну значајну примену, а то је да омогући да верификацију кернала на почетку стартовања рачунара које прегледа Јуефи (енг. UEFI Secure Boot). Тренутна ситуација је таква да рут налог може правити измене кернела, што у принципу нарушава интегритет кернела и Јуефи сигурносне провере. Локдауном ће се рут налогу ограничити приступ, и то кроз један од два режима:

1. Режим интегритета – забрањује рут налогу приступ интерфејсима: /dev/{mem,kmem,port}, /dev/efi_test, и другим начинима на који рут налог може комуницирати са кернелом.
2. Режим поверљивости – је режим интегрита плус још: /proc/kcore, kprobes, коришћење бпф-а да чита садржај РАМ меморије.

Постојање режима поверљивости оправдава се чињеницом да се у меморији рачунара која припада језгру могу наћи поверљиве информације попут енкрипционих кључева који потенцијално могу бити прочитане одстране рут корисника, па је овај вид заштите потребан првенствено за бизнис кориснике који имају потребу да осигурају сервере или своје рачунаре од потенцијалног цурења поверљивих информација у случају компромитовања рут налога. Локдаун је уведен у саставни део од 5.4 верзије линукс језгра али је подразумевано искључен. Више информација на следећим линковима: линк 1, линк 2, линк 3 и линк 4.

Иако је јасно да има више сигурносних решења за наше линукс језгро, може се поставити питање које решење је најбоље. На то је тешко одговорити јер су нека решења прикладнија серверима, нека десктоп корисницима, док су једна једноставна друга компликованија али са више могућности да се добро конфигуришу (или погрешно) ако им се посвети више времена. Друга идеја може бити користити више линукс сигурносних модула што је опет негде могуће а негде бесмислено јер има више веома сличних решења која раде исту ствар. На пример, сасвим је могуће користити грсек и апармор, док је бесмислено комбиновати томојо и апармор. Разлог је једноставан, грсек има сигурносне механизме специфично за сречавање експлоита док апармор ограничава приступе, а апармор и томојо раде скоро исту ствар и то на сличне начине и не допуњују се ни у чему, мада и код грсека и апармора има делова истих механизама ипак има више смисла за комбинацију. Међутим комбинација сигурносних модула је изузетно ретка и тешка поготово за обичне кориснике десктопа, не само зато што би вероватно захтевала да се такав специфичан кернел наменски компајлира, већ и зато што би се сигурносни модули „отимали” око системских ресурса од којих зависе како би нормално функционисали, поготово они који раде на сличним принципима.

Бацили смо поглед на неке од сигурносних модула за линукс језгро и упознали читаоце са начинима заштита. У следећем делу бавићемо се мање познатим пројектима који могу допринети већој безбедности свакодневног коришћења линукса или знатно унапредити критичне операције.