Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Pokud chceme založit nového uživatele, musíme to udělat na dvou místech. Zavést uživatele do KDC (Key Distribution Center, v našem případě Kerbera) a nastavit mu v něm heslo. Tím je v databázi KDC vytvořeno sdílené tajemství mezi uživatelem a KDC, které je později používáno pro účely autentizace (vytváření lístků, ...).
Dále si musíme vytvořit záznam v PRDB (Protection Data Base). Vazba mezi
jednotlivými databázemi je tvořena automaticky na základě shody jména
uživatele (principalu) a důvěry mezi AFS servery a KDC.
Důvěru mezi nimi jsme zařídili při instalaci buňky ve
druhém díle, a to
příkazem asetkey
, který přejal klíč z Kerberos keytabu do AFS
KeyFile, ten najdete v /etc/openafs/server/KeyFile
.
Zkontrolovat si to můžete příkazy (druhý příkaz vyžaduje oprávnění root):
~$ bos listkeys afssrv.foo.bar key 2 has cksum 1976585079 Keys last changed on Tue Feb 22 17:17:19 2011. All done. ~# klist -k /var/lib/krb5kdc/keytab.afs -e Keytab name: WRFILE:/var/lib/krb5kdc/keytab.afs KVNO Principal ---- -------------------------------------------------------------------------- 2 afs/foo.bar@FOO.BAR (DES cbc mode with CRC-32)
Avšak soubor keytab.afs
jsme použili pouze jako prostředek
pro výměnu klíčů při instalaci. Ve skutečnosti se musíme podívat do databáze
Kerbera, kde zjistíme aktuální informace o používaném klíči. Prozatím
opět zneužijeme privilegia uživatele root:
~# kadmin.local -p spravce/admin -q "getprinc afs/foo.bar" getprinc afs/foo.bar Principal: afs/foo.bar@FOO.BAR Expiration date: [never] Last password change: Tue Feb 22 16:01:02 CET 2011 Password expiration date: [none] Maximum ticket life: 0 days 10:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Tue Feb 22 16:01:02 CET 2011 (spravce/admin@FOO.BAR) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 2, DES cbc mode with CRC-32, no salt MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none]
Zde vidíme informace o principalu afs/foo.bar@FOO.BAR
(služba AFS),
jehož klíč (de facto heslo) jsme uložili do keytab.afs
,
abychom ho mohli do AFS naimportovat příkazem asetkey
.
Pro nás je důležité, že odpovídají čísla klíčů a jsou ve správném
šifrování, které umí OpenAFS. AFS tak má k dispozici klíč,
kterým dokáže ověřit, že token vytvořený z lístku pro službu
afs/foo.bar@FOO.BAR
není nějaký podvrh. Celá záležitost
s protokolem Kerberos je trochu zamotanější, ale pro naše potřeby to stačí,
méně náročným lze doporučit
Frantu a jeho krabice,
ostatním už jedině
dokumentaci prokolu Kerberos.
Je doporučení, že jednou za čas byste klíč měli vyměnit. To znamená celou
operaci zopakovat a výsledný /etc/openafs/server/KeyFile
ručně rozkopírovat na všechny vaše servery. Důvodem je slabost šifry DES
(kterou dnes lze prolomit do jednoho dne), ale jiné šifrování
zatím OpenAFS nepodporuje.
Po odbočce k protokolu Kerberos si založíme jednoho administrátora, abychom jím pak mohli vytvářet uživatele. V systému se rozlišují 4 základní typy principalů: administrátoři, uživatelé, počítače (host) a služby. Je vhodné je rozlišovat, protože v databázi KDC se používají tzv. politiky (policy), kterými jednotlivé principaly lze předkonfigurovat. Vytvoříme tedy tyto politiky:
~$ su Password: ~# kadmin.local -p kadmin/admin@FOO.BAR Authenticating as principal kadmin/admin@FOO.BAR with password. kadmin.local: add_policy -minlength 8 -minclasses 3 admin kadmin.local: add_policy -minlength 8 -minclasses 2 -maxlife "365 days" user kadmin.local: add_policy -minlength 8 -minclasses 4 host kadmin.local: add_policy -minlength 8 -minclasses 4 service
Všechny politiky vyžadují heslo minimální délky 8 znaků a podle důležitosti
musí obsahovat různé množství tříd znaků (čísla, velká písmena, malá písmena,
interpunkce a ostatní znaky). Jak je vidět, na uživatele jsme nebyli tak přísní
jako na administrátory s požadovanou kvalitou hesla. Ale uživatelé si každý
rok musí změnit heslo příkazem kpasswd
. Administrátoři si heslo
nemusí měnit, defaultně je nastaven maxlife na 0, což se bere jako nekonečno.
Ztráta jejich přístupu k systému by mohla být fatální a také se předpokládá
nějaké povědomí o potřebě měnit hesla.
Než začneme vytvářet nový principal v Kerberu pro administrátora,
je vhodné se rozmyslet, jak budete rozlišovat administrátory od uživatelů.
Nejčastěji se administrátorům připojuje přídomek admin
nebo root
. Ale lze narazit i na jiné varianty. V obecném formátu
principalu primary/instance@REALM využijeme část instance. Je vhodné
mít všude sladěné uživatelské jména a tak doporučuji, abyste si
administrátorskou identitu odvodili od svého běžného loginu.
Takže pro uživatele lojza budeme mít principal
lojza/admin@FOO.BAR
. V příštím díle pak shodu loginu a principalu
využijeme k automatickému vytváření lístku.
Můj oblíbený login je svamberg
takže si pro něj vytvořím principal (stále pracujeme v kadmin.local):
kadmin.local: add_principal -policy admin svamberg/admin@FOO.BAR Enter password for principal "svamberg/admin@FOO.BAR": Re-enter password for principal "svamberg/admin@FOO.BAR": Principal "svamberg/admin@FOO.BAR" created. kadmin.local: quit
Nyní sice máme administrátora, ale ten nemá žádná oprávnění.
Použijeme tedy hvězdičkovou notaci v souboru
/etc/krb5kdc/kadm5.acl
abychom všem administrátorům
(*/admin
) přidali všechna oprávnění (*
).
Pak provedeme restart admin serveru a už nebudeme uživatele
root
potřebavat.
~# echo "*/admin *" >> /etc/krb5kdc/kadm5.acl ~# /etc/init.d/krb5-admin-server restart Restarting Kerberos administrative servers: kadmind ~# exit
A teď vytvořeným administrátorem si můžeme vytvořit uživatele,
tentokrát už nepoužijeme program kadmin.local
, který přistupuje
k databázi KDC přímo. Spustíme kadmin
, kterým se
regulérně přihlásíme k administrátorskému rozhraní KDC serveru, kde
vytvoříme běžného uživatele (v jejich principalu se
nepoužívá část instance):
~$ kadmin -p svamberg/admin Authenticating as principal svamberg/admin with password. Password for svamberg/admin@FOO.BAR: kadmin: add_principal -policy user svamberg Enter password for principal "svamberg@FOO.BAR": Re-enter password for principal "svamberg@FOO.BAR": Principal "svamberg@FOO.BAR" created. kadmin: quit
Program kadmin
můžete použít odkudkoliv, kde budete mít svůj
/etc/krb5.conf
(nebo si vzpomenete na adresu admin serveru,
viz man kadmin
).
Principal pro uživatele i administrátora máme vytvořen, ale nemáme žádnou návaznost na AFS. Token sice vytvoříme, ale je nám prakticky k ničemu, protože není svázaný s žádným uživatelem:
~$ kinit svamberg Password for svamberg@FOO.BAR: ~$ aklog ~$ tokens | nl 1 Tokens held by the Cache Manager: 2 Tokens for afs@foo.bar [Expires Apr 2 10:09] 3 --End of list--
Na řádku 2 je jen obecný token a není v něm řečeno, kterému uživateli
z AFS patří. Budeme tedy naposledy potřebovat token od afsadmin
:
~$ kinit afsadmin Password for afsadmin@FOO.BAR: ~$ aklog ~$ tokens | nl 1 Tokens held by the Cache Manager: 2 User's (AFS ID 1) tokens for afs@foo.bar [Expires Apr 2 10:16] 3 --End of list--
Zatím je toto jediný token, který máme ve skupině
system:administrators
, proto napřed vytvoříme identitu
pro našeho nového správce v AFS a pak jej do skupiny přidáme. AFS pro
oddělení jména a funkce nepoužívá lomítko nýbrž tečku, proto si já
založím uživatele svamberg.admin
:
~$ pts createuser svamberg.admin User svamberg/admin has id 2 ~$ pts adduser svamberg.admin system:administrators ~$ pts members system:administrators Members of system:administrators (id: -204) are: afsadmin svamberg.admin
Zařazení do této skupiny nám ale nedává úplně všechna oprávnění.
Můžeme sice dělat některé operace, ale již v příštím díle bychom zjistili,
že takto nemůžeme například založit nový volume. Proto svého administrátora
přidáte na každý AFS server do souboru UserList (ten se nachází v
/etc/openafs/server/
). Pro tuto operaci použijeme příkaz:
~$ bos adduser afssrv.foo.bar svamberg.admin
Aktuální obsah seznamu privilegovaných uživatelů si lze vypsat příkazem:
~$ bos listuser afssrv.foo.bar SUsers are: afsadmin svamberg.admin
Správce afsadmin
ponecháme v seznamu, jeho přístup na konci
tohoto článku odepřeme v Kerberosu. Jeho identitu můžeme tak snadno obnovit
a použít jej v případě nějaké krize.
A teď už můžete používat svou vlastní administrátorskou identitu pro správu
celého systému. Hned ji využijeme na to, abychom do Protection Data Base (PRDB)
přidali i obyčejného uživatele. Výjimečně si pustíme aklog
v debug
režimu, kde je pěkně vidět, jak z Kerberos lístku vytvoří AFS token:
~$ kinit svamberg/admin Password for svamberg/admin@FOO.BAR: ~$ aklog -d Authenticating to cell foo.bar (server afsdb.foo.bar). Trying to authenticate to user's realm FOO.BAR. Getting tickets: afs/foo.bar@FOO.BAR Using Kerberos V5 ticket natively About to resolve name svamberg.admin to id in cell foo.bar. Id 2 Set username to AFS ID 2 Setting tokens. AFS ID 2 / @ FOO.BAR ~$ tokens Tokens held by the Cache Manager: User's (AFS ID 2) tokens for afs@foo.bar [Expires Apr 2 10:56] --End of list--
Lze doporučit nějak vhodně oddělit uživatele od systémových účtů. To lze provést obdobně jako v Linuxu, kdy systémové účty mají nižší ID a běžní uživatelé začínají od čísla 1000. To lze nastavit i u účtů v AFS, posuneme čítač pro vytváření uživatelů na vyšší číslo. To samé provedeme i čítači skupin, které se počítají v záporné ose.
~$ pts listmax Max user id is 2 and max group id is -205. ~$ pts setmax -group -1000 -user 1000 $ pts listmax Max user id is 1000 and max group id is -1000.
Jako administrátor lze vytvořit obyčejného uživatele v PRDB:
~$ pts createuser svamberg User svamberg has id 1001
Když už máme svou vlastní a vyzkoušenou správcovskou identitu,
můžeme zakázat uživatele afsadmin
. To zařídíme
přes kadmin
, kde zakážeme tvorbu Kerberos lístku (a potažmo
tokenu) pro tento principal:
~$ kadmin -p svamberg/admin Authenticating as principal svamberg/admin with password. Password for svamberg/admin@FOO.BAR: kadmin: modify_principal -allow_tix afsadmin Principal "afsadmin@FOO.BAR" modified. kadmin: quit ~$ kinit afsadmin kinit: Clients credentials have been revoked while getting initial credentials
Stejným způsobem lze zablokovat i ostatní uživatelské principaly a tím jim odepřít přístup nejen k AFS, ale i jiným službám, které můžete mít na Kerberos navázány.
Každý správce by měl mít svou běžnou (uživatelskou) identitu a k ní samostatnou administrátorskou. Není dobrý nápad mít jednu identitu, ke které si budete předávat heslo. Ztrácí se tím pak informace, kdo co udělal a také to spěje jen k problémům v budoucnu. KDC umožňuje drobnější dělení práv a spoustu dalších detailů, ale to už je trochu mimo téma tohoto seriálu.
Správci jsou už spokojení, ale pro uživatele jsme toho moc neudělali. Napravíme to tedy v příštím díle, kde jim vytvoříme jejich vlastní prostor a také je naučíme pracovat se skupinami.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: