Zabezpečenie SELinuxu: Ovládajte svoj systém Linux do milimetra

Informatec Digital » Zdroje » Zabezpečenie SELinuxu: Ovládajte svoj systém Linux do milimetra

SELinux môže znieť ako technológia vyhradená pre jadrových nadšencov, ale v skutočnosti je to jeden z najvýkonnejších bezpečnostných nástrojov dostupných v Linuxe . Ak spravujete servery, zabezpečenie kontajnerov Docker , cloudovú infraštruktúru alebo dokonca mierne citlivé stolové počítače, pochopenie fungovania SELinuxu predstavuje zásadný rozdiel medzi systémom, ktorý je jednoducho „dobre nakonfigurovaný“, a systémom, ktorý je ťažké kompromitovať, a to aj s zraniteľnosťami typu zero-day.

Napriek svojej povesti „komplikovaného“ systému SELinux ponúka veľmi logický model: definuje, čo môže každý proces robiť a s akými objektmi môže komunikovať, a ak sa niečo odchýli od tohto skriptu, jadro to okamžite zastaví . Namiesto slepej dôvery, že root sa bude správať správne alebo že vaše démony nebudú mať chyby, SELinux vynucuje povinnú kontrolu prístupu, ktorá sa vzťahuje aj na superpoužívateľa, a to pomocou veľmi podrobných označení a politík.

Čo je SELinux a aké problémy rieši?

Security-Enhanced Linux (SELinux) je bezpečnostný modul jadra Linuxu založený na LSM (Linux Security Modules). Pôvodne ho vyvinula NSA v spolupráci so spoločnosťou Red Hat a ďalšími partnermi a od verzie jadra 2.6 je oficiálnou súčasťou jadra. Nie je to samostatná aplikácia, ale skôr rozšírenie jadra, ktoré pridáva systém povinného riadenia prístupu (MAC) a riadenie prístupu na základe rolí (RBAC).

Na rozdiel od klasického diskrečného riadenia prístupu (DAC) v systéme Unix – oprávnenia vlastníka, skupiny, ostatných a rwx – v systéme SELinux nie sú rozhodnutia o prístupe založené na voľbe vlastníka súboru, ale skôr na globálnej politike stanovenej správcom bezpečnosti. DAC je stále prítomný a má prednosť: ak DAC zamietne, SELinux nezasiahne; ale aj keď DAC povolí, SELinux môže operáciu stále blokovať podľa svojej politiky.

Architektúra SELinuxu jasne oddeľuje komponenty: na jednej strane kód jadra, ktorý robí bezpečnostné rozhodnutia , a na druhej strane moduly politík, ktoré definujú, čo je povolené a čo nie. Toto oddelenie umožňuje úpravu pravidiel bez prekompilácie jadra a zefektívňuje počet komponentov, ktoré môžu ovplyvniť bezpečnosť systému.

SELinux bol štandardne prijatý v distribúciách ako Fedora, Red Hat Enterprise Linux, CentOS a Scientific Linux a je tiež hlboko integrovaný do systémov ako Android, kde sa používa na obmedzenie systémových procesov a aplikácií na veľmi špecifické domény. Vo svete BSD a GNU/Linux existujú alternatívy ako AppArmor, TOMOYO a TrustedBSD (na macOS/FreeBSD), ale SELinux vyniká úrovňou granularity, ktorú ponúka nad všetkými systémovými objektmi.

Od DAC k MAC: prečo klasický model už nestačí

V tradičnom unixovom systéme sa model doména-objekt spravuje pomocou DAC: každý súbor alebo zdroj má vlastníka a oprávnenia a každý proces spustený od tohto používateľa môže s týmito zdrojmi robiť čokoľvek . To znamená, že ak démon beží od používateľa root, akákoľvek zneužiteľná chyba môže otvoriť dvere k ovládaniu polovice systému pomocou jeho koreňového kontextu.

Typickými príkladmi sú databázy, ktorých dátové súbory by mali byť manipulované iba prostredníctvom DBMS, ale ktoré sú v skutočnosti čitateľné a modifikovateľné procesmi s koreňovým UID ; alebo kritické démony bežiace s nadmernými oprávneniami. Programovacia chyba, pretečenie vyrovnávacej pamäte alebo zlá validácia vstupu môžu zmeniť službu na diaľnicu k celému systému.

SELinux pridáva nad DAC vrstvu povinnej kontroly prístupu (MAC) . „Povinná“ znamená, že kontrola prístupu je centrálne definovaná správcom prostredníctvom politík a ani používatelia, ani procesy nemôžu tieto pravidlá sami uvoľniť. Operačný systém vynucuje tieto politiky vyhodnotením každej relevantnej operácie jadra predtým, ako ju povolí.

Jadro pomocou LSM hookov dotazuje SELinux pri každom citlivom systémovom volaní (otváranie súborov, vytváranie soketov, pripájanie súborových systémov, komunikácia cez IPC atď.). V každom bode rozhodovania SELinux vyhodnocuje operáciu na základe načítanej politiky a bezpečnostného kontextu subjektu a objektu . Ak politika explicitne neudeľuje povolenie, akcia je zamietnutá bez ohľadu na to, či je proces root alebo nie.

Prevádzkové režimy: vynucovací, tolerantný a zakázaný

SELinux môže fungovať v troch jasne odlišných prevádzkových stavoch, ktoré je dôležité pochopiť, aby sa predišlo prehnaným dychom v produkcii:

• presadzovanieSELinux je povolený a plne presadzuje pravidlá. Všetky akcie, ktoré pravidlá nepovoľujú, sú blokované a zaznamenávané.
• PovoľnýSELinux je aktívny, načíta politiku a označí súborový systém, ale neblokuje Zaznamenáva transakcie iba tak, akoby boli zamietnuté. To je ideálne na ladenie a úpravu politík.
• invalidnýSELinux je vypnutý. Neuplatňujú sa žiadne pravidlá ani sa nevykonáva žiadne označovanie. Systém sa spolieha na klasický model DAC.

Pre rýchle a dočasné zmeny medzi režimami vynucovania a permisívnym sa používa príkaz `setenforce` , kde je režim zadaný ako 0 (permisívny) alebo 1 (vynucujúci). Je dôležité vedieť, že táto zmena je nestála: po ďalšom reštarte sa režim vráti do režimu definovaného v konfigurácii.

Ak potrebujete trvalú zmenu, musíte súbor upraviť. /etc/selinux/config (alebo /etc/sysconfig/selinux v niektorých distribúciách) a upravte hodnotu direktívy SELINUX=disabled|permissive|enforcingZmeny sa použijú pri ďalšom spustení a v mnohých prípadoch budú zahŕňať premenovanie súborového systému.

Aktívny režim môžete skontrolovať pomocou príkazov ako getenforce alebo sestatus . Prvý z nich jednoducho vráti hodnotu Enforcing (Vynucovanie), Permissive (Povoľovanie) alebo Disabled (Zakázané); druhý poskytuje úplnejší súhrn stavu SELinuxu, načítaných politík a aktívnych modulov.

Bezpečnostné kontexty a systém označovania

Srdcom SELinuxu je jeho systém bezpečnostných označení alebo kontextov . Každý súbor, proces, sieťový port, soket, zariadenie atď. má priradený kontext, ktorý popisuje, ako sa dá použiť. Tento kontext sa skladá z niekoľkých polí, ktoré spolu tvoria pohľad SELinuxu na daný objekt.

Všeobecný formát kontextu je user_u:role_r:type_t:level s určitými nuansami v závislosti od politiky (najmä ak sa používa MLS/MCS). Každé pole má špecifický účel: používateľ SELinuxu, rola, typ (nazývaný aj doména, keď sa odkazuje na procesy) a úroveň alebo kategóriu citlivosti.

V praxi je najdôležitejším prvkom typ (tretie pole), pretože prevažná väčšina pravidiel politiky je formulovaná ako vzťahy medzi typmi . Napríklad povolenie procesom typu httpd_t prístupu k súborom označeným httpd_sys_content_t alebo povolenie konkrétnej doméne komunikovať so socketmi označenými http_port_t.

Tieto kontexty sú uložené ako rozšírené atribúty súborového systémuPreto je nevyhnutné používať súborové systémy, ktoré podporujú xattrs (ako napríklad ext4, XFS atď.). V prípade procesov je aktuálny kontext a ďalšie súvisiace kontexty zverejnené prostredníctvom pseudosúborového systému. /proc/<pid>/attr/ v súboroch ako current, exec, fscreate, prev, sockcreate alebo keycreate.

Typické príklady kontextov v systéme s cielenou politikou by boli:

• system_u:object_r:httpd_sys_content_t:s0 pre webový obsah poskytovaný Apache alebo Nginx.
• system_u:object_r:home_user_t:s0 pre domovské adresáre používateľov.
• system_u:system_r:httpd_t:s0 pre vykonávaciu doménu samotného webového servera.

Rozdelenie komponentov kontextu SELinuxu

Keď narazíte na kontext ako unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 , môže sa to zdať ako hieroglyfy, ale každý kus zodpovedá špecifickému konceptu v rámci SELinuxu a jeho referenčnej politiky.

El Používateľ SELinuxu (podľa konvencie s príponou) _uToto nie je to isté ako používateľ Unixu v súbore /etc/passwd. SELinux si udržiava vlastnú databázu používateľov a mapuje ich na používateľov Linuxu. Používateľ SELinuxu môže zoskupiť niekoľko používateľov Unixu, pretože myšlienkou je, aby vrstva MAC bola nezávislá od DAC.

El Rola SELinuxu (s príponou _rToto definuje, aké role môže používateľ alebo doména zaujať. Ak sa používa striktne, nazýva sa to plný RBAC. Väčšina súborových objektov používa rolu object_r, zatiaľ čo roly ako system_r, user_r, staff_r alebo sysadm_r sa aplikujú na procesy v závislosti od bezpečnostného kontextu, ktorý musia zaujať.

El Typ alebo doména SELinuxu (prípona _tV praxi je typ kľúčovým prvkom. Typ opisuje triedu objektu alebo doménu vykonávania procesu. Politika určuje, ktoré interakcie sú povolené medzi typmi: ktoré domény môžu čítať, zapisovať, vykonávať alebo komunikovať s ktorými inými typmi objektov.

Úrovne a kategórie sa používajú, keď sú povolené politiky viacúrovňového zabezpečenia (MLS) alebo viackategóriového zabezpečenia (MCS). Citlivosť je hierarchická (napr. s0, s1 atď.), zatiaľ čo kategórie nie (c0, c1, c2, ...). Vo vysoko kritických prostrediach – napríklad v niektorých vládnych organizáciách – sa používajú na zabezpečenie toho, aby sa údaje mohli čítať iba smerom nadol a zapisovať na rovnakú úroveň alebo nahor , a na izoláciu údajov podľa veľmi špecifických oddielov.

Pravidlá SELinuxu: cielené, prísne, MLS/MCS a modularita

Bezpečnosť vynucovaná systémom SELinux je určená načítanou politikou . Politika je jednoducho rozsiahla sada pravidiel, ktoré popisujú, ktoré domény môžu čo robiť na ktorých typoch, ako aj ďalšie prvky (prechody, pravidlá označovania atď.). Distribúcie zvyčajne obsahujú štandardné politiky, takže nemusíte všetko písať od začiatku.

Najbežnejšia politika sa nazýva cielená . V tomto režime bežia v rámci obmedzených domén iba špecifické procesy – najmä sieťové služby a vysoko rizikové démony ako Apache, Nginx, DNS, proxy, SNMP, syslog atď. Všetky ostatné používateľské procesy bežia v „neobmedzených“ doménach, kde sa v podstate uplatňuje štandardné zabezpečenie systému Linux spolu so zaznamenávaním určitých akcií.

Existuje aj prísna politika , v ktorej sú prakticky všetky procesy obmedzené špecifickou politikou. Je oveľa bezpečnejšia, ale jej údržba môže byť tiež podstatne ťažšia, ak model nie je dobre pochopený, pretože akýkoľvek rozdiel v označovaní alebo pravidlách môže narušiť štandardné pracovné postupy.

Pre prostredia s vysokou úrovňou zabezpečenia existujú politiky MLS/MCS (Multi-Level/Multi-Category Security) , ktoré využívajú citlivosti a kategórie na zavedenie ešte presnejších kontrol. Tieto sú typické pre veľmi prísne vojenské alebo administratívne prostredia a zriedkavo sa používajú mimo špecifických kontextov kvôli ich vysokej operačnej zložitosti.

Moderné politiky sú distribuované modulárnym spôsobom . Namiesto jedného monolitického súboru politík sa pre špecifické služby používajú samostatné moduly, čo výrazne zjednodušuje správu a aktualizácie. Tieto moduly sa spravujú pomocou nástrojov ako semodule a semanage module , ktoré umožňujú inštalovať, odstraňovať, povoľovať alebo zakazovať časti politiky bez toho, aby ste museli zakaždým znova kompilovať celú politiku.

Ako SELinux rozhoduje: subjekty, objekty, triedy a oprávnenia

Keď sa proces (subjekt) pokúša o prístup k zdroju (objektu), SELinux koncepčne kladie otázku: „Môže doména typu X vykonať operáciu Y na objekte typu Z patriacom do triedy C?“ . Odpoveď sa potom hľadá v politike prostredníctvom definovaných pravidiel.

V politikách vynucovania typov (TE), ktoré používa väčšina distribúcií a Android, každý objekt patrí do triedy (súbor, adresár, fifo_file, tcp_socket, process atď.) a politika definuje, aké povolenia sú možné pre každú triedu: čítanie, zápis, spúšťanie, viazanie, pripojenie, getattr, otváranie atď.

Pravidlá TE sú vyjadrené veľmi priamo. Základný príklad by bol:

povoliť httpd_t http_port_t:tcp_socket name_bind;

Toto pravidlo označuje, že procesy v doméne httpd_t môžu vykonávať operáciu name_bind na TCP socketoch označených http_port_t. Tento prístup sa zameriava na typy a triedy objektov, nie na konkrétne cesty , čo zabraňuje prekvapeniam pri presúvaní súborov alebo zmene štruktúry adresárov.

Napríklad v systéme Android sa atribúty SELinux používajú na zoskupovanie typov pod všeobecnejšími označeniami, ako napríklad `appdomain` , takže jedno pravidlo sa môže vzťahovať na viacero domén („untrusted_app`, `isolated_app` atď.) bez opakovania definícií. Makrá ako `rw_file_perms` sa tiež používajú na zoskupovanie niekoľkých bežných oprávnení k súborom a zníženie chýb spôsobených prehliadnutím.

Interné stavy, AVC a register zamietnutí

Keď dôjde k požiadavke na prístup, SELinux najprv konzultuje vyrovnávaciu pamäť Access Vector Cache (AVC) , čo je vyrovnávacia pamäť, ktorá ukladá nedávne rozhodnutia o prístupe, aby sa proces urýchlil. Ak sa rozhodnutie už nachádza vo vyrovnávacej pamäti, použije sa priamo; v opačnom prípade sa dotazuje firewall (vnútorná časť SELinuxu v jadre), ktorý vyhodnotí operáciu na základe politiky a kontextu subjektu a objektu.

Ak neexistuje pravidlo, ktoré by explicitne povoľovalo požadovanú akciu, predvoleným rozhodnutím je odmietnuť . Táto filozofia „predvoleného odmietnutia“ je jedným z pilierov SELinuxu a to, čo mu dáva odolnosť voči chybám konfigurácie, ktoré spôsobujú povolenie.

Keď dôjde k zamietnutiu v režime vynucovania, jadro zaznamená správu typu avc: zamietnuté v systémových protokoloch. V závislosti od distribúcie sa môže zobraziť v /var/log/audit/audit.logv /var/log/messages alebo ich môže zachytiť démon auditd. Tieto správy zahŕňajú kontext procesu (scontext), kontext objektu (tcontext), triedu, požadovanú operáciu a ďalšie údaje veľmi užitočné pre ladenie.

V permisívnom režime je operácia povolená, ale stále sa generuje udalosť avc: denied označená ako permissive=1. Toto je čisté zlato pre vytváranie a úpravu politík, pretože vám umožňuje vidieť, čo by narušilo systém, ak by sa vynucovanie implementovalo bez prerušenia bežnej prevádzky.

Integrácia SELinuxu do distribúcií a Androidu

V ekosystéme serverov a desktopov Linux je SELinux štandardne povolený v... Fedora, RHEL, CentOS a derivátyDebian a Ubuntu poskytujú plnú podporu vo svojich jadrách a balíkoch, hoci aktivácia je zvyčajne voliteľná a vyžaduje inštaláciu balíkov ako selinux-basics, selinux-policy-default a auditd, po ktorej nasleduje globálne preznačenie pomocou fixfiles relabel.

Android pôvodne začlenil SELinux vo verzii 4.3 v permisívnom režime, na čiastočné použitie prešiel vo verzii 4.4 (iba pre kritické domény, ako sú installd, netd, vold a zygote) a plne integrovaný je od verzie Android 5.0 . Politika Androidu sa zameriava na izoláciu aplikácií, systémových služieb a citlivých procesov pomocou typov a atribútov s cieľom minimalizovať dopad kompromitácie na ktorúkoľvek z týchto komponentov.

Android používa koncepty ako typ untrusted_app pre bežné procesy aplikácií, atribúty appdomain na zoskupenie domén aplikácií a kategórie MLS/MCS na izoláciu údajov medzi aplikáciami a medzi fyzickými používateľmi. Toto všetko spolu funguje, aby sa zabránilo úniku napadnutej aplikácie z jej sandboxu, a to aj v prípade, že získa veľmi široké používateľské oprávnenia.

Dôležité: Android zjednodušuje model SELinux ignorovaním používateľov, rolí a rozšírených citlivostí. Existuje iba jeden používateľ SELinuxu (u), dve základné role (r pre subjekty a object_r pre objekty) a citlivosť je vždy s0. Kategórie sú to, čo robí rozdiel pre izoláciu údajov.

Porovnanie s AppArmor a inými LSM

V mnohých diskusiách sa nevyhnutne vynára porovnanie medzi SELinuxom a AppArmorom , keďže oba sú bezpečnostné moduly Linuxu a ponúkajú MAC adresy. Ich prístupy sú však dosť odlišné a stojí za to si to uvedomiť predtým, ako si vyberiete jeden alebo druhý pre svoje prostredie.

SELinux definuje politiku zameranú na objekty a ich typy: každému objektu v systéme (súbory, procesy, sokety, porty, zariadenia, IPC atď.) je priradený štítok. Rozhodnutia o prístupe sa prijímajú na základe kontextu subjektu a objektu bez závislosti od presnej cesty k súboru. Vďaka tomu je systém stabilnejší zoči-voči zmenám štruktúry adresárov alebo alternatívnym zobrazeniam súborového systému (chroot, kontajnery, viazané pripojenia atď.).

AppArmor na druhej strane uplatňuje politiku zameranú na úlohy a cestu. Definuje profily pre každý program, pričom určuje, ku ktorým cestám k súborom, portom atď. má prístup a s akými oprávneniami. Jeho konfigurácia je intuitívnejšia a vo všeobecnosti je užívateľsky prívetivejšia pre administrátorov, ktorí sa nechcú stať expertmi na SELinux, ale jeho ovládanie je o niečo menej granulárne a viac závislé od štruktúry súborového systému.

Oba zdieľajú princíp predvoleného zamietania, ale aplikujú ho odlišne: AppArmor predvolene zamieta iba úlohy, ktoré pokrýva profilmi, zatiaľ čo SELinux v prísnom režime ho rozširuje na celý systém a všetky označené objekty. V dôsledku toho SELinux zvyčajne ponúka hlbšiu úroveň obmedzenia , ale za cenu rozsiahlejšej a komplexnejšej politiky.

Praktické nástroje na správu SELinuxu

Práca so SELinuxom sa spolieha na sériu nástrojov príkazového riadku, ktoré zjednodušujú správu režimov, označovania, booleovských hodnôt a modulov politík. Aj keď sa to na prvý pohľad môže zdať ako ohromujúci arzenál, niekoľko nástrojov pokrýva väčšinu každodenných úloh.

Ak chcete zobraziť kontext zabezpečenia súborov a procesov, môžete použiť možnosť -Z v bežných príkazoch ako ls, ps alebo id. Napríklad ls -Z Okrem oprávnení DAC zobrazí aj kontext SELinuxu každého súboru, čo vám umožní rýchlo skontrolovať, či je označenie podľa očakávaní.

Príkaz `chcon` („zmeniť kontext“) umožňuje manuálne upraviť celý kontext súboru alebo iba jeho konkrétne časti (rola, typ, rozsah) pomocou volieb ako `-r`, `-to` a `-l`. Je užitočný pri jednorazových opravách, ale je dôležité pamätať na to, že vaše zmeny sa môžu stratiť, ak sa označenie znova použije podľa politiky pomocou nástrojov ako `restorecon` alebo `fixfiles`.

Nástroj semanage je švajčiarsky nôž v oblasti správy politík za behu. Pomocou rôznych podpríkazov môžete spravovať perzistentné kontexty súborov (fcontext), mapovania prihlásení medzi používateľmi Linuxu a SELinuxu (login), používateľov SELinuxu a ich roly (user), označené porty (port), booleovské hodnoty a dokonca aj moduly politík. To všetko bez nutnosti prekompilovať celú politiku zo zdrojového kódu.

Na kontrolu a zmenu stavu boolovských premenných – malých prepínačov, ktoré povoľujú alebo zakazujú bloky pravidiel v rámci politiky – sa okrem samotnej boolovskej premennej setsebool používajú aj premenné getsebool a setsebool . Typickou boolovskou premennou je httpd_enable_homedirs, ktorá, keď je aktívna, umožňuje webovému serveru prístup k domovským adresárom používateľov (užitočné pre ~user/public_html/).

Nakoniec, príkazy ako fixfiles vám umožňujú vynútiť úplné preznačenie súborového systému podľa definovaných pravidiel a semodule sa postará o inštaláciu, zobrazenie, povolenie alebo zakázanie modulov politík (.pp) zabalených a distribuovaných referenčnou politikou alebo správcom.

Vytvorenie a úprava prispôsobených politík

Keď aplikácia nemá vlastný modul SELinux alebo potrebujete špecifickejšie obmedzenia, je čas pustiť sa do práce a vytvoriť vlastné politiky . Môže to znieť komplikovane, ale pracovný postup je celkom dobre definovaný, ak budete starostlivo dodržiavať určité kroky.

Prvým krokom je zabezpečiť, aby boli relevantné objekty (spustiteľné súbory, dátové adresáre, sockety atď.) označené príslušnými typmi. To sa dá dosiahnuť definovaním pravidiel kontextu súborov pomocou ` semanage fcontext` a ich aplikovaním pomocou `restorecon`, pričom sa pomocou regulárnych výrazov zahrnú celé adresárové stromy.

Systém sa potom zvyčajne prepne do permisívneho režimu pre daný počítač (alebo v niektorých prípadoch pre konkrétnu doménu) a aplikácia môže bežať normálne, zatiaľ čo SELinux zaznamenáva všetky príkazy `avc: denied` , ktoré by sa mohli vyskytnúť. Tieto protokoly, zvyčajne analyzované nástrojmi ako audit2allow , sa používajú na extrakciu kandidátskych pravidiel.

Referenčné politiky sú zvyčajne štruktúrované do troch súborov na aplikáciu: súbor .te obsahujúci pravidlá TE (allow, type, domain_type atď.), súbor .fc obsahujúci pravidlá kontextu súboru a súbor .if obsahujúci verejné rozhrania, ktoré môžu iné moduly opätovne použiť. Toto všetko sa skompiluje do modulov .pp pomocou make a načíta sa pomocou semodule.

Je dôležité neveriť slepo všetkému, čo audit2allow navrhuje: má tendenciu byť viac tolerantný, než je nevyhnutne potrebné . V ideálnom prípade by ste mali manuálne skontrolovať navrhované pravidlá, v prípade potreby vytvoriť nové typy na oddelenie citlivých údajov od irelevantných údajov a ak zamietnutá operácia nie je kritická, zvážiť použitie pravidiel dontaudit na zastavenie zaznamenávania šumu bez udelenia povolení.

V prostrediach ako SUSE Linux Micro alebo Android sú k dispozícii ďalšie nástroje (napríklad Udica na generovanie kontajnerových politík z popisov JSON), ktoré automatizujú časť procesu rýchlym prispôsobením politiky konkrétnym kontajnerom bez nutnosti učiť sa celý jazyk politík od začiatku.

Celý tento ekosystém kontextov, modulárnych politík, booleovských hodnôt a nástrojov na správu robí zo SELinuxu mimoriadne robustnú a flexibilnú bezpečnostnú platformu . S určitou počiatočnou investíciou do učenia sa umožňuje veľmi presné obmedzenie toho, čo môže každá služba alebo aplikácia robiť, čím sa drasticky posilní povrch útoku systému proti zneužitiam, malvéru a ľudským chybám.