Keresés: - [Linux] A Flatpak - LOGOUT Hozzászólások

Hirdetés

Legfrissebb anyagok

LOGOUT témák

PROHARDVER! témák

Mobilarena témák

IT café témák

GAMEPOD témák

Keresés

Új hozzászólás Aktív témák

sh4d0w félisten

#204
#201 Rowon
2024-12-12 20:48:28

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#201 Rowon

#201 Rowon
Akkor a Debiannál is biztos hülye mindenki, mert átvették a Systemd-t.

Bizony. A Red Hat megiratta ezzel a felkegyelmuvel azt a rendszert, ami a corporate iranyba viszi a Linuxot, Debianek, meg meg egy valag masik disztribucio meg csak annyit lattal belole, hogy mar nem nekik kell init scripteket irogatniuk es karbantartaniuk, hanem a systemd-vel kapnak egy jo adagnyit. Ami persze igaz, csak egy kalap szar az egesz.
sh4d0w félisten

#203
#195 Rowon
2024-12-12 20:44:02

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#195 Rowon

#195 Rowon
Mióta van Systemd azóta meg főleg, bár ezt sem tudta még senki értelmesen nekem elmagyarázni, hogy miért baj a Systemd meg, hogy miért kellene Poetteringet lecsukatni. Csak megy a hümmögés meg a mellébeszélés meg a semmivel alá nem támasztott gyűlöletbeszéd. Szokásos Linuxos hozzáállás, még a saját fajtánkat is utáljuk.

Pedig lenne ra ok boven, amiert le kellene csukatni - a tobbi vadpontot megtalaljuk azutan is, hogy mar ul.
A systemd egy mindent felzabalo, ostoba operacios rendszer az operacios rendszeren belul. Eloszor egy parhuzamos init rendszernek indult, de mara mar bezabalta a service managementet, az alkalmazas managementet, a userek kezeleset, a rendszer beallitasait, session managementet, device managementet. A KISS filozofiat hirbol sem ismeri es valoszinuleg a problemak nagy resze is ebbol fakad - tul a szerzoje ostobasagan es hozza nem ertesen. A csavo egyebkent a Red Hattol atment a Microsofthoz - ott nem fog kilogni a sorbol.
Miket "tud" a systemd? Nos, tudja azt, ha screenben inditasz el egy tavoli munkamenetet, mert mondjuk egy sokaig futo script es nem akarod, hogy megszakadjon a melo, ha kilepsz, akkor o elozekenyen azt a tavoli munkamenetet is lezarja. "Tudja" azt, ha nem sikerul valamiert a tuzfal szabalyokat ervenyesiteni, akkor is felhuzza a halozatot, de ertesitest legalabb nem kuld arrol, hogy gaz van a tuzfallal, igy az admin hiheti, hogy minden rendben van... amig eszre nem veszi, hogy az ssh portra, vagy a web portra omlenek a requestek. Mi tudja elcseszni a tuzfal konfigot? El tudja kefelni az admin... vagy az, hogy felveszel a rendszerbe CUPS-on keresztul egy nyomtatot... Termeszetesen arra is van lehetoseg, hogy egyszer, s mindenkorra hazavagd az alaplapod, mert az EFI ertekeket nem konstansokba olvassa be a laprol, hanem sima valtozokba, amiket akar veletlenul is felulirhatsz. Allitolag a systemd olyat is tud, hogy barmilyen alkalmazast, scriptet service-kent futtasson, de egeszen biztosan allithatom, hogy ez nem igy van, nagyonsok evvel ezelott volt valami, amit nem tudtam igy megoldani, pedig a systemd nagykonyve szerint csinaltam. Nyilvan azota nem probaltam, mert ha 1-2 alkalommal kell ez a funkcio es ebbol egyszer nem sikerul, akkor nem baszodik vele az ember, keres mas megoldast. Ezenkivul magara teszi az 1-es PID-et, aminek normal esetben a kernelnel kellene lennie, igy ha a systemd ledoglik, akkor ledoglik a teljes rendszered - hipiszupi. A logolas binaris, tehat eleve kell egy futo rendszer, hogy tudd olvasni... A halozati interface-eket eloszeretettel nevezgeti at, allitolag hardvercimeknek megfeleloen, de nem mindig sikerul neki, tehat azt a feladatot, amire ezt az atnevezosdit kitalalta herr pocstering... hat azt mersekelt sikerrel sikerult megoldania. Evtizedes vagy idosebb konvenciokat rugott fel a parancsok hasznalatat tekintve - es meg szerintem napestig lehetne sorolni a hibakat.
A systemd iroja meg egy ostoba, arrogans es agressziv f.sz, aki nem tudta elviselni a kritikakat es minosithetetlen stilusban reagalt a jelzett problemakra, amit vegul odaig sikerult tolnia, hogy Torvalds kozolte vele: vagy fixalja a szarjat, vagy egyetlen commitot sem fogad be tole, amig nincs fix.
Szoval boven van ok utalni a systemd-t.
sh4d0w félisten

#196
#192 Rowon
2024-12-12 19:56:27

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#192 Rowon

#192 Rowon
Nem gondolod, hogy ennél azért már tovább jár a történet? 2024-et írunk, nem 1984-et. Haladni kéne a korral.

A windows meg egy rémálom, fusson ámokot máshol.

Elnézve az Linux ~4% körüli asztali részesedését, amit 30 (!) év alatt össze tudott hozni... hát annyira nagyon nem rémálom a Windows hozzá képest. Pont ezaz, hogy a Linuxot kellene versenyképessé tenni.

"Elnézve az Linux ~4% körüli asztali részesedését, amit 30 (!) év alatt össze tudott hozni... hát annyira nagyon nem rémálom a Windows hozzá képest. Pont ezaz, hogy a Linuxot kellene versenyképessé tenni."
A Linux 4% asztali reszesedese pont jo, nem kell, hogy Windows-za varazsoljak, de egyebkent tenyleg remalom a Windows kezelese. Kattints ide, kattints oda, legelabb ketfele felulet, ahol a beallitasokat tudod maceralni, egyseges hotkey-t felejtsd el. Tele van mindenfele csillogo-villogo kutyuvel, ami elvonjak a figyelmet es nem hagyjak, hogy a dolgodra koncentralj, de legalabb meg mindig eroforras-igenyesebb, mint egy Linux (Ubuntut kiveve). Mindezek tetejebe egy update lassu, mert meg mindig nem sikerult azt felgyorsitani, belepes utan meg mindig sok ideig szarozik a rendszer, mielott hasznalhatova valik. A power userek kezebol is kivettek a kulonbozo telepitesi es management eszkozoket es ugy garazdalkodik a Microsoft a gepen, mintha a sajatja lenne - nincs full kontrollod felette.
Meg nagyobb baj, hogy az alkalmazasok egy resze is a magaeva tette ezt a filozofiat, pl. egy Symantec Endpoint scan-t elinditani parancssorbol olyan korulmenyes, amivel nagyjabol a DOS korszakban talalkoztam utoljara.
sh4d0w félisten

#190
#181 urandom0
2024-12-12 19:20:31

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#181 urandom0

#181 urandom0
Ne az én fogalmázáskészégemről szoljón a topik, kérlek titeket. Lehet persze kritizálni, csak nem biztos, hogy van értelme.
totron
Nem arról van szó, hogy Árnyék kolléga jobban meg tudta fogalmazni, hanem arról, hogy azt írta, amit hallani akarsz.
sh4d0w
Én abszolút értékelem, hogy a Debian security csapat ilyen sokat tesz a biztonságért, nekem csak annyi a problémám, hogy eddig senki nem tudta bemutatni azt a dokumentációt, ami leírja, hogy a csomagbefogadás során mit és hogyan ellenőriznek.
Az AI véleményére pedig, ha nem haragszol, nem adok egy lyukas garast sem.
Azt pedig kizártnak tartom, hogy alapos codereview-t végeznek minden egyes programon. Mennyi csomag van most egy Debianban kiadásban, 65 ezer? Ha ezeknek csak a negyede szoftver, az is 16 ezer csomagot jelent. A világ összes programozója nem lenne elég arra, hogy ennyi csomagot alaposan átnézzen.
Abban egyetértünk, hogy a 3rd party repó legyen az utolsó, ahhonan az ember letölt bármit is. Csak abban nem, hogy én a Flathubot nem tartom úgy 3rd party repónak, mint mondjuk az AUR-t vagy a COPR-t, mert azokat senki nem ellenőrzi. Ahhoz képest egyébként, hogy mennyire nem ellenőrzi az AUR-t senki sem, eddig egyetlen egy esetben találtak benne veszélyes programot, az is egy kriptominer volt. Egyébként a miner a user systemd unitjai közé írta be a sajátját - flatpak esetén ezt alapból nem tudta volna megtenni, mert nincs hozzá jogosultsága.
Én nem tartom veszélyesebbnek a Flathubot, mint mondjuk az universe vagy multiverse repókat.
-----
Viszont a gyakorlatban alig van olyan ember, aki csak a repó által biztosított csomagokat használja. Ha valaki töltött le valaha az életben egy Gnome kiterjesztést, egy KDE témát, egy akármilyen .sh fájlt, egy scriptet a Gimphez, bármilyen Python vagy NodeJS modult... akkor ő már eleve veszélynek tette ki magát. De akár egy szimpla böngésző-kiegészítő is lehet veszélyes.

Mondtam mar, hogy kerdezd meg oket. Nemigen ertem egyebkent ezt a fajta bizalmatlansagot a Debian fele, mikor vakon bizol a Flathubban, pedig ott nincs biztonsagi ellenorzes, raadasul a Debian repository-k 1st party, a Flathub meg akarmilyen disztribucion 3rd party - teljesen mellekes, hogy Te mit gondolsz rola. Code review eseten egyebkent sokat lehet optimalizalni a folyamaton, plane, hogy a csomagok egy resze alig 1-2 KB terjedelmu, egy bevizsgalt csomag eseten meg utana eleg a diff-eket megnezni.
sh4d0w félisten

#175
#151 urandom0
2024-12-11 22:00:29

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#151 urandom0

#151 urandom0
Ja értem, oké
Tehát tulajdonképpen nincs semmilyen vizsgálat. Pedig jó lenne, ha lenne, talán akkor a Debian stable sem lenne tele sebezhetőségekkel
De távol álljon tőlem, hogy bántsam a Debiant, egy nagyon jó rendszernek tartom. A maintainereknek is minden elismerésem.
De némi józan ésszel könnyen belátható, hogy nincs olyan teszt a világon, ami - néhány triviális biztonsági problémát leszámítva - alkalmas lenne arra, hogy a csomagok biztonságát garantálják. Vannak automatizált tesztek, amik bizonyos patterneket (SQL injection, XSS, stb.) illetve megtalálnak backdoorokat, malware-eket. Ilyeneket le lehet futtatni, de ehhez is kell szakember, idő, energia.
A legbiztosabb módszer a sebezhetőségek kiszűrésére az, amit Lasse Collin is megtett, hogy sorról sorra, commitról commitra végigellenőrizni a forráskódot.

Aligha hiszem, hogy van okod ilyesmit kijelenteni. A megbizhatosag magaban foglalja a biztonsagot is es nem veletlenul letezik a Debian Security Team. Termeszetesen soha senki nem jelentette ki - ebben a topicban sem -, hogy nincs es nem lesz a Debianban sebezhetoseg, mindazonaltal szeretnek ramutatni, mekkora ostobasag volt a linked: 2023. junius 10-en jelent meg a jelenlegi stable es belinkeltel tobbnyire 2024-es CVE-ket. Kabe nagyjabol 1-2 lehet ezekbol a CVE-kbol olyan, ami a kiadas idejen tenylegesen detektalhato lett volna. Mindezeken tul az sem mindegy, hogy egy sebezhetoseg CVSS score-ja mondjuk 4.0 alatt van, vagy sem. Nagyon sok helyen a medium besorolast kapott serulekenysegek nem showstopperek, hanem a javitas megerkezeseig mitigalandok vagy security sign-off-ot igenylok.
Nemcsak a csomagok/modulok, hanem a teljes szoftverek biztonsagat sem lehet garantalni, de vannak olyan eszkozok, amelyek meg forraskod formaban kepesek ramutatni vagy a programozasbol szarmazo kozvetlen biztonsagi hibakra (pl. c kodban hianyzik a user controlled valtozo hosszanak ellenorzese), vagy a mar bejegyzett serulekenyseggel hasznalt komponensekre - mindezt automatikusan a CI/CD pipeline-ban, human beavatkozas nelkul. Nem kerek arra valo hivatkozast, hogy a Linuxra fejleszto hobbiprogramozoknak nem telik CI/CD pipeline-ra, vagy Sonarqube-ra, mert mindegyik kivitelezheto ingyen, vagy tenyleg gombokert, masreszt egy reszuk biztosan nem hobbiprogramozo, hanem professzionalis, aki a munkahelyen csinalja az uzleti szoftver, a szabad idejeben meg Linuxra ir valamit.
Megkerdeztem tobb, egymastol fuggetlen AI-t is, milyen biztonsagi ellenorzeseket vegeznek a Debian Projectben: code review, dependency CVE check, vulnerability scanning - a teljesseg igenye nelkul.
"Milyen egy biztonsági ellenőrzés egyébként?
Hát ez az, pont erre várom én is a választ tőletek "
Nem, nem ezt kerdezted, hanem azt, hogy Debianek milyen ellenorzeseket vegeznek - nem biztos, hogy egy altalanos ellenorzes es a DB altal elvegzettek teljesen fedik egymast.
Az altalad leirtak alapjan en nem latom biztositottnak, hogy a Flathub megbizhato csomagokat kinal es tovabbra is fenntartom azt a velemenyemet, hogy nagyjabol az utolso megoldas legyen barmelyik 3rd party csomagforras hasznalata, beleertve a PPA-kat is.
Ettol fuggetlenul felolem mindenki azt hasznal, amit akar es meg csak karorvendeni sem fogok, ha valaki emiatt bekap valami tamadast, azt viszont nagyon is szeretnem elerni, hogy aki ebbe a topicba teved, vagy mar itt van, tisztan lassa a veszelyeket, a mukodesi mechanizmusokat, veszelyeket.
sh4d0w félisten

#149
#148 urandom0
2024-12-11 07:13:18

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#148 urandom0

#148 urandom0
Pontosan mit foglal magában ez a vizsgálat, és ki végzi el?

Kérdezd Debianékst.
sh4d0w félisten

#147
#146 urandom0
2024-12-11 06:52:09

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#146 urandom0

#146 urandom0
És ez pont így van bármely disztribúció bármely csomagjával.

Pont nem, pl. Debian alatt. Stable-be csak biztonsági oldalról is megvizsgált csomagok kerülhetnek be. Ez persze nem jelenti azt, hogy időnként nem csúszik át ez-az, de az esélye sokkal kisebb, mint más esetekben, ahol egyáltalán nincs vizsgálat.
Kiváló példa az xz backdoor.
sh4d0w félisten

#145
#140 Rowon
2024-12-10 23:42:05

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#140 Rowon

#140 Rowon
A Flathubon futtatnak valamilyen biztonsági ellenőrzést a feltöltött csomagokon?

Nem. Irsz egy programot, becsomagolod flatpaknek, feltoltod a Flathubra, userek meg elkezdik letolteni. Ha initially nem raktal bele ganyesagot, kesobb - mint a maintainer - meg mindig megteheted.
sh4d0w félisten

#106
#104 urandom0
2024-12-07 21:11:13

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#104 urandom0

#104 urandom0
A Red Hat nem kommercializálta a Linuxot, nem is volt célja. A Canonical volt ráálva erre a témára kb. 20 éven keresztül, de pár éve (sok milliárd EUR elégetése után) rájött, hogy ez nem fog működni. Azóta gyakorlatilag annyi az Ubuntu, hogy fognak egy Debian unstable-t, újraforgatják egy saját patch settel, aztán megbrandelik saját névvel, hátterekkel, egyebekkel és kiadják más néven. Nem mintha ez olyan rossz lenne, szerintem az Ubuntu azóta jó, amióta a Canonical csak minimálisan nyúl bele.
A fejlesztőcégek folyamatosan azon pörögnek, ha szóba kerül a Linux, hogy nehéz rá fejleszteni, mert semmi sem egységes. Se a disztrók, se a csomagformátumok, se az asztali környezetek, semmi. A flatpakkal kapcsolatos egyik várokozás az, hogy ezt a szétszórtságot kicsit összerakja, lesz egységes csomagformátum az appoknak, egységes store (legalább webes, ha asztali egyelőre nem is), és lesznek fizetős appok is, így az appfejlesztők majd nagyobb kedvvel fordulnak a Linux felé, ami elméletileg több és jobb minőségű appokat eredményez, ami több Linux usert, és így nagyobb piaci részesedést vonz be.
Majd meglátjuk, így lesz-e.
Amúgy ez inkább Macesítés, mint Windowsosítás. A Flatpak a MacOS-féle .app formátumhoz hasonlít.

Naaaaaa.
"Red Hat went public on August 11, 1999". Non-profit cegek nem mennek tozsdere.
sh4d0w félisten

#90
#89 DarkByte
2024-12-06 21:36:26

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#89 DarkByte

#89 DarkByte
A Flatpak előnye az egyszerűbb bináris terjesztés.
Ahogy Torvalds is mondta, a nagy cégek szempontjából pont az egyik nagy probléma a Linux-ra fejlesztéssel, hogy rengeteg környezet lehetséges, és ezek összes kombinációjára lehetetlenség érdemi QA-t és support-ot adni értelmes költség mellett. (azt hiszem a DebConf14-es talk-jában magyarázta, hogy egy búvárkomputerhez való szoftvert fejleszt a cége, és konkrétan egy ponton inkább felhagytak a Linux támogatással, mert egyszerűen nem térül meg.. ouch)
A Flatpak-el össze lehet zárni az app-ot a függőségeivel amivel garantáltan tesztelve lett és menni fog. Kvázi Docker az app-okra. Egy lóugrással átugorja a disztrók különbözőségeit, azok csináljanak amit akarnak.

Aham... csak mondjuk ahol csomagoljak, ott egy uj libc6 van, ahol me hasznalni akarjak, egy regebbi es maris nagy esellyel bukta.
sh4d0w félisten

#74
#67 urandom0
2024-12-06 12:35:45

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#67 urandom0

#67 urandom0
Mert a böngésző egy moving target, és amikor komolyabb webappot fejlesztesz, akkor ott van előtted egy krva nagy kompatibilitási mátrix, ahol azt kell lesegetned, hogy adott böngésző adott verziója éppen mivel kompatibilis.
Ha odacsomagolod a böngészőt az app mellé, akkor meg nincs ilyen probléma.

Talán nincs ilyen probléma, cserébe sokkal többet kér diskből, memóriából, CPU-ból és sokkal lassabb. Egyébként meg - mivel alapvetően böngészőkre készülnek a webappok -, nem látom az érv validitását.
sh4d0w félisten

#65 2024-12-06 11:59:46

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

Az sem világos, miért kell olyanokat becsomagolni bármibe, ami webapp? Discord, Teams, Zoom, Slack stb. mind webapp, böngészőből használható. Csomagolva kapsz egy electronjs alkalmazást, ami pont ugyanazt a felületet jeleníti meg, amit a böngészőben is látna a user.
sh4d0w félisten

#30
#12 urandom0
2024-12-05 20:50:11

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#12 urandom0

#12 urandom0
A legtöbb flatpak csomag közvetlenül a Github repóból készül a Flathub infráján, teljesen nyitott manifest fájllal. Az ilyenek visszaellenőrizhetők.
Vannak persze olyanok is, ahol prebuild binaryt töltenek fel, de hát ez elkerülhetetlen olyan esetekben, amikor nem nyílt forráskódú programról beszélünk. De hát még magában a kernelben is vannak closed-source részek...
Biztonsag szempontbol egy olyan platform, ami egy egyszeru dotfile-lal torheto,
Ez kb. ugyanaz a szituáció, mint ha fognál valakit, leültetnéd a géped elé, adnál neki root jogokat és kijelentenéd, hogy a Linux nem biztonságos, mert bárki feltörheti.
Ha valaki random dolgokat tölt le a netről, és vakon ad nekik futtatási jogosultságokat, és le is futtatja őket, akkor ne csodálkozzon, ha lyukas a rendszere, mint az ementáli.
Mert amúgy a ~/.local/share/flatpak/ könyvtár a flatpak alkalmazások számára NEM elérhető, amíg explicit módon nem adsz rá engedélyeket.
Másrészt ezzel a módszerrel csak olyan jogosultságok adhatók az appoknak, amivel egy csomagkezelőből letöltött program vagy egy appimage alapból rendelkezik. Tehát még mindig van egy plusz védelmi réteg a flatpak appoknál, amivel a csomagkezelős programok, a random weboldalakról letöltött csomagok vagy binárisok, illetve az appimage-ek nem rendelkeznek.
Egyébként a hosszútávú cél az, hogy a statikus jogosultságok megszűnjenek, vagy legalábbis a minimumra csökkenjen a használatuk, és a helyüket átvegyék a portálok.
az minden, csak nem biztonsagos, ennel meg a normal csomagokra vonatkozo ACL-ek (SELinux, AppArmor) es filesystem jogosultsagok is nagyobb vedelmet nyujtanak.
Igen, azt a pillanatot várom én is, amikor az átlagos Linux felhasználó SELinux policyket fog írkálni
Az érveid közül én egyedül azt látom aggályosnak, hogy a flatpak csomagban lehetnek olyan binaryk, amiket nem nyílt forráskódból építettek, illetve nem bizonyítható, hogy az adott app abból a forráskódból épült, amire hivatkozik. De hát ez utóbbi biztosítása sem jelent garanciát, lásd az xz esetét.
Egyébként a Flathub webes felületén van olyan szűrő, ahol be tudod pipálni, hogy csak nyílt forráskódú és csak verified appokat mutasson: https://flathub.org/apps/search?q=image

"A legtöbb flatpak csomag közvetlenül a Github repóból készül a Flathub infráján, teljesen nyitott manifest fájllal. Az ilyenek visszaellenőrizhetők."
Nem az a lenyeg, hogy visszaellenorizheto-e, hanem hogy megteszi-e valaki, mielott a userhez eljut a file es nem, nem teszi meg senki.
"Ez kb. ugyanaz a szituáció, mint ha fognál valakit, leültetnéd a géped elé, adnál neki root jogokat és kijelentenéd, hogy a Linux nem biztonságos, mert bárki feltörheti.
Ha valaki random dolgokat tölt le a netről, és vakon ad nekik futtatási jogosultságokat, és le is futtatja őket, akkor ne csodálkozzon, ha lyukas a rendszere, mint az ementáli."
Ezzel most nem mondasz ellen, hanem pont egyetertesz velem a sandbox semmilyenseget illetoen.
"Igen, azt a pillanatot várom én is, amikor az átlagos Linux felhasználó SELinux policyket fog írkálni."
Javasolnam, hogy ne menjunk egy bizonyos szint ala.
/.local es tarsai: iden aprilisi a bejegyzes a Fedora project foruman.
Meg egy szo a Flatsealrol, mert korabban nem olvastam azt az oldalt. Ez a masik olyan alkalmazas, ami ebben az egesz okoszisztemaban iszonyu veszelyes - ha valami, hat ez a root jelszo a sima usernek, mert nem csak a jogosultsagok szukebbre vonasara alkalmas, hanem azok kitejesztesere is.
Mindezek melle koszonom, hogy jobban kitertel a security-re is, meg ha az by design nem is jo.
sh4d0w félisten

#29
#17 sonar
2024-12-05 20:07:31

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#17 sonar

#17 sonar
Egy laikus kérdés. Ilyen szempontból a snap és az appimage jobb?

Nem.
sh4d0w félisten

#11
#10 urandom0
2024-12-05 00:14:46

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#10 urandom0

#10 urandom0
A verified flatpak az egvilagon semmilyen biztonsagot nem ad, mert artalmas kod kesobb is belekerulhet az appba, hiaba egy a fejleszto es a koder.
Az összes repó, csomag, minden alá van írva, abba biztosan nem nyúlkál bele senki.
A usernek pedig nem olyan szoftvert kell adni, amirol reklamozzuk, hogy secure es kozben egy mozdulattal megsemmisitheto a vedelmi vonala, hanem olyat, ami tenylegesen biztonsagos.
Szerintem olyan nincs, hogy a kényelem és a biztonság ne mennének egymás rovására. Eleve nehéz azt definiálni, hogy mi a biztonság, és mi a biztonságos. Legfeljebb elvárható biztonságról lehet beszélni, ebből a szempontból a Flatpak szerintem jól működik. Ő a technikai felételeket biztosítja hozzá, azt, hogy ha pl. letiltod a hozzáférést a /home-hoz, akkor ahhoz nem fog hozzáférni. És én meg arra utalok vissza, hogy ezt ilyen könnyen nem tudod megtenni hagyományos csomagkezeléssel.
Egyébként minden védelmi vonal megsemmisíthető, ha a user elég ügyes hozzá.

Meg mindig nem erted. A fejleszto sajat maga rakja bele az arto kodot a fejlesztesebe, miutan az installbase eleg nagy lett. Itt aztan alairhatsz barmit.
Biztonsag szempontbol egy olyan platform, ami egy egyszeru dotfile-lal torheto, az minden, csak nem biztonsagos, ennel meg a normal csomagokra vonatkozo ACL-ek (SELinux, AppArmor) es filesystem jogosultsagok is nagyobb vedelmet nyujtanak.
De az utolso mondattal legalabb egyet lehet erteni.
sh4d0w félisten

#9
#8 urandom0
2024-12-04 23:23:33

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

#8 urandom0

#8 urandom0
Ez igaz, de:
1. a runtime-ok folyamatosan frissülnek, egyébként jelezve van (paranccsorban is, Flathub felületén is, Warehouse-ben is, Gnome Software-ben is) ha valamelyik runtime túllépte az EOL-t.
A flatpakon belüli binárisok állapota valóban lehet kérdéses, erre találták az a f-e-d-c-t, ami végigellenőrzi, hogy van-e elavult függőség a csomagban. Ezt nem csak a fejlesztők használhatják, hanem maga a Flathub is használja folyamatosan, és ha elavult függőséget talál, a Flathub bot pull requestet küld.
De egyébként a csomagtelepítős programok közül is van olyan, ami saját binárisokat hoz magával, azokra sincs garancia, hogy nincs bennük sebezhetőség.
2. az appok jogosultságait te, mint felhasználó, nagyon egyszerűen meg tudod nézni (Flathub felületén pl. ott is van, hogy tudja írni/olvasni a home foldert) és át tudod állítani, ellentétben a csomagkezelőből érkezett programokkal, amikkel ezt azért sokkal nehezebb megtenni.
És ha verified flatpakot töltesz le, akkor biztos lehetsz benne, hogy ugyanaz készítette a flatpakot, mint aki a programot is, tehát szándékosan rossz indulatú kódot nagy valószínűséggel nem tartalmaz.
De azzal szerintem te is egyetértesz, hogy nem lehet úgy odaadni a végfelhasználónak egy szoftvert, hogy ne lenne filesystem=user jogosultsága. Nagyon sok program így gyakorlatilag használhatatlanná válna.

Speciel Debian eseten van biztonsagi ellenorzes a csomagokra, mielott a stable-be kerul. Az olyan slendrian disztribuciok, mint az Ubuntu, persze futyulnek erre, tobbek kozott ezert kaptak be az xz-alapu ssh backdoort.
A verified flatpak az egvilagon semmilyen biztonsagot nem ad, mert artalmas kod kesobb is belekerulhet az appba, hiaba egy a fejleszto es a koder. Megint visszautalok az xz-re, ahol egy uj fejleszto vette at a csomag karbantartasat, majd idovel becsempeszte a backdoort.
A usernek pedig nem olyan szoftvert kell adni, amirol reklamozzuk, hogy secure es kozben egy mozdulattal megsemmisitheto a vedelmi vonala, hanem olyat, ami tenylegesen biztonsagos.
sh4d0w félisten

#7 2024-12-04 21:14:44

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

sh4d0w

félisten

Koszi az irast, szep munka, hogy utana mentel - azt viszont sajnalom, hogy a biztonsagrol szolo resz csak egy ocska marketing duma, semmi tobb.
Eloszor is, a flatpak nem fog frissulni, tehat biztonsagi hiba eseten meg kell varni, mig a csomag karbantartoja elkesziti a friss flatpeket - ha egyaltan megtortenik. Masodszor, a flatpak annyira biztonsagos, amennyire azza tette a fejleszto. Harmadszor, a sandbox sem ugy igaz, ahogy azt az egyszeru halando kepzeli, mert a flatpak meg mindig nem szabalyozza az appok jogosultsagait, hanem az appokra hagyja, hogy elkeszitsek a sajat policy-juket. Ha egy flatpak alkalmazas filesystem=host vagy filesystem=home jogosultsagokkal van konfiguralva, akkor meg ebbol a gyengen vedett sandboxbol is eleg egyszeruen ki lehet torni.