Hoezo Linux veilig? Zie je link & thanks for the underpinning:
"The clear consensus at the Linux Security Summit was that squashing bugs is a losing strategy. Many deployed devices running Linux will never receive security updates, and patching a security hole in the upstream kernel does nothing to ensure the safety of an IoT device that could be in use for a decade and may forever be ignored by the manufacturer."

Je kan hier (https://wiki.openjdk.java.net/display/BSDPort/Main eens kijken

Enige wat OpenBSD kan is features van GRSecurity (https://grsecurity.net/) stelen. Gebruik Linux, maar gebruik GRSecurity.

Inderdaad ;-) want het probleem is dat software security needs fixing.

Ik vrees dat mensen niet intelligent genoeg zijn om zodanig lekarme software te maken dat de kans op uitbuiting verwaarloosbaar is. De gedachte "hoe dan wel" beangstigt mij.

Erik, ik denk dat er wel mensen zijn intelligent genoeg voor veilige ict systemen. Een hal2000 zie ik niet meer als ict systeem, zoiets is inderdaad beangstigend.

Van alles is gebaseerd op heel oude concepten met beperkingen en aannames. Neem nou memory vrijgave in c libraries. Het is geen standaard om memory te schonen bij vrijgave zo'n optie bestaat wel bij de allocatie. Raar, het hoort juist bij vrijgave eenvoudig foutloos te gaan.
Met selinux kan je de processen goed isoleren (confinement) Met cgroups heb je iets overeenkomstig op een ander niveau. Virtualisatie van het os is weer iets anders.
Er zijn drie opties (en meer) om iets in te perken.

In de praktijk wordt er uit kosten en time to market maar een enkele optie tot afscherming en stabiliteit toegestaan. (Root cause 1)
Techneuten met hun eigen wereld roepen een bepaalde strategie als de heilg graal. Docker Virtualisatie is voor de applicatiebeheerder om op te lossen (root cause 2)
Dan is er nog het beeld dat ICT niets voorsteld. Het is iets wat kinderen op school al goed doen (root cause 3).
Als je meer root causes ziet. Noem ze maar.
Dan wordt het ze stuk voor stuk zien aan te pakken.

Het shellshock verhaal is een mooi voorbeeld. Er was iets raars in de parameterdoorgave netwerk (root) naar de Webserver(root). De vragen:
- Waarom er daarvoor een complete shell nodig zou zijn. Een beperkt stukje code is veiliger.
- waarom heeft confinement niets tegengehouden
- waar zit de afvang voor het Webserver proces
- Hoe zit het met de afscherming van de gevoelige gegevens.
Nu was alle aandacht op het pleistertje in de bash-shell.
Jammer.

De gewenste situatie zou moeten zijn (ars technica) gaat er eens iets niet goed dan zijn er nog meer veiligheden.
Het moet niet een ketting zijn afhankelijk van de zwakste schakel, maar een aantal combinaties.
Als je vaart, eigen mogelijkheden kennen, wat het schip aankan , vaarwater kennen, weer inschatten, alternatieve uitwijklocaties etc.. Als het dan alsnog mis gaat is het niet een enkel foutje.

OpenBSD heeft hetzelfde probleem als Linux, een monolithische kernel waar een bug in een device driver de veiligheid van het hele systeem om zeep kan helpen.

Karma4, goede bijdrage! Meer compartimentisering is een antwoord om de gevolgen van aanvallen te beperken; betere code produceren ook. Een belangrijke root-cause is dat Unix is ontworpen in een tijd dat computernetwerken nog nauwelijks bestonden en fysieke beveiliging (de portier bij de voordeur) een niet te verwaarlozen component was.

En ik heb nog een gemene vraag: Welke besturingsssystemen gebruiken de IOMMU om de toegang van uitbreidingskaarten tot het geheugen te beperken? Anders kan malafide firmware in een van deze kaarten vertrouwelijke gegevens uitlezen of data (van het besturingssysteem) aanpassen.

Laten we even aannemen dat op een bepaald systeem maar 10% van alle beschikbare device drivers gebruikt worden, de andere 90% is niet nodig omdat de hardware er niet is. Dan heeft draaiende Linux kernel maar 15+8.5=23.5% van de totaal bekende veiligheidsbugs geladen.
De OpenBSD kernel heeft 100% van de bekende veiligheidsbugs geladen, maar daarvan zal een percentage niet te exploiteren zijn zonder aanwezigheid van het hardware device. Maar die buggy code kan mischien wel op een andere manier uitgebuit worden.

(Op zich is er heel wat voor te zeggen om loadable modules uit te schakelen; code die in kernel mode uitgevoerd wordt is een heel hoog veiligheidsrisico en door dat van het bestandssysteem te kunnen laden creeer je een groot veiligheidsgat.)

Tip voor de OpenBSD developers: je moet gewoon de ondersteuning voor storage devices (disks enzo) laten vallen!
De meeste spullen met bugs worden geladen van de storage devices. So do the math.

Ik geloof niet dat menselijke programmeurs tot 100% perfecte code in staat zijn, audits en tools kunnen enorm helpen de kwaliteit van de code te verbeteren en ik weet dat de OpenBSD code een orde beter is dan Linux, maar helaas gaat dat weer ten koste van de hardware ondersteuning.

De goede vragen om te stellen zijn:
1: Biedt OpenBSD/Linux/Windows/... de functionaliteit die je nodig hebt voor jouw beoogd gebruik?
2: Is OpenBSD/Linux/Windows/... veilig genoeg voor jouw beoogd gebruik?

Eigenlijk zeggen ze gewoon dat een open systeem niet goed is want als je een open systeem hebt dan kunnen er
ook andere programmeurs dan jijzelf (dus allemaal slechte programmeurs) software op de machine draaien.

Dat is toch ook het argument wat Microsoft hanteert? Zijn we daar nu ineens een fan van of zijn het gewoon
de kritiekloze OpenBSD adepten die hier in meegaan?

Het is 100% duidelijk dat als je flexibiliteit uit het systeem sloopt de mogelijkheid van misbruik vermindert.
Op een home computer met BASIC in ROM had je ook nooit last van ongewenste software.
Maar het is gewoon niet reeel om dit soort functionaliteit te verwijderen omdat het misbruikt zou kunnen worden,
daar is het veel te nuttig voor.

(ik ben biased omdat ik degene ben die het kernel module systeem ooit voorgesteld heeft, inclusief de methode
om de compatabiliteit van de interface te valideren met MODVERSIONS. ik heb het niet geimplementeerd in
Linux maar had zo iets gemaakt voor System V Unix)

Dat hoort ook niet bij vrijgave te gebeuren, althans niet standaard, veel te inefficiënt. Overigens gebeurt dit opschonen bij allocatie ook alleen wanneer je daarom 'vraagt'. Schoonmaken bij vrijgave is een feature die zelden nodig is en wanneer dan kies je specifiek een memory management library die het doet, of je laat het OS dat voor je doen.

Normaal gesproken compileer je een kernel met alleen die devicedrivers 'ingebakken' die je ook echt wilt gebruiken.

Ook voor de C64 waren er virussen, en ook nog behoorlijk geavanceerd: http://virus.wikia.com/wiki/Com64/BHP

Ja dat was bij Linux in het begin ook zo. Iedereen moest zijn eigen kernel compileren. En uiteraard eerst die 200
vragen beantwoorden over devices en features die er al of niet in moesten.

Maar goed, die tijd hebben we gelukkig achter ons gelaten.

Dat gaat nog wel even anders over!
Er is een strijd bij de puristen die zelf niks met hun computer doen of het toegestaan moet zijn dat een fabrikant een
driver module meelevert zonder source. Dat zou dan volgens mensen niet mogen en er is een club ontwikkelaars die
heel graag stunts uithaalt om het die fabrikanten lastig te maken (zoals de hele tijd de driver interface aanpassen).

Linus vindt dat dat dus wel moet kunnen.
Maar waar men bij OpenBSD kennelijk op wil overgaan is dat het hele laden van modules niet meer kan, dus ook niet
modules waar wel source van is en die men bij de kernel packaged.

Je bent een beetje kwijt waar het over ging.

Uitdaging aangenomen. (had je anders verwacht?).

Ik vind:
https://software.intel.com/en-us/blogs/2009/03/02/intels-virtualization-for-directed-io-aka-iommu-part-1 nieuw in d e x86 wereld. Het is op verzoek van Microsoft (pag 4 vt-d) door Intel gebouwd. Het sluit aan op de UEFI bios. De hardware moet van ruim na 2009 zijn evenals het OS. Het is vrij normaal dat die volgorde en vertraging zo plaatsvind. https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_Intel_VT-d_for_DMA_Protection.pdf
Waar doel je op? Volgens mason (IBM) http://www.mulix.org/lectures/using-iommus-for-virtualization/OLS-jdmason.pdf Clug en gemerged met Linux 2.6 https://www.kernel.org/doc/ols/2007/ols2007v1-pages-9-20.pdf

Welke OS systemen ondersteunen het?
De eerste hadden we al en verder https://msdn.microsoft.com/en-us/library/windows/hardware/dn894176(v=vs.85).aspx of https://msdn.microsoft.com/windows/hardware/drivers/network/virtualized-networking-concepts-and-terms
Ik verwacht het niet in het goedkope IOT spul. Een googlen of Apple het ook ondersteunt, lijkt goed te zitten. https://developer.apple.com/reference/kernel/iodmacommand/1811308-setmemorydescriptor?language=objc

Een flauwe vraag om een beetje te kietelen:
Welk hardware systeem kent per 4k memory page een extra byte voor ondersteuning in ring-kernel scheiding (storage protection). Flauw omdat het van +30 jaar geleden in een VM en Multi-user service processen basis pop-ontwerp is. Het UWV heeft een langlopend contract (sinds 2004) met de leverancier.

Mathfox de systemen van +30 jaar terug kenden geen uitbreidingsslots maar werkten met randapparatuur 3720 3704 (voor de 3270's) met daarop een eigen operatingsysteem. Dat alles aan te sluiten met channels (dikke 128 aderige kabels) dan wel via een SNA SDLC 9600b netwerk. Het was als moderner en geavanceerder dan Unix uit de jaren 60 (nog eens 20 jaar ouder). De draaiende multiuserprocessen gebouwd rond middleware met een eigen terminal cpu en memory management waarbij de code-kloppers niets van het OS mochten gebruiken maar de specifieke middleware Api's.

Daarmee had je ook settings om het memory management protected aan of uit te zetten. Bij ontwikkeling/test stond de protectie aan. De overhead is groot maar de belasting relatief laag, de kosten te verantwoorden . Echter in prod werd de memory protectie uit gezet omdat de kostprijs (cpu bijna verdubbeld) veel te hoog lag. Dat is een managementbeslissing met de onderbouwing da alle code uitvoering getest is. Die zelfde verhouding overhead zie je 30 jaar later weer terug in een eerdere link (2007).

De hele softwarengineering met fouten / bugs en architectuur gaat nog verder terug. Met oa Dijkstra in de http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF , kun je de woorden moderniseren de getallen met Moore laten meegaan en dan is het vebazend actueel. Ofwel we lijken in 40 jaar niet echt veel opgeschoten te zijn.

Ik hoop niet dat mijn bijdrage van gisterochtend aan het besluit van Muria heeft bijgedragen om zijn account te verwijderen, want dat was beslist niet mijn bedoeling. Integendeel, ik ga zijn bijdragen missen.

Wat ik overigens bedoelde in mijn bijdrage is dat ik verwacht dat wij mensen software zullen gaan ontwikkelen die software ontwikkelt die, na evolutie, veiliger zal zijn dan individuele of enkele mensen kunnen maken (zoals nu). Aanvankelijk zullen we (enkele mensen) nog wel kunnen begrijpen waarom die (door software ontwikkelde software) doet wat ie moet doen en waarom deze veiliger is dan wij zouden kunnen maken. En dat kwaadwillende mensen en er niet aan gerotzooid hebben.

Maar, zo verwacht ik, er komt een moment dat wij mensen out of control raken, o.a. doordat ontwikkelende software van kwaadwillenden zich in het proces heeft gevoegd en wij mensen dat niet meer kunnen ontwaren.

Eens echter volgens mij doe je geen voorspelling (toekomst) maar een beschrijving van de situatie hoe hij nu is.
Ooit ging je met de kennis van het systeem (hardware) aan de slag met machinetaal (assembler) niveau om een (beperkt) doel te bereiken. Nu heb ja daar software voor via compilers en ontwikkelframeworks.

Het liefst plakt men wat blokken her en der in de openbaarheid gevonden aan elkaar. Het argument dat heeft iemand anders al gemaakt hoef je geen tijd (kosten) aan te spenderen. De hoeveelheid code van kwaadwillenden (malware) loopt hard op zonder met een gebrek aan controle. Dat is waar we zo druk met "security" bezig zijn.

Als je een veiligere omgeving wilt, kijk dan eens naar genode.org.

Je zult zelf nog wel de java-runtime moeten porten.

Hallo Erik, zeker niet hoor! Ik stelde gewoon vast dat ik - weer - wat vastgeroest gedrag begon te vertonen en vond het daarom tijd om de bezem er weer eens door te halen.

Muria
-- Ardet nec consumitur ;-)

[OT]
Goed te lezen dat het niet aan mij lag!

Ik drink vanavond vanavond een biertje op je (maar dat zal, om logistieke redenen, wel een Chouffje worden :-)
https://en.wikipedia.org/wki/Grimbergen_%28beer%29#Label_and_slogan
[/OT]

@Anoniem 30-09-2016, 17:39: jij bent de grootste troll in deze thread. Ga je uitleven op Facebook of zo.

[OT]

Terug getrokken? Volgens mij heb je de betekenis van die Latijnse uitspraak niet begrepen.

(Over de Grimbergen associatie die je idd ook kan maken: proost Erik.)
[/OT end]

Geniet er van Muria Erik. De geneugten des levens met alle idealen. Het is een werkelijkheid boven die van de cyber.