Branch Privilege Injection (CVE-2024-45332, Paper) je nejnovější bezpečnostní problém procesorů Intel. Intel jej řeší ve včerejším opravném vydání 20250512 mikrokódů pro své procesory. Neprivilegovaný uživatel si například může přečíst /etc/shadow (YouTube).
Dle plánu byl vývoj Firefoxu přesunut z Mercurialu na Git. Oficiální repozitář se zdrojovými kódy je na GitHubu.
V terminálovém multiplexoru GNU Screen byly nalezeny a v upstreamu ve verzi 5.0.1 už opraveny bezpečnostních chyby CVE-2025-23395, CVE-2025-46802, CVE-2025-46803, CVE-2025-46804 a CVE-2025-46805. Podrobnosti na blogu SUSE Security Teamu.
Training Solo (Paper, GitHub) je nejnovější bezpečnostní problém procesorů Intel s eIBRS a některých procesorů ARM. Intel vydal opravnou verzi 20250512 mikrokódů pro své procesory.
Byla vydána nová verze 25.05.11 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Svobodný elektronický platební systém GNU Taler (Wikipedie, cgit) byl vydán ve verzi 1.0. GNU Taler chrání soukromí plátců a zároveň zajišťuje, aby byl příjem viditelný pro úřady. S vydáním verze 1.0 byl systém spuštěn ve Švýcarsku.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
4.8.2005 15:38
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
4.8.2005 17:18
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
/etc/lilo.cong a grub v /boot/grub/grub.conf.
getcfg-interface.
Řešení je velmi jednoduché. Interfacy se číslují podle toho, v jakém pořadí zavádíš moduly pro jednotlivá síťová zařízení do kernelu.
Bohužel to vůbec nezávisí na aliasech vytvořených v modprobe.conf. Ty slouží jen pro zjednodušení názvů. Pokud modulu pro síťovou kartu přidělíš alias Franta nebo Lojza, bude to fungovat naprosto stejně jako při aliasu eth0. Alias pro modul nesouvisí s označením rozhraní.
Pořadí načítání modulů můžeš ovlivnit editací patřičného inicializačního skriptu - podle toho, jakou máš distribuci. Například v mé distribuci (ArchLinux) se klíčový soubor jmenuje /etc/rc.conf.
Pokud používáš k nastavení sítí nějaké grafické rozhraní, tedy nějaký nástroj typu "control center" apod., jaký některé distribuce mají, ne vždy takový nástroj dokáže skript správně editovat. Dá tam poctivě všechno, co si odklikneš, ale na pořadí nekouká.
Například u mě je ovladač pro klasický ethernet zvaný 8139too, pro WiFi ipw2100 a pro FireWire ohci1394. Jestliže chci mít ethernet na eth0, WiFi na eth1 a síť přes FireWire na eth2, musím moduly načíst v pořadí 8139too ipw2100 ohci1394. Jinak řečeno: Pokud jim nastavím aliasy (po řadě) eth0, eth1 a eth2, ale budu načítat v pořadí eth1 eth0 eth2, bude driver s aliasem eth0 ovládat rozhraní eth1 a naopak. Na to pozor.
Za běhu systému můžeš síť (dočasně pro danou session) dát do pořádku (jako root) takto:
ifconfig eth0 down
ifconfig eth1 down
ifconfig eth2 down
modprobe -r eth0
modprobe -r eth1
modprobe -r eth2
modprobe eth0
modprobe eth1
modprobe eth2
dhcpcd eth0
dhcpcd eth1
dhcpcd eth2
Ještě pár poznámek: Pokud se nepřipojuješ přes server dhcp, musíš přidělit IP adresu ručně. Pak místo dhcpcd použiješ ifconfig s několika parametry. Podívej se na man ifconfig, jak na to. Pozor na správné pořadí a na správné aliasy v modprobe.conf. Změna pořadí při každém restartu znamená, že se moduly zavádějí v náhodném pořadí, což je dost zvláštní. Pořadí zavádění modulů by mělo být ve startovacích skriptech přesně definované a nikdy by nemělo probíhat paralelně nebo na pozadí...
Sorry za délku příspěvku. Doufám, že to pomůže.
Pane doktore, proč me každý ignoruje?Další!
Jinak řečeno, snažil jsem se vám tady vysvětlit, že skutečnost, že jméno interface není pevně svázáno s fyzickým zařízením, není problém, který byste měl řešit, ale realita, na kterou byste si měl zvyknout. Distribuce, kterou používáte, se s touto realitou vyrovnává a vyrovnává se s ní úspěšně, všechno funguje, jak má. Tak proč, proboha, s tou distribucí chcete za každou cenu bojovat? V čem vám konkrétně překáží skutečnost, že jméno interface není pořád stejné?
Mám kernely z www.kernel.org i z distribuce. U obou je pojmenování vázané na pořadí vkládání modulů. To lze jednoznačně nastavit v inicializačních skriptech. Děje se sériově, v daném pořadí. Neříkám, že změny pořadí jsou špatné. Jen se divím, jak je vůbec možné, že k nim dochází.
Různé názvy interfaců jistě nejsou problém, hlavně při zmíněném přístupu s MAC adresami. Řešíme ovšem jinou otázku: Mohl by uživatel, ať už z jakýchkoliv pohnutek, třeba iracionálních, mít názvy vždy stejné? Odpověď zní ano.
Musím-li něco, ptám se proč. Chci-li něco, ptám se proč ne. Dobře, tedy chci stálá jména interfaců. Proč ne? Pokud jde o riziko, lze přece bez potíží zároveň používat konfiguraci pomocí MAC adres a využít tak výhod obou přístupů.
Používám stálá jména, protože to tak chci. Až bude člověk sloužit počítači, pak se bude muset člověk s něčím smiřovat. Dokud ale slouží počítač člověku, bude prostě dělat to, co se člověku zlíbí. Přešel jsem kdysi na Linux právě proto, abych se už nikdy nemusel s ničím smiřovat. Opravdu jsem se zatím smiřovat nemusel.
Když napíšu ifconfig eth0, chci vidět informace o klasické síťovce. Když napíšu ifconfig eth1 nebo iwconfig eth1, chci vidět informace o WiFi síti. Na tom přece není nic k nepochopení, že to někdo přesně takhle chce mít...
Aha, tady je ten zásadní rozpor, podle mne totiž řešíme něco úplně jiného. Řešíme to, že tazatel zjistil, že přiřazení jmen rozhraní fyzickým zařízením není persistentní, domnívá se, že je to špatně a ptá se, jak to opravit. Proto se mu snažím vysvětlit, že to není špatně, že tudíž není třeba opravovat něco, co funguje, a samozřejmě se také snažím (jemu i ostatním) vysvětlit, jak to vlatně funguje.
Dobře, tedy chci stálá jména interfaců. Proč ne?
Také jsem měl období, kdy jsem se snažil předělávat distribuci jen tak, jak mne napadlo. Ale už mne to přešlo. Teď předělávám distribuci jen tam, kde mi to něco užitečného přináší. A tohle není ten případ.
Když napíšu ifconfig eth0, chci vidět informace o klasické síťovce.
Jak už jsem mnohokrát napsal, chybou je už samo používání ifconfig, ale to je jako házet hrách na stěnu a s probíraným problémem to nesouvisí (aspoň ne přímo). Bylo by pro vás o tolik problematičtější napsat si jednořádkový skript, který vám opravdu zobrazí nastavení toho rozhraní, které vás zajímá, a který navíc na rozdíl od toho vašeho příkazu bude opravdu dělat to, co má? (Jak už jsem také několikrát zmínil, změna jména interface vás mohla potkat už v pre-2.6 instalacích, jen si to (skoro) nikdo neuvědomoval.)
-i a -o příkazu iptables to nevadí, psal jsem to už několikrát, řešení je uvedeno i v této diskusi. Co se týká iptables-save, považoval bych to spíše za problém samotné koncepce nastavování paketového filtru pomocí tohoto příkazu, podle mých zkušeností to navíc není zdaleka jediný problém s iptables-save. Ostatně, stačí použít --pid-owner a máte úplně stejný problém.
/dev/hda1 a podruhé /dev/hdd7, ale velmi snadno se vám může stát, že stejný oddíl bude jednou /dev/sda1 a podruhé /dev/sdb1. To je realita a na systémech, kde to hrozí, je potřeba se s tím vypořádat (jde to). Stejně tak na systémech, kde hrozí, že stejný interface bude jednou eth0 a podruhé eth1, je třeba se s tím vypořádat. Takových systémů několik spravuji a nemám s tím nejmenší problém.
Takže pořád čekám, až mi vysvětlíte, v čem konkrétně vám vadí, že témuž fyzickému zařízení bude jednou odpovídat interface eth0 a jindy eth1. Protože já jsem zatím na žádnou situaci, kde by to opravdu vadilo, za rok a čtvrt nenarazil. Pro jistotu předem podotýkám, že konfigurace paketového filtru takovým případem není.
EXTHW='00:50:fc:e1:3d:07' EXTIF=`getcfg-interface "eth-id-$EXTHW"`na začátku skriptu a všechno funguje jak má. Totéž můžete použít i u IP accountingu (ten název se vám nezmění sám od sebe, změní se jen při startu systému). Opakuji: zatím jsem nenarazil na žádnou situaci, kde by byl problém s tím, že se interface nejmenuje pokaždé stejně. Pokud o takové víte, napište to.
/dev/sda1 sa /dev/sdb1 stane iba vtedy, ak sa nieco fyzicky zmeni v pocitaci
To není pravda. Máte-li dva externí USB disky, nemůžete si být jistý tím, v jakém pořadí je systém při startu nadetekuje. Ano, není to zrovna typická situace, ale takové systémy existují a je potřeba s takovou možností počítat.
getcfg-interface nemá a ani to nepotřebuje... Čím víc skriptů, tím víc potencionálních bezpečnostních chyb a nepřehlednější systém - pravý opak toho, co patří na firewall...
Vycházíte pravděpodobně z mylného předpokladu, že getcfg (a potažmo getcfg-interface) je nějaký příšerně složitý program a potenciální zdroj záludných chyb. Ve skutečnosti je to velmi jednoduchý program, který všechno potřebné najde v sysfs - stejně jako třeba udev, který se ke zmíněnému přejmenování rozhraní používá v některých jiných distribucích.
P.S.: slovo potencionální neexistuje
Vycházíte pravděpodobně z mylného předpokladu, že getcfg (a potažmo getcfg-interface) je nějaký příšerně složitý program a potenciální zdroj záludných chyb.
Já nevycházím z ničeho, samotné zjištění jména rozhraní z MAC je skript na tři řádky, ale z principu je to další skript, který není potřeba a to hlavně při nasazení na firewallech. Argumentovat přidáváním a odebíráním síťovek přeci na firewallu není vůbec relevantní. Na notebooku samozřejmě věci jako hotplug nebo udev používám také.
P.S.: potencionální - to jsem opravdu napsal já? každý se někdy uklepne
getcfg není potřeba. Ale jen za cenu toho, že musíte (téměř) totéž provést někde jinde. Jak už jsem napsal, ty dva přístupy nejsou tak odlišné, liší se jen tím, kde přesně to mapování persistentního identifikátoru na jméno interface provádíte. Snažím se tu jen vyvrátit představu, že ten přístup, který používá SuSE, je nějak principiálně horší než ten, který používají (některé) jiné distribuce. Ano, porušuje zavedenou představu, že jméno interface je něco, co je pevně svázáno s konkrétním fyzickým zařízením - jenže právě tohle de facto v úplnosti neplatilo nikdy.
Stačí jeden. Výše uvedené mám v souboru /etc/sysconfig/network/addresses, ten se includuje do všech skriptů, které potřebují pracovat se jménem interface. Vlastně ve dvou, počítám-li i /etc/sysconfig/network/eth-id-*.
Avsak traffic chcem konzistentne pocitat aj medzi jednotlivymi rebootmi.
To je mi jasné. Ale nikdo vás přeci nenutí pojmenovávat si ty jednotlivé třídy provozu podle interface. Takže data (ať už je ukládáte jakkoli) budou konzistentní, protože budou vázána na logické označení třídy, které se jménem interface nemá nic společného.
A ak sa medzi 2 bootmi ozaj nic nezmeni, tak preco by sa mali nadetekovat USB zariadenia v roznych poradiach?
Kontrolní otázka: co se změní v logice vaší úvahy, pokud sousloví USB zařízení nahradíte souslovím síťové karty? :-)
Přestože to tak nevypadá, ten problém není nový, on tu byl už dříve, jen nebyl tolik vidět. Už s jádrem 2.4 jste mohl mít dva USB disky nebo dvě PCMCIA karty (případně USB-to-ethernet adaptéry, pokud by to u PCMCIA nastat nemohlo). A dokonce i u PCI ethernetových karet (kde bylo pořadí detekce dáno číslem slotu) mohl nastat problém. Představte si totiž situaci, kdy eth0 je karta do vnitřní sítě, eth1 na Internet, a najednou se vám stane, že se tu vnější nepodaří detekovat (např. hardwarová závada karty). Výsledek je takový, že přestože rozhraní jsou (v 2.4) přiřazována (zdánlivě) fixně, máte bez vlastního přičinění vnitřní konfiguraci na vnějším rozhraní…
se tu vnější nepodaří detekovat (např. hardwarová závada karty)Tady se uz ale dostavame mimo tema debaty. Tady je to celkem logicke. Debata ovsem je IMHO o stavu bez hw poruch.
udev nebo čehokoli jiného), neznamená, že tomu tak není. A neděje se to proto, že by vývojáři jádra měli nějaký zvrácený smysl pro humor, ale proto, že Linux dnes musí podporovat řadu zařízení, u kterých pořadí detekce už z principu nemůže být persistentní. Proto jsou ta vaše oblíbená jména typu hda nebo eth0 spíše historickým reliktem, přednost by měly mít persistentní identifikátory. Persistentní jména ale vůbec nemusejí vypadat tak ošklivě, jak si myslíte, můžete si rozhraní pojmenovat eth-in, eth-out a eth-dmz, tedy podstatně praktičtěji a logičtěji než nějaké eth0, eth1 a eth2.
22.5.2007 01:41
Gilhad | skóre: 20
| blog: gilhadoviny
dam prednost tem historickym reliktum, u kterych uz v okamziku pripojeni disku vim, jak se bude jmenovat
Mám to chápat tak, že používáte jádro 2.4 a navždy u něj zůstanete? I když ani tam to neplatilo stoprocentně.
jak se bude jmenovat (podle toho, z ktereho konektoru jde kabel a podle toho, zda se jedna o master nebo slave
Klasické IDE se svým master a slave je dnes na ústupu a je jen otázkou času, kdy ze základních desek klasické IDE řadiče zmizí úplně - a s nimi i ten nešťastný master a slave. Nemluvě o tom, že distribuce už dnes přecházejí na libata, kde se i s tradičními IDE zařízeními zachází jako se SCSI.
ze az po startu systemu budu s napetim zkoumat, zda jsem nabootoval ze spravneho zarizeni, zda je vse namountovane tam, kde to potrebuju a jak se asi dneska bude jmenovat tento pevny disk
Slyšel jste někdy o udev? Vypadá to že ne, je na čase s tím něco udělat.
Není pravda, že mi udev nevoní, považuji ho za výborný nástroj, který řeší řadu problémů. Pouze jsem se snažil vysvětlit, že v tomto případě to jde celkem snadno i bez něj. Zatím mi nikdo nedokázal (v této diskusi ani v jiné) ukázat jediný příklad, kdy by nepersistentní jména síťových rozhraní skutečně vadila. Pokud takový máte, sem s ním. Navíc si všimněte, že tento thread se původně týkal jedné konkrétní verze jedné konkrétní distribuce - a já se (před dvěma roky) snažil vysvětlit, jak tato verze této distribuce funguje a proč toto řešení není a priori špatné jen proto, že neodpovídá zažitým představám. Že se do mne po téměř dvou letech někdo dost nevybíravě a nevěcně obul a teď do mne další šijí zleva zprava bez uvědomění si kontextu, to není moje vina.
Proc se zarizeni nemohou pojmenovavat vzdy podle poradi sbernice jako je to napr. v OpenBSD?
Za prvé proto, že to ne u všech sběrnic jde - např. USB. Za druhé je potřeba si uvědomit, že i když je pojmenujete podle pořadí na sběrnici, jména stejně nemusejí být persistentní - např. pokud se vám první kartu nepodaří inicializovat (z jakéhokoli důvodu), další se posunou a rázem máte eth0 tam, kde čekáte eth1 a stojíte před stejným problémem.
16.8.2005 13:26
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
21.5.2007 09:37
houska | skóre: 41
| blog: HW
Tiskni
Sdílej:
