Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
local
z prvního díluV předchozích dvou dílech jsme se naučili rozumět principům TE a RBAC tak, jak je používá SELinux. Tyto znalosti nám postačují k tomu, abychom uměli analyzovat stávající pravidla, případně tvořit nová. Soubor pravidel, které jsou do systému zavedeny, se nazývá politika (policy). V současné době zabírá takřka monopolní postavení takzvaná referenční politika. Tuto politiku používají v různých verzích a s různými patchi všechny distribuce, které podporují SELinux.
Největším problémem, se kterým se musí jakákoliv politika vypořádat, je
množství pravidel a typů, které jsou v klasickém systému
potřeba. Základní představu o tom si můžeme udělat opět pomocí
programu apol
: Počet typů je v řádu tisíců, počet
pravidel v řádu desetitisíců. Na rozdíl od normálních UNIXových
oprávnění, která si více méně tahá každý instalovaný balíček (např. DNS
server, web server) s sebou, je u SELinuxových oprávněních vše
v rukách dodavatele politiky. Referenční politika si ke svému úkolu
bere na pomoc několik principů.
Prvním principem je automatizace práce pomocí makrojazyka m4. Pokud vám to připomíná staré zlaté časy sendmailu, jste naladěni na správnou notu. Politika psaná ve stylu referenční politiky je směs volání maker a AV pravidel. Puritáni dokonce tvrdí, že optimální stav je pouze volání maker. Jazyk m4 sice neobsahuje mnoho možností, ale je to jazyk, a lze v něm dosáhnout poměrně velké strukturovanosti kódu.
Tím se dostáváme k druhému principu, a tím je modularita,
potažmo rádoby zapouzdřenost modulů. První stupeň modularity je ve
zdrojových souborech politiky. V adresáři
policy/modules
ve zdrojovém balíku najdeme hromadu modulů,
roztříděných podle zařazení v systému (systémové služby, aplikace, …). Toto rozřazení je pouze pro vývojáře, jinak nemá na politiku vliv. Jeden modul se pak věnuje části politiky, která pracuje
s vybranou částí systému. Pro konkrétnější představu se můžeme
podívat na modul bind
pro DNS server. Tento modul se
nachází mezi službami, a tedy v adresáři
services
. Každý modul je typicky rozdělen na tři části,
a bind
není výjimkou.
Soubor bind.if
obsahuje interface neboli definice maker,
která smí používat všechny ostatní moduly. Zde se soustřeďuje většina
automatizace pomocí m4. Každé makro by také mělo mít u sebe krátkou
dokumentaci v XML. Dokumentaci k interfacům všech stávajících
modulů lze nalézt v sekci Interface Reference
na webu referenční politiky. V našem modulu bind
je
například definováno toto makro:
######################################## ## <summary> ## Send BIND the kill signal ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`bind_kill',` gen_require(` type named_t; ') allow $1 named_t:process sigkill; ')
Výše uvedený kód vytváří makro bind_kill
, které očekává
jeden parametr, jež má určovat typ (doménu, chlívek, …), který
v tomto případě bude mít dovoleno provést kill -9
na
běžící proces bind. Makro bychom volali takto:
bind_kill(mujtyp_t)
A výsledkem by bylo pravidlo:
allow mujtyp_t named_t:process sigkill;
Část gen_require
bude vysvětlena později. Makro samozřejmě
může být složitější a může také volat další makra. To je velká
výhoda, ale také zdroj potíží, protože chyba v definici nebo volání
makra se obvykle projeví až po výsledné expanzi a načtení celé
politiky do systému, a to je fáze, ve které se nelehce poznává, kde
vlastně k chybě došlo. To je ale bohužel dáno vlastnostmi použitého
jazyka m4.
Jak již bylo zmíněno, takto zadefinované makro lze volat ze všech
modulů politiky. Zmíněné bind_kill
není možná
z nejužitečnějších, ale například pomocí bind_admin
lze zadefinovat nějaké roli všechna oprávnění, která potřebuje na správu
DNS serveru. Lze tedy na velmi málo řádcích vytvořit modul, který
popisuje roli správce DNS serveru, kterou pak můžeme přiřadit
uživatelům.
Pravidla, která nemusí nutně být součástí nějakého makra, modulu volatelného
zvenčí a vůbec celou kostru modulu tvoří soubor
bind.te
. Lze říci, že tento soubor je pro kompilaci
politiky podstatný, a makra definovaná v interfacech dalších
modulů se do něj vkládají podle potřeby. V souboru
bind.te
je vidět směs volání maker z různých dalších
modulů a pravidel v jazyce pro politiku SELinuxu (AV pravidla,
definice typů, rolí, …). Co je co lze poznat podle ukončujícího
středníku: Makra jej nemají. Strukturu tohoto souboru, jakož
i obvyklou metodiku používání maker, si rozvedeme podrobněji na
příkladech níže a v dalším díle.
Posledním souborem modulu je bind.fc
, neboli definice
výchozích kontextů souborů. Výchozí kontext se použije v případě
vytvoření nového souboru a v případě manuálního obnovení
výchozích kontextů pomocí restorecon
nebo fixfiles
relabel
. Formát souboru je celkem jednoznačný: Regulární výraz
(který je automaticky ohraničen ^
a $
),
typ souboru (viz nápověda k příkazu semanage
, volba
-f
) a nakonec buď řetězec
<<none>>
, nebo volání makra
gen_context()
s příslušným kontextem. Například řádek
/usr/sbin/named -- gen_context(system_u:object_r:named_exec_t,s0)
určuje, že obyčejný soubor (--
) podléhající danému
regulárnímu výrazu (což je zde pouze jeden soubor) bude mít ten
a ten kontext, z něhož je důležitá část
named_exec_t
, která označuje spustitelný soubor démona
named
. Pokud bychom někdy přestěhovali named
jinam, můžeme správný kontext souboru nastavit ručně pomocí
chcon
, což ale nepřežije obnovu implicitních kontextů.
Trvalejší metodou je použití příkazu semanage fcontext
,
který daný kontext zapíše do souboru file_contexts.local
a bude ekvivalentní kontextu v politice. Všimněme si, že
jelikož se referenční politika snaží být univerzální a linuxové
distribuce se někdy v umístění souborů liší, v souboru
bind.fc
najdeme konstrukce jazyka m4 jako
ifdef(`distro_debian',`sada_kontextů')
.
Posledním důležitým principem referenční politiky je modularita
z hlediska nastavení za běhu systému. Dříve se jednotlivé moduly ve zdrojovém formátu slepily dohromady a vznikla jedna monolitická
politika, která se musela při každé změně ve smyslu odebrání/přidání
modulu přeložit a načíst znovu. Dnes lze z jednotlivých
zdrojových modulů vytvořit moduly binární, které obvykle sídlí
v adresáři /usr/share/selinux
a které lze
programem semodule
za běhu odebírat a přidávat bez
nutnosti překladu. Pokud používáme DNS server, načteme modul
bind
, pokud ne, tak ho necháme ležet.
S tímto principem přichází možnost výroby vlastních modulů, aniž
bychom museli modifikovat původní politiku. Podrobný popis výroby
netriviálního modulu si uvedeme v příštím díle. Dnes se pouze
podíváme na dva jednoduché moduly. Prvním z nich je modul, který
zpřístupňuje socket vytvořený příkazem ssh_agent
(respektive ssh -A
). V politice, která je
nainstalována v distribuci Debian Lenny, se na něj zřejmě zapomnělo.
Nejprve vytvoříme soubor sshagent.if
:
## <summary>sshagent policy</summary> ## <desc> ## <p> ## policy for accessing ssh agent sockets in /tmp ## </p> ## </desc> # ######################################## ## <summary> ## Access ssh agent sockets. ## </summary> ## <param name="domain"> ## Domain allowed access. ## </param> interface(`sshagent_access',` gen_require(` class sock_file { read write }; type $1; type sshd_tmp_t; ') allow $1 sshd_tmp_t:sock_file { read write }; ')
Definujeme pouze jedno makro, které generuje jedno pravidlo, povolující
danému typu přístup k socketům typu sshd_tmp_t
(tj.
v adresáři /tmp
). Makro gen_require
vloží
dané řádky do sekce require
v souboru, odkud je naše
makro zavoláno. Co je to sekce require
? Každý typ, roli,
přístupové právo, atd., které chceme použít, musíme předem oznámit
v sekci require
. Při zavedení modulu do jádra se
nejprve ověří, zda všechny tyto entity existují. Tím vlastně zavádíme
závislost našeho modulu na modulu ssh
, bez kterého
neexistuje typ sshd_tmp_t
.
Dále vyrobíme soubor sshagent.te
, který triviálně použije
právě definované makro:
policy_module(sshagent,1.0.0) sshagent_access(staff_ssh_t) sshagent_access(sysadm_ssh_t)
V prvním řádku deklarujeme (voláním makra), že vyrábíme modul
s názvem sshagent
a verzí 1.0.0. Dále už jen
voláme naše makro pro zpřístupnění socketů daným typům (co jsou zač, jsme
rozebírali minule).
Konexty souborů zde nepotřebujeme, soubor sshagent.fc
tedy
vytvoříme prázdný. Zbývá přeložit modul. K tomu potřebujeme
nainstalovat devel balíček od naší politiky (v Debianu je to
selinux-policy-dev
). Dále už je to jen:
make -f /usr/share/selinux/default/include/Makefile
Výsledkem bude soubor sshagent.pp
v aktuálním
adresáři. Pro jeho nahrání stačí semodule -i sshagent.pp
,
případně výše uvedeným make
vyrobit cíl load
(make -f … load
). A vida, autentizace pomocí
SSH agenta začne fungovat. Příkazem semodule -l
se můžeme
pokochat, případně zjistit, jaké další moduly jsou nataženy. Nahrání
modulu jej taky zkopíruje do adresáře
/etc/selinux/default/modules/active/modules
, odkud se
nahraje při rebootu. Podobně semodule -r sshagent
modul z tohoto adresáře smaže a odinstaluje z jádra.
local
z prvního díluDruhým příkladem je modul local
, který vznikl při prvotní
instalaci v prvním díle použitím příkazu audit2allow -M local
. Jak bylo řečeno, použití audit2allow
bylo sice funkční řešení, ale bez dalšího auditu výsledné politiky může
přinejmenším zanášet nepořádek a přinejhorším otevírat bezpečnostní
díry. V této chvíli již rozumíme pravidlům, kontextům a dalším
principům SELinuxu, umíme použít auditovací nástroje apol
a sesearch
a umíme si dohledat informace na
webových stránkách referenční politiky a dalších webech. Jako
správní rootové s bezpečnostním uvažováním rozumíme také svému
operačnímu systému, své distribuci a instalovaným službám
a programům. Přišla tedy ta správná chvíle splatit dluh
z prvotní instalace SELinuxu a podívat se, co v souboru
local.te
vzniklo, a zamyslet se nad tím, jestli nelze daný problém vyřešit jinak. Konkrétní postup necháme zatím jako
„domácí úkol“ pro čtenáře a vrátíme se k němu
v příštím díle.
Povíme si podrobněji, kudy by se mělo naše uvažování ubírat při tvorbě nebo validaci modulu bezpečnostní politiky. Ukážeme si, jak se tvoří složitější moduly pro nějakou vlastní nebo nepodporovanou aplikaci, případně pro uživatelskou roli. Při tom budeme vážit důsledné používání maker a principů referenční politiky s principem nejmenšího odporu.
Článek vznikl za podpory ČVUT FEL, Katedra kybernetiky, kde jsou k dispozici, mimo jiné, studijní programy Otevřená informatika a Kybernetika a robotika.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Diskuse byla administrátory uzamčena
Po tomto diele sa fakt už SElinuxu bojím :)
Většina Wokeníků pracuje pod administrátorem, protože je to jednodušší. Fungují i špatně napsané aplikace (jsou takové ještě), systém vás nebuzeruje že na to a to nemáte oprávnění.Pochopitelně je vždy jednodušší se bezpečnosti vzdát, než ji navrhnout dobře, a bohužel jsou i případy, kde platí, že žádné zabezpečení je lepší, než špatné. Mimochodem systém bezpečnosti ve Windows NT je metodicky mnohem propracovanější, než ten v UNIXu (ale zase ne tak dobrý jako v SELinuxu, protože stále patří do kategorie DAC, tedy až na ten pokus s UAC ve vistě).
Nedovedu si představit, že bych spravoval SELinux, protože nikdy nebudu mít tak přesné informace o vnitřnostech systému, abych věděl kdo k čemu kdy přistupuje. Špičkový profesionální admin, to je pochopitelně jiná liga.To je samozřejmě přípustný postoj, narozdíl od ignorance typu "je to moc složité, tak to radši hned vypnu". Bohužel v bezpečnosti je to tak, že čím víc chcete zabezpečovat, tim víc musíte znát jednotlivé procesy, které zabezpečujete. A procesama v operačním systému to jen začíná. A můžete taky dojít k závěru, že tuto úroveň zabezpečení pro svoje procesy nepotřebujete. Každopádně bych ale doporučil všem těm adminům typu "mám tři weby a poštovní server a pár kamarádů přes ssh", aby se alespoň zkusili podívat na defaultní nastavení targeted politiky pro SELinux (viz níže), která přesně tento případ adresuje.
Druhá možnost je, že celou konfiguraci připraví distributor, takže běžný uživatel o SELinuxu vůbec nemusí vědět. V práci máme jeden RHEL5 a SELinuxu ničemu nevadí, je neviditelný (ale ten stroj jsem neinstaloval, takže nevím, co se tam řešilo).Připraví to distributor a administrátor, takže uživatel neví o SELinuxu, ale už ví o personální politice která by měla být spjatá s tou počítačovou (např.: heslo si udělej jen jedno, ale dlouhý, nebo: tady máš přístupovou kartu, nenechávej ji na stole). Pokud máte RHEL5 tak IMHO používáte "targeted" politiku, kde jsou omezeny alespoň služby s přístupem na síť (web server, ...), ale už ne uživatelé, kteří se přihlašují. Nebo ji nemáte a pak máte buď schopného administrátora, a nebo zapracovaly Vaše peníze za subskripci RHEL. :)
uživatel o tom v podstatě ani neví a přitom je chráněnýPokud se to nezměnilo, tak implicitně máte jako uživatel identitu
unconfined_u
, což zas taková ochrana není. Je ale poměrně jednoduché se toho zbavit.
Rozchodit SELinux bez nějaké větší podpory distribuce je jaksi vyšší dívčí.Jeden z dílů chci věnovat i tomuto tématu.
k SELinuxu: Cheddar Bay Exploit...