Vraag werking Linux omtrent veiligheid

[partyrabbit]

Wat ik me afvraag, eigenlijk zomaar en zonder reden. Gewoon even vrijblijvend. Nieuwsgierigheid.

Op zich ken ik wel het principe van Linux.
Linux bestaat uit de kernel met daar omheen een schil (waarmee verschillende distri's gemaakt kunnen worden) en programma's.
De kernel schil is de zwaar beschermde kern van de veiligheid van linux. En de software daar omheen is bewerkelijk, doch ook veilig mits niet van vreemde derden maar uit de community gehaald.

Maar wat ik me nu afvraag is hoe breed dit werkt.
Ik moet uiteraard de software up2date houden, ook in het kader van de veiligheid.
Maar in hoeverre heeft de kernel invloed op en rol in de veiligheid van alle software daar omheen? (op schil + proggies)
Er bestaan lekken. Ook in schillen en programma's.

Is het bijvoorbeeld mogelijk dat buiten de kern(el) om via een lek in een programma rechtstreeks een ander programma benaderd kan worden?
Kan bijvoorbeeld(!) email in Thunderbird benaderd worden via een lek in Rhythmbox? Of bestanden via een lek in Gimp?
Of zit de kern(el) daar altijd nog tussen als veiligheidsbuffer? Of overkoepelt de kern(el) alles, en lopen alle bewerkingen altijd over de kern(el)?

Hoe moet ik dat zien?

[Bloom]

De kernel is alleen het stuk dat babbelt met je hardware. Er is een hele architectuur aan het werk bestaande uit meerdere schillen en waarvan de applicaties die je als gebruiker gebruikt, de buitenste laag zijn. De kernel heeft qua veiligheid geen enkele invloed op de hem omringende schillen van code.

In tegenstelling tot een ander OS beschouwt Linux niet elke code als uitvoerbaar en kunnen zogenaamde veiligheidslekken niet zo maar uitgebuit worden bij thuisgebruikers omdat die achter een router met lokale niet-routeerbare adressen zitten. Daar is normaal geen link van het internet naar die systemen geconfigureerd. Bij bedrijfsservers is dat natuurlijk wat anders en daar moet je dan ook een goede beveiliging toepassen met een fatsoenlijke firewall en IDPS (Intrusion Detection & Prevention System) of een UTM (Unified Threat Management system). Bij een desktopsysteem bestaan de dreigingen uit JavaScript die op je computer uitgevoerd wordt door een website via je browser, en uit uitvoerbare code die je systeem binnenkomt via een e-mail of chat. Dat laatste gebeurt bij dat andere OS redelijk vaak, maar bij Linux is dat soort code per definitie niet uitvoerbaar en gebeurt er dus niks. Let wel: e-mails met html-code aan boord zijn webpagina's en daar kan ook JavaScript inzitten die wél uitgevoerd wordt op je systeem. Daarom ben je best heel voorzichtig met wie je toestaat JavaScript uit te voeren en wie niet. Daar gebruik ik zelf een addon genaamd SafeScript voor: die bestaat zowel voor Chromium als voor Firefox. Voor de rest installeer je dingen zoals uBlock Origin en Privacy Badger en eventueel Auto-Deleting Cookies, dan ben je al héél veilig.

De architectuur van Linux zorgt ervoor, dat malware in feite geen kans maakt. De dag dat mensen software lukraak van internet binnenhalen en installeren zoals bij Windows en MacOS, stijgt die kans aanzienlijk. Bij Linux doe je dat niet omdat je software haalt binnen het voorgeïnstalleerde softwarebeheer. En die software is digitaal ondertekend en wordt (toch bij Debian) rigoureus gecontroleerd - bovendien mag niet eender wie software uploaden in het systeem. Dat draagt allemaal bij tot een zeer veilig systeem. Het andere OS is een ware gatenkaas die een brakke architectuur heeft zonder inherente veiligheid en dat wreekt zich al jaren. Vandaar de vele gevallen van malware en met name ransomware die de laatste tijd steeds vaker het nieuws halen. Helaas wordt bij die artikels nooit duidelijk gezegd dat dit volledig de schuld van dat andere OS is met zijn gebrekkige beveiliging en nog gebrekkiger architectuur en niet van de gebruikers. En dus zie je mensen en bedrijven na een ransomware-aanval hun systeem herbouwen met... krek hetzelfde. En kunnen ze nog wel zo'n ransomware-aanval verwachten vroeg of laat. Naarmate er meer gijzelsommen betaald worden, stijgt ook het aantal ransomwaregevallen vermits de makers dan weten dat er geld mee verdiend kan worden - veel geld. Welkom in de wondere wereld van het wereldwijde OS-monopolie.

[partyrabbit]

Op enkele termen na een heel duidelijke en verduidelijkend verhaal.

Ik begrijp het kortgevat zo.
Uitbuiten van eventuele lekken in rand-software (om de kernel) is niet mogelijk omdat op het moment van poging tot uitbuiten juist wel weer de kernel er bij betrokken raakt en de boel blokkeert.
Dus uiteindelijk staat dan (als in mijn vraagbewoording hierboven) de kernel er altijd toch weer tussen als ik het goed begrijp?

[Joshua Orbit]

Alles is zo sterk als de zwakste schakel is: root en root wachtwoord.

Dus het zwakke punt zal meer en meer afhangen van je discipline dan van het systeem zelf.

Maar ook: als we code a gaan aanvallen met code a hacking tools .... wie weet ? Dat is op dit moment niet duidelijk en een kristallen bol is er ook niet.

Wormen in Linux ..... volgens mij technisch mogelijk maar simpel ..... helemaal niet: maar ook daar is de discipline van de eindgebruiker een vereiste.

Kernels gaan een lock down krijgen, of 5.4 ging zo geport worden, daarmee is de ultra veiligheid ook gegarandeerd dat zomaar troep installeren of kernels tweaken zo goed als onmogelijk worden ..... vooral interessant voor smartphones (b.v. 1+ gebruikt soms een Ubuntu kernel) . Kortom : we komen dichterbij naar hack-free platforms , alleen is het nodig op de weg om ook uitdagingen (XXX en Warez-sites b.v. ) niet uit de weg te gaan; grondigheidstesten zijn ook nodig.

Maar Linux 5.4 is nu de LTS kernel voor 20.04 mét lock-down ..... daar moeten we uiteindelijk massaal op overstappen voor een nieuw begin van Ubuntu en de toekomst daarvan.

[vanadium]

Uitbuiten van eventuele lekken in rand-software (om de kernel) is niet mogelijk omdat op het moment van poging tot uitbuiten juist wel weer de kernel er bij betrokken raakt en de boel blokkeert.
Dus uiteindelijk staat dan (als in mijn vraagbewoording hierboven) de kernel er altijd toch weer tussen als ik het goed begrijp?

Toch niet:

De kernel is alleen het stuk dat babbelt met je hardware. Er is een hele architectuur aan het werk bestaande uit meerdere schillen en waarvan de applicaties die je als gebruiker gebruikt, de buitenste laag zijn. De kernel heeft qua veiligheid geen enkele invloed op de hem omringende schillen van code.

Er zijn verschillende factoren die van Linux een fundamenteel veiliger OS maken dan Windows zoals Bloom mooi uitlegt. De kernel is maar één van de "schillen" (BIOS, bootloader, kernel, user space en gebruikerssoftware, ...). Op elk van de niveaus zijn veiligheidslekken mogelijk.

[Bloom]

Ja, maar daarom niet noodzakelijk uitbuitbaar. Een veiligheidslek in Firefox kan in Linux bijvoorbeeld geen enkel probleem vormen en in Windows wel. Hetzelfde met lekken in processoren (Intel), die zijn ook steevast veel gevaarlijker in Windows dan in Linux. Ik heb het wel steeds over desktopsystemen. Servers die vanaf het internet bereikbaar zijn moeten altijd stevig afgeschermd en verdedigd worden, dat spreekt vanzelf.

[partyrabbit]

Duidelijk. Het is de combinatie van diverse punten wat het veilig maakt. Het moet ook bruikbaar blijven, en hoe meer de gebruiker activeert hoe meer er misbruikt kan worden.
Het ging me puur even technisch over de rol van de kernel, en de software onderling mbt de kernel.

Root wat Joshua vernoemd is er een belangrijke in. Zie ik het dan goed als ik zeg dat root weer embed zit in de kernel? Dus dat de kernel er weer tussen zit, en soms toestemming moet krijgen van de gebruiker voor bepaalde handelingen? Zoals installatie, wat hacksoftware ook wil maar dan natuurlijk niet krijgt.

[partyrabbit]

De kernel is maar één van de "schillen" (BIOS, bootloader, kernel, user space en gebruikerssoftware, ...). Op elk van de niveaus zijn veiligheidslekken mogelijk.

Deze wil ik er eigenlijk nog even uitlichten.

Ik begrijp wat je bedoeld. Maar daar zoek ik ook de nuance.

Als bv tunderbird een bug heeft, zou daar een virus door kunnen komen. Maar dat virus kan dan niets, want komt de kernel tegen waardoor hij niet kan installeren.
Dit principe is duidelijk.

Maar bestaat de mogelijkheid op lekken waarbij de kernel niet betrokken is?
Dat bijvoorbeeld Skype, waarmee bestanden verzonden kunnen worden, te selecteren mbv een mini bestandverkenner. Zijn dan bijvoorbeeld door een bug in skype hierdoor je bestanden te benaderen door een derde zonder dat de kernel betrokken raakt (want geen sprake van installatie backdoor?).
Of is dat bestandverkenner deel onder skype dan juist weer een kernel funtie, dus staat de kernel er toch weer tussen, wat dit uiteindelijk weer onmogelijk maakt?
Denk asn remote line comnands zoals we vroeger ook deden in dat win terminal proggie (hie heet dat ook alweer? Ben t ff kwijt)

Kort gezegd. Theoretisch zou in simpelere software sneller een makkelijke bug kunnen zitten. En daardoor andere simpelere software kunnen benaderen. Of is de kernel áltijd betrokken? Is de kernel áltijd significant onderdeel van de simpelere software?



"Simpelere software" = simpeler dan de kernel. Uiteraard nog steeds zeer ingewikkeld.

[Pjotr]

Vergeet niet, dat kwaadaardige programmatuur ook zonder root-toegang een hoop ellende kan aanrichten.... En dat staat helemaal los van de systeemkern.

Overigens is een onkraakbare systeemkern een illusie: alles is (uiteindelijk) te kraken en niets is geheel veilig. Zorg dus voor zoveel mogelijk niets (zoals een helaas overleden forumlid in zijn handtekening had staan).

Bij ellende zonder root-toegang kun je denken aan alles wat in je persoonlijke map staat: dat is immers zonder wachtwoord te lezen, te schrijven en te verwijderen.

De webverkenner (Firefox, Chrome, Chromium....) is daarom een belangrijk doelwit voor misdadigers, ook in Linux. Je ziet dan ook wel eens gebeuren dat het Firefoxprofiel van een Linuxgebruiker wordt besmet. Kan erg lastig zijn, ook al is het makkelijk op te lossen door simpelweg een nieuw Firefoxprofiel aan te maken.

Je kunt je webverkenner in de zandbak van Firejail draaien en zo, wat altijd een goed idee is natuurlijk, maar gezond verstand gebruiken is eigenlijk de meest effectieve bescherming.... En telkens op tijd je systeem bijwerken.

[partyrabbit]

Je kunt je webverkenner in de zandbak van Firejail draaien en zo, wat altijd een goed idee is natuurlijk, maar gezond verstand gebruiken is eigenlijk de meest effectieve bescherming.... En telkens op tijd je systeem bijwerken.

FF draait standaard al in een zandbak.
De rest van wat je uit legt is me bekend.

Wat mijn vraag vooral omvat is of (zie bijlage) de weg altijd de blauwe is, of dat de rode weg ook mogelijk is?
Of zeker niet want de rode weg onmogelijk??

[kfboerne]

FF draait standaard al in een zandbak.

Ik heb iets te lang onder een steen gelegen geloof ik . Sinds wanneer eigenlijk? Tot dusver gebruikte ik altijd het door Pjotr aangehaalde Firejail. Is dat dan niet meer nodig in FF? Biedt de FF-sandbox dezelfde veiligheid als Firejail, waardoor Firejail overbodig is geworden?

(Interessant topic trouwens!) 

[partyrabbit]

Sinds wanneer eigenlijk?

Sinds versie 60 ergens. Is hier al vaker besproken (ook door mij) dus kun je misschien wel terug vinden.

Tot dusver gebruikte ik altijd het door Pjotr aangehaalde Firejail. Is dat dan niet meer nodig in FF?

Geen idee. Ik ga er toch van uit dat als FF zo een beveiliging in bouwt dat deze minstens deugdelijk is. Dat FF niet iets zegt in te  bouwen wat niet werkt. Ik vertrouw op het nut ervan.
En we zijn alweer wat updates verder dus ik ga er ook vanuit dat deze functie inmiddels nog meer verbeterd is.
Zie ook mijn volgende reactie.

Biedt de FF-sandbox dezelfde veiligheid als Firejail, waardoor Firejail overbodig is geworden?

Ook dat durf ik niet te zeggen.
En al heb ik het zelf niet, afraden zou ik Firejail ook weer niet want dubbel is ook vaak niet verkeerd. Ik heb een add-blokker, en toch ook nog een scriptblocker. Ik zit achter twee routers, met twee firewalls en dus dubbele veiligheid (waarover ik niet verder in detail ga).

FF duckducken op 'firefox sandbox' en dan vind je heel veel informatie daarover.
Blijkt trouwens al sinds versie 57 zie ik nu ook.

[kfboerne]

En al heb ik het zelf niet, afraden zou ik Firejail ook weer niet want dubbel is ook vaak niet verkeerd.

Dat vraag ik me nou ook af. Is een dubbele sandbox veiliger dan een enkele? Of is het nutteloos? Ben benieuwd wat de 'wat-meer-dan-ondergetekende-technisch-onderlegden' hierover te melden hebben

[partyrabbit]

Dat vraag ik me nou ook af. Is een dubbele sandbox veiliger dan een enkele? Of is het nutteloos? Ben benieuwd wat de 'wat-meer-dan-ondergetekende-technisch-onderlegden' hierover te melden hebben

Geen idee omtrent sandbox en firejail (wat allebei 'hetzelfde' is). Dubbel is in elk geval soms wel 'meer' door aanvullen.
De scriptblocker hier houdt duidelijk toch weer dingen tegen wat de add-blocker door laat. De tweede router hier blokkeert duidelijk toegang vanaf de eerste router die al een blokkade op zich is voor externe toegang.

Firefox zelf heeft ook al de nodige beveiligingen, met daarbij dan nog de sandbox en de blockers, en dan nog de veiligheidsaspecten van de OS ... voor mij geen reden om nog meer dubbel te gaan doen.
Maar afraden zal ik het zeker niet doen want het zal ongetwijfeld wel weer wat bijdragen, of misschien zelfs wel beter zijn.
Pjotr is geloof ik erg thuis in Sandbox. Mogelijk kan hij er meer van zeggen.

[Polleke]

Grappig al die veiligheids- onderwerpen over de extra beveiliging van Linux systemen, met extra maatregelen zoals firejail en weet ik wat niet al.
Ik werk nu al ruim 10 jaar met Linux zonder extra beveiligingsmaatregelen en het is nog altijd goed gegaan: ik voel me wel veilig en comfortabel

[partyrabbit]

Hier draait alles op alle pc's ook ver core hoor Polleke.  Het enige wat ik extra draai zijn de blockers, en dan nog 1 meer dan de andere gebruikers hier die er maar 1 draaien. De sandbox is gewoon onderdeel van Firefox en is er met updaten bij gekomen (heb ik niet geinstalleerd).
Websites zijn nu eenmaal een grote risicofactor voor veiligheid en stabiliteit. En ik draai ze vooral vooral om infograbbing tegen te gaan, met als leuke bijkomstigheid dat andere !@#$%⁻scripts dan ook geblockt worden.

PS: het zijn er stiekem toch veel hoor. Snel tientallen tot honderden blocks, en bij sommige richting de duizend. Van soms tientallen externe infograbbing partijen. Soms verbazend tot beangstigend aan toe als je ziet wat voor informatie er verzameld wordt op websites waar je het niet van zou hoeven verwachten.
Op reguliere gangbare websites is dat, niets de rare of speciale. Die er na het blocken nog steeds ver hetzelfde uit zien en werken, dus scripts geblockt die weinig tot niets toevoegen. Daarnaast soms ook geruststellend dat partijen waar je het niet van hoeft te verwachten het ook daadwerkelijk niet doen.
Dus die blockers blijf ik er maar wat graag in houden.

[Pjotr]

Dat vraag ik me nou ook af. Is een dubbele sandbox veiliger dan een enkele? Of is het nutteloos? Ben benieuwd wat de 'wat-meer-dan-ondergetekende-technisch-onderlegden' hierover te melden hebben

Geen idee omtrent sandbox en firejail (wat allebei 'hetzelfde' is). Dubbel is in elk geval soms wel 'meer' door aanvullen.
De scriptblocker hier houdt duidelijk toch weer dingen tegen wat de add-blocker door laat. De tweede router hier blokkeert duidelijk toegang vanaf de eerste router die al een blokkade op zich is voor externe toegang.

Firefox zelf heeft ook al de nodige beveiligingen, met daarbij dan nog de sandbox en de blockers, en dan nog de veiligheidsaspecten van de OS ... voor mij geen reden om nog meer dubbel te gaan doen.
Maar afraden zal ik het zeker niet doen want het zal ongetwijfeld wel weer wat bijdragen, of misschien zelfs wel beter zijn.
Pjotr is geloof ik erg thuis in Sandbox. Mogelijk kan hij er meer van zeggen.

Zandbak Firejail heeft nog steeds nut; ook bij de nieuwste Firefox-met-ingebouwde-zandbak. Een eenvoudig proefje toont dat aan:

1. Start Firefox normaal, dus niet in de zandbak van Firejail. Klik in de werkbalk van Firefox op Bestand - Bestand openen...

Je kunt dan bij alle bestanden in je persoonlijke map. Firefox heeft dus onbelemmerd toegang tot alles in je persoonlijke map.

2. Start Firefox in de zandbak van Firejail. Klik in de werkbalk van Firefox op Bestand - Bestand openen...

Je kunt dan alleen bij de bestanden in de map Downloads van je persoonlijke map. Alle overige mappen zijn ontoegankelijk; je hebt alleen toegang tot gelijknamige nepmappen, die geheel leeg zijn.

Ziedaar de beveiliging van Firejail in actie. 

[partyrabbit]

Je kunt dan bij alle bestanden in je persoonlijke map. Firefox heeft dus onbelemmerd toegang tot alles in je persoonlijke map.

Ook met deugdelijke scriptblockers?
Over het algemeen zal er om je bestanden te kunnen benaderen toch iets van een script actief moeten zijn zou ik zeggen. Wat een scriptblocker tegen gaat? En daarnaast is een browser zelf niet zo gemaakt dat iemand zomaar bij jouw bestanden te kan.

In principe heeft zoals jij het zegt elk programma waarin je bestanden laadt "toegang tot je persoonlijke map, zolang je dat zelf activeert. Dat testje wil nog niet zeggen dat het van buitenaf zomaar toegankelijk is.

[vanadium]

In principe heeft zoals jij het zegt elk programma waarin je bestanden laadt "toegang tot je persoonlijke map, zolang je dat zelf activeert. Dat testje wil nog niet zeggen dat het van buitenaf zomaar toegankelijk is.

Als er een kwaadaardig script kan lopen, dan zal dit wel degelijk aan al je persoonlijke bestanden kunnen, net zoals je dat zelf kan. Niet meer, dus, met firejail.

[Pjotr]

Zoals vanadium zegt. Denk ook eens aan het scenario dat je een spionerende of zelfs kwaadaardige add-on installeert in je Firefox. Met Firejail kan die een stuk minder ellende aanrichten; hij kan dan alleen maar rondspoken in je Downloads-map.

[HWE64]

@Pjotr, ik kan zelfs niet meer vanuit FF73 een document zichtbaar maken. Ik moet het eerst downloaden, opslaan  en dan bekijken in downloads. Dit is wel onder Firejail. Zonder Firejail kan ik het document wel openen.

In het verleden kon ik het wel bekijken maar niet opslaan in documenten.  Dit is in Xubuntu 18.04.4 LTS

[partyrabbit]

Als er een kwaadaardig script kan lopen, dan zal dit wel degelijk aan al je persoonlijke bestanden kunnen, net zoals je dat zelf kan. Niet meer, dus, met firejail.

En daar ben ik niet zo bang voor. Ten eerste omdat ook FF enkele beveiligingen heeft en waarschuwt (vreemde sites en popups e.d.).
En niet te vergeten omdat ik serieuze scriptblockers heb draaien. Dus leuk dat scripts dat kunnen, maar scripts kunnen hier niets (blockers, linux) dus waarom zou ik daarvoor vrezen?!

Zoals vanadium zegt. Denk ook eens aan het scenario dat je een spionerende of zelfs kwaadaardige add-on installeert in je Firefox. Met Firejail kan die een stuk minder ellende aanrichten; hij kan dan alleen maar rondspoken in je Downloads-map.

Ik draai ook geen add-ons buiten de blockers.
Ik heb weleens een add-on gehad (andere pc) die wel een pagina probeerde te openen, maar zelfs die werd geblockt.
En ja, als je dat soort waarschuwingen gaat negeren en alsnog OK geeft ... duidelijk dat de gebruiker ook op moet blijven letten.

@Pjotr, ik kan zelfs niet meer vanuit FF73 een document zichtbaar maken. Ik moet het eerst downloaden, opslaan  en dan bekijken in downloads. Dit is wel onder Firejail. Zonder Firejail kan ik het document wel openen.

Dit klinkt mij een beetje tegenstrijdig. Downloaden lijkt mij dan toch weer meer risico dan offline openen (waar browser beveiligingen actief zijn).
Bij downloaden heb je ook de welbekende linux-beveiligingen, maar die zijn ook actief bij offline openen.

PS: Ik zeg NIET dat firejail slecht of overbodig is hè!!  Prima service! Ik leg alleen uit (omdat het gevraagd werd) waarom ik het hier niet zo dringend noodzakelijk acht.

Het enige wat naar mijn mening wel een risico kan zijn, en daarom ook dit topic, is toegang via (bugs in) randsoftware rechtstreeks naar andere randsoftware, waarbij de kernel omzeilt zou worden.
En daar gaat het niet eens direct alleen over FF maar naast de browser zoals ook anderen al aanhaalden, de bekende kanalen zoals LO (macro's), email (links, bijlagen), PDF-reader .... de bekende risico factoren.
Is hier altijd de kernel en daarmee de linux beveiligingsaspecten betrokken? Of kan deze omzeild worden?

[kfboerne]

Even voor wat betreft Firejail.

Firejail werkt supermakkelijk (via Pjotr's website : https://makkelijkelinuxtips.blogspot.com/p/zandbak.html)! Iedereen mag het uiteraard zelf weten, maar waarom Firejail dan niet gewoon standaard inschakelen?

[partyrabbit]

Die vraag heb ik al geantwoord. En ik bevestig het ook positief, al zie ik er voor mezelf geen toegevoegde waarde in. Ik antwoord dus niet nog een keer om niet in herhaling te vallen.

Hij hoeft niet beantwoord worden, maar bij mij blijft de vraag wat firejail sandbox toevoegd terwijl firefox sandbox (in mijn geval) al aanwezig is. Is firefox sandbox dan ondeugdelijk? Lijkt mij van niet.
Maar ik heb geen zin in discussie hierover, want m.i. allebei gewoon goed, dus beantwoord ook maar niet.