Prvním krokem pro ověření původu binárky je kontrola digitálního podpisu. Pokud chcete srovnávat "doma" zkompilované binárky proti těm od autorů SW/distra, tak se pochopitelně budou lišit, protože ty "domácí" nebudou podepsané (nebo ne stejným klíčem). Technicky sice není problém srovnat binárky se zanedbáním podpisu, Jak to ale jde dohromady se snahou aby byla "doma" vytvořená binárka na bit stejná?
Nějak jsem nepředpokládal, že na Linuxu podobnou základní věc nemáte.
Ad widle to delaji jedinym spravnym zpusobem, a proto je na nich 99,99% binarek nepodepsanych - LOL. Binárky OS jsou podepsané, stejně jako binárky ostatních MS produktů. Vyjma toho vidím podepsané namátkou následující: Adobe Photoshop, CorelDRAW, Eclipse, Firefox, LibreOffice, Foxit Reader, Paint.NET, Java, WinRAR... A co se namátkou koukám, vidím podepsané i hry koupené přes Steam. Takže s těmi 99.99% binárek zjevně kecáte. Proč mě to nepřekvapuje?
Jistě, to chápu, a snad je to jasné i z mého prvního příspěvku v tomto threadu. Nicméně digitální podpis binárky umožňuje zjistit alespoň jestli je ta binárka opravdu od autora. Ověření překladem, což je oproti kontrole podpisu dost náročná operace, bych viděl až jako druhý krok pokud nevěříte autorovi binárky.
Takže na nainstalovaném systému nelze nijak snadno zjistit jestli binárky pocházejí z distribuce? To moc nepotěší, a reprodukovatelná kompilace tomu moc nepomůže. Abych zjistil jestli můj bash pochází z distribuce, tak bych ho musel zkompilovat ze zdrojáku a srovnat výsledek.
To to trvalo, než jsi přišel...
A prosím tě, snaž se trochu víc, tvé argumenty jsou slabé a znalost problematiky chabá.
Takhle si nepředstavuji dobře odvedenou práci, za kterou tě platí.
Pozor, aby tě nevyměnili za někoho výkonnějšího!
Nepozoruješ to sám na sobě, zvláště takhle k večeru? :-)
To je pouze jedna z možností. A upřímně řečeno ta méně pravděpodobná. Daleko pravděpodobnější je že si stáhnete binárku z nakaženého serveru, nebo že vám ji někdo po hacknutí stoje vymění. Proto má svou roli jak digitální podpis binárek, tak reprodukovatelný překlad.
Ale myslím že otázka je uzavřena. Ptal jsem se, jestli se nebudou mlátit digitální podpisy binárek s reprodukovatelnou kompilací. Zjevně nebudou, protože binárky nejsou podepsané. Za mě zodpovězeno.
To je pouze jedna z možností. A upřímně řečeno ta méně pravděpodobná. Daleko pravděpodobnější je že si stáhnete binárku z nakaženého serveru
To se ovšem týká Windows. Linuxové distribuce to "stažení binárky z nakaženého serveru" už léta řeší distribucí software přes důvěryhodné repozitáře, takže tenhle problém mají dávno vyřešený. Proto teď řeší tu méně pravděpodobnou možnost, tj. modifikaci binárky přím opři kompilaci.
Ptal jsem se, jestli se nebudou mlátit digitální podpisy binárek s reprodukovatelnou kompilací.
K tomu není důvod. Podpis je vždy něco, co vzniká vedle podepisovaného objektu, pouze pro zjednodušení pro lidi se pak někdy podpis spojí s původním objektem do jednoho souboru. Ale i když chcete ověřit podpis souboru s připojeným podpisem, musíte být schopen s toho souboru s připojeným podpisem získat původní soubor bez podpisu. Takže stejný způsob lze použít i pro ověřování podepsaných binárek - prostě získáte nepodepsanou binárku (stejným způsobem, jako byste chtěl ověřit podpis), a tu pak porovnáte s tou, která vypadla z kontrolní kompilace. A nebo ty podpisy prostě necháte uložené vedle, v samostatném souboru.
Osobně jsem pro nasazení TLS úplně všude, takže jsem rozhodně pro nasazení https, ale nikoli z důvodů důvěryhodnosti přenášených binárních souborů.
Vaše znevážení toho, že se software distibuuje přes http, pramení spíše z nepochopení problematiky, než z faktické situace.
a) https přináší bezpečnost přenosového kanálu. Nic víc, nic mín - máte pouze garanci, že data nezměnil nikdo po cestě (pomineme-li ty všechny pěkné falešné certifikáty, které byly v posledních letech vydány). Tj. pokud na mém fake-mirror.debian.xyz nasadím https, tak v manipulaci s archívem zabrání pouze digitální podpis onoho archivu (repozitáře).
b) teoretický přínos by mohl být ve zvýšení soukromí - padouch po cestě nevidí, co přenášíte. Bohužel metadata komunikace a přístup k obsahu archivu nakonec poměrně spolehlivě prozradí, co jste plus mínus přenášel. Samozřejmě to není tak spolehlivé, jako odposlech http.
Takže nakonec zůstáváme u toho, že nasazení TLS pro repozitáře Linuxových distribucí by mělo jen jediný pořádný efekt, a tím je přidání "šumu", který je zapotřebí analyzovat, a tím pádem čistý efekt zůstane v tom, že to budou mít padouši, kteří dělají všudypřítomné a neustálé sledování provozu, těžší.
Ne, TLS by zvysilo bezpecnost pred padouchy.
Bez HTTPS vam muzu zobrazit starsi verzi repo. To je zajimave, kdyz se nalezne kriticka chyba treba v sitovem demonu. Padouch potrebuje nalezt, co presne se zmenilo, napsat exploit a nekam jej podvrhnout. S TLS na to ma cas do nejblizsiho updatu a to nedava. Bez TLS neni cas omezen. Navic system uzivatele neupozorni, ze je v stahovani chyba.
Ad Linuxové distribuce to "stažení binárky z nakaženého serveru" už léta řeší distribucí software přes důvěryhodné repozitáře - což funguje přesně do té doby než potřebujete zjistit, jestli soubory na vašem systému pocházejí opravdu z distribuce, nebo jsou od někdo pozměněné přímo na vašem stroji. Předpokládám že kvůli kontrole nebudete chtít tahat kompletní zdrojáky a kompilovat je.
Ad Podpis je vždy něco, co vzniká vedle podepisovaného objektu, pouze pro zjednodušení pro lidi se pak někdy podpis spojí s původním objektem do jednoho souboru - pravda, podpisy nemusejí být součástí souboru. Ale je to tak výrazně praktičtější.
Ad když chcete ověřit podpis souboru s připojeným podpisem, musíte být schopen s toho souboru s připojeným podpisem získat původní soubor bez podpisu - ano, ale pak podepsaný soubor není přesně shodný z nově přeloženým (který je bez podpisu). Souhlasím že to nemusí být problém.
Co to meles ty pomatence? Pozmenene soubory? Jestli se ti nekdo hrabal v systemu, tak NEMAS SANCI zjistit, jestli jsi stale kompromitovany. Muzes mit zmenene jadro, nebo nastroje pomoci kterych ten podpis overujes, nebo datove soubory ktere nejsou podepsane. I moje babicka ma lepsi predstavu o bezpecnosti nez ty. Nauc se zaklady. Dneska si vyplatu od Microsoftu nezaslouzis.
> Ve visualku ve widlich napises helo world ... a vyleze ti z toho 5MB exe.
Nevím, jak to děláš, ale já mám ve VS v .NET program implementující síťový protokol včetně SSL velký 14 kB, a to jsem se o žádnou optimalizaci nesnažil (například protože to bylo moje první setkání s C# a vůbec tomu nerozumím). (k nakoukání zde)
Což ovšem neznamená, že to na Linuxu nejde udělat lépe...
$ cat hello.c
#include <stdio.h>
int main(void) {
puts("Hello, world!");
return 0;
}
$ diet gcc -Os -ohello hello.c
$ ./hello
Hello, world!
$ ls -l hello
-rwxr-xr-x 1 ondrej ondrej 4408 Sep 11 17:21 hello
$ strip hello
$ ls -l hello
-rwxr-xr-x 1 ondrej ondrej 2296 Sep 11 17:25 hello
Ale i se standardními knihovnami to nejde do MB:
$ gcc -Os -static -ohello-gcc hello.c
$ ls -l hello-gcc
-rwxr-xr-x 1 ondrej ondrej 825328 Sep 11 17:24 hello-gcc
$ strip hello-gcc
$ ls -l hello-gcc
-rwxr-xr-x 1 ondrej ondrej 742864 Sep 11 17:24 hello-gcc
To je ale nedostatok kompilatoru, nie? Hlavne teda pri statickom linkovani, kde by sa to mozno dalo po analyze volani vyhodit (nie som si isty, ci sa na to nieco nespolieha). Pri dynamickom linkujes vsetko, takze tam to zmysel nedava.
U ELF z asm som sa u mna dostal na 254 B, ale to uz je na urovni, na ktorej by asi nikto nechcel pisat kod.
Toto je ukazka, ze sa setrit da, ale ked to porovnas s kodom Ondreja Sureho, tak uvidis, ze to uz nie je ono.
nasm -f elf hello.asm
ld -m elf_i386 -s -o hello hello.o
section .text
global _start
_start:
; syscall(sys_write = 4, stdout = 1, worldmsg, length);
mov edx,worldmsg_end - worldmsg
mov ecx,worldmsg
mov ebx,1
mov eax,4
int 0x80
; syscall(sys_exit)
mov eax,1
int 0x80
worldmsg:
db 'Hello, world!',0xa
worldmsg_end: