Heb je hem ook die vraag gesteld? Waarom hij dit veiliger vind?

Maar wat is veiliger?

Zou het niet veel handiger zijn om die vraag aan de systeembeheerder te stellen?

Out of the box is geen van beide veilig. Beveiliging regel je zelf. Denk oa aan: ongebruikte services uitzetten, access control (ssh, pam, sudo), iptables/nftables, mount flags, sysctl, intrusion detection.

Geen idee. Heb je het 'waarom' aan hem gevraagd?

Debian is in handen van mijn collega's en mijzelf veel veiliger dan zowel Red Hat als Ubuntu, maar dat is alleen maar omdat wij gezamenlijk meer dan 5.000+ jaar werkervaring met Linux hebben (ik overdrijf niet). Waarmee ik maar wil zeggen: dat het aankomt op de mate van expertise, opgedane werkervaring, goede connecties en de werksfeer.

Het bewijs van de boute claim die jouw collega ICT systeembeheerder doet, lig dan ook geheel bij hemzelf. Zowel Red Hat als Ubuntu zijn prima systemen, dus dat is het probleem niet, maar het is maar net wat je er mee doet, over hoeveel middelen je beschikt en hoeveel verstand je er echt van hebt.

Hiermee zul je het moeten doen.

Ik heb het te druk met het reanimeren van Windows, Citrix en het buiten de deur houden van de corona pandemie.

Bij Ubuntu moet je inderdaad iets meer zaken configureren/nalopen. Dit heeft te maken dat Ubuntu (versie afhankelijk) wat progressiever is met nieuwe programma's . Verder ben ik het eens met Anoniem (11:26).

Kan het zijn dat Ubuntu out-of-the-box nog wat nawerk nodig heeft voor een veilige werking en dat Redhat hier een voorgeconfigureerde optie voor heeft?
Verder ben ik het eens met Anoniem (11:26)

Jullie systeembeheerder is geen systeembeheerder.
Iemand die zoiets zegt moet je niet serieus nemen.

@ano 11:26 Wat is veilig .... tegen binnendringen zijn beide out of the box veilig.

Maar evengoed moet je altijd dit soort zaken afkaarten/nalopen. Onderdeel van de boel veilig maken/houden.
Doe je het niet, dan kun je geen garantie geven dat het goed staat. Prachtig voorbeeld van MongoDB fuckups, default paswoorden etc.

Jazeker wel. Out of the box (desktop) is Redhat heel veilig (ubuntu heb ik al een paar jaar niet naar gekeken).
Firwalld staat aan (staat niets toe vanaf buiten), selinux staat aan. ssh server staat standaard uit (als je die hebt geinstaklleerd). Je moet natuurlijk wel de laatste patches installeren, maar gelukkig is dat een fluitje van een cent.

Verder heb je natuurlijk diverse rollen die je kan installeren. Van minimum tot zeer uitgebreid.
Wat ik wel extra zou doen op een server is roottoegang van buiten uitzetten en alleen maar werken met ssh keys. Verder nog even fail2ban installeren om een brute force attack tegen te gaan, maar eigenlijk niet nodig als je password toeggang hebt uitgezet.
Verder reviewed Redhat elk pakket in de repository. Dat doet Cananical met Ubuntu volgens mij niet maar laat het over aan de community. Ubuntu heeft standaard ook veel meer repositories. In die zin zou je Ubuntu onveiliger kunnen noemen, maar ook bij Ubuntu heb je verschillende versies van out-of-the-box. Een minimal install die professionals meestal als basis gebruiken is extreem veilig bij allebei.
MongoDB heeft niks met een standaard out-of-the-box installatie te maken. Hetzelfde geldt voor default wachtwoorden. Die zijn er niet.

Niet om een heilige oorlog te starten, maar tegen de 3-letter agencies is geen van beide veilig.

Daar weet jij niks van, ik trek meteen mijn woorden in als je met bewijs komt.

@souplost

Hardening kan altijd.
Overigens hang ik geen enkele doos rechtstreeks aan het internet dus b.v. fail2ban heeft niet zoveel nut omdat ik alles blokkeer op mijn firewall behalve wat nodig is. Ik heb alleen echt interesse in het verkeer wat binnenkomt.

Achter een firewall wil overigens NIET zeggen dat je je services ook fatsoenlijk onder controle (authorisatie/authenticatie) moet hebben voor het geval je een keer een gaatje teveel prikt in je FW.

Wat wel? OpenBSD!

Zijn uitspraak heeft wellicht te maken doordat hij zelf Redhat ingesteld heeft en Ubuntu nog niet? Wellicht ook niet.. :-)
Verschillende distro's gebruiken specifieke kernels, zelfs als ze dezelfde versie hebben, zouden ze van elkaar op verschillende aspecten verschillen.

Ik denk dat statements hierover fout zijn.

Bittau et al. BROP attack

https://www.scs.stanford.edu/brop/bittau-brop.pdf

fail2ban heeft zeker nut. Wat dacht je als je server deel uitmaakt van een gehackt intern Microsoft netwerk. Dan wil je niet dat je Linux servers (waar in Maastricht de kroonjuwelen lagen) door een interne brute force attack onderuit gaan. Out of the box luisteren de services alleen lokaal en niet naar een vreemde tcp socket.
Natuurlijk moet je je services wel onder controle hebben voor het geval dat. Voorbeeld als je postfix installeert luistert het default alleen naar de localhost interface. Meer hoeft niet als je alleen mail wil versturen. Wel zo handig voor als je de smtp port per ongelijk wel open zet zet in je firewall en je postfix nog niet had gepatcht. Postfix is dan weer niet zo'n goed voorbeeld omdat het laatste belangrijke probleem uit 2011 stamt

Dit verhaal gaat niet over de NSA, wel o.a. over buffer overflows. Dankzij de NSA kan je je hiertegen beschermen (selinux). De NSA is er namelijk ook voor om Amerikaanse bedrijven te beschermen. SELinux is zo'n ontwikkeling. Daarnaast speelt Torvalds geen bugs door naar de NSA, die zijn namelijk al openbaar (open source). Microsoft doet dit wel en heeft waarschijnlijk ook zo'n nsakey beschikbaar gesteld. Maar ja, closed source. Mag niemand controleren. Dat is op zich al verdacht.

dit dus! daarnaast hefet RH alles on line GOED vindbaar UITGEBREID gedocumenteerd :

vergelijk

https://help.ubuntu.com/

maar eens met:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/

met bijvoorbeeld uitgelicht:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/index

Dat is aanzienlijk uitgebreider en diepgaander dan de documentatie van Ubuntu onder H9 security van bijv 18.04.

Dus, is RHEL veiliger dan Ubuntu? Ik zou zeggen ja, want out of de box zit het goed veilig geconfigureerd, gebruiken ze targeted SELinux (dat een tandje beter is dan AppArmor maar moeilijker), is er uitgebreidere diepgaandere security informatie beschikbaar en biedt die ook aspecten zoals SCAP profile based kickstart installs en uitgebreide systeem auditing logging.

Dat gezegd hebbende, is een Debian / Ubuntu systeem ook echt vrij veilig op te zetten, maar heb je toch wat meer ervaring zelf nodig en moet je zelf wat beter je bronnen zoeken etc. etc. dan dat je die bij RedHat dus beschikbaar hebt.

Ook weet ik uit ervaring dat de support bij RedHat, welliswaar niet goedkoop (en daarom gebruiken veel mensen CentOS) maar excelent is. De canonical ubuntu support is iets minder enterprise oriented merk ik maar ook niet meteen slecht.

Ik denk dus dat het grootste verschil de ervaring is die RH heeft tov Canonical in jaren in de buisness van Enteprise Linux omgevingen en SELinux.

ja als je bijvoorbeeld via een SCAP profile een automatische installatie doet:

https://www.open-scap.org/tools/oscap-anaconda-addon/

voorbeeldje hoe dat gaat:

https://www.open-scap.org/resources/documentation/installing-pci-dss-compliant-rhel-7-2-using-oscap-anaconda-add-on/

Out of box kun je ze beter even *onveilig* beschouwen.
Ze worden opgeleverd met maximale compatibiliteit in gedachte en dan kun je naar gelang de wensen bepaalde onderdelen wel of niet gaan gebruiken. Ik heb nog nooit van mijn leven een server meegemaakt die out of the box veiliger was. Tenzij er hele gerichte instructies richting de fabrikant waren gestuurd met dit moet er *vooraf* ingeregeld worden.

Wat wel zo is dat als je abonnement hebt bij Redhat je altijd toegang hebt tot security specialisten en ze beschikken over een heel scala aan bestpractice documenten waarbij voor Ubuntu ze wel bestaan maar qua detail niet zover gaan en je veel meer bent gewezen op zelf zoeken of vertrouwen op de community.

Ter vergelijking officiële security hardening document van Redhat
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/overview-of-security-hardening-security-hardening

En die van Ubuntu
https://help.ubuntu.com/lts/serverguide/security.html

Verder is out of box ondersteuning met commerciële producten over algemeen wel beter op Redhat omdat hun ook simpelweg betaalde partnerships met grote organisaties aangaan en dus meer geld tegen aan kunnen gooien om te zorgen dat alles soepel verloopt. Daarnaast is Redhat een hele grote influencer als het op commerciële linux aangaat nieuwe bestpractices en educatie. Dat is na de overname door IBM alleen maar groter geworden. We spreken over een waarde van in de biljoenen als het om Redhat gaat en in de miljoenen als we spreken over Canonical.

Neemt niet weg dat met tijd je beide even veilig kan maken als we enige bestaande bugs, exploits buiten beschouwing laten.

De rest is simpelweg gebruikerservaring, kennis en inschatting wat je organisatie nodig heeft in de toekomst. Moet je legacy hardware ondersteunen of bleeding edge? Moet er een juridsch bindende garantie worden opgesteld over schade gevallen door bepaalde factoren? Enzovoort.

nogmaals, daar is dus die SCAP based profile installatie methode dus voor:

https://www.open-scap.org/tools/oscap-anaconda-addon/

hoef je niet meer na te lopen meer bij elke installatie.

Onderschat niet wat dit voor een waarde heeft voor Enterprise en Security (management): Alles van moment 0 compliant geinstalleerd en eenvoudig achteraf regelmatig verifieren en rapporteren. Je kunt er zo een SIEM alert van maken als een machine bij de nachtelijke SCAP controle ineens niet meer compliant is. Meteen van het net afkoppelen is dan een eenvoudige actie die je als follow up u kunnen doen...

"Out of box kun je ze beter even *onveilig* beschouwen."

niet dus als je de RHEL installatie doet met een SCAP profile tijdens de installatie geinstalleerd. Je instalatie begin niet als die niet voldoet aan de policy regels. Na installatie (mist voldoen aan policy regels) wordt er ook een rapportage gedaan meteen. Dus als je RHEL out-of-the-box installeerd en je doet dat via een policy die je organistaie heeft, dan kun je daarna bij eerste boot je systeem wel als veilig beschouwen. Je moet wel een goede policy als organisatie dus hebben, of een std gebruiken:

https://www.open-scap.org/security-policies/choosing-policy/
https://www.open-scap.org/security-policies/scap-security-guide/
https://www.redhat.com/en/blog/configuring-and-applying-scap-policies-during-installation
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-security-policy-x86

Klopt, die nemen echt geen prutsers aan.

De ernstige fout waar het dan misgaat is: "je doet dat via een policy die je organistaie heef"
De policies van een organisties zijn niet technisch maar die gaan over het specifiek bedrijf.

Staat ook prima op de scap site: https://www.open-scap.org/security-policies/choosing-policy/
"Unfortunately, there is no universal security policy that could be applied everywhere; each organization has different needs and different security requirements. Before applying a security policy, it is necessary to think about your needs and go through the available offerings."
Je begint met een standaard vinkenlijst van scap. Toch raar dat die al anders dan de out of the box installatie.
Wat dan in ieder geval mist dat zijn de gereedschappen middleware en de bedrijfsinformatie met die verwerkingen.
Een keten is zo sterk als de zwakste schakel, je hebt nog maar 20% in beeld 80% te gaan.

Je leest het weer met gebruikelijke karma ogen only. Jij denkt aan een of andre ISO-nog-wat policy, het enige wat jij kent als a technische papieren tijger, maar in de context van SCAP hebben we het natuurlijk over een SCAP policy.

Ga de zaak maar eerst eens inhoudelijk bestuderen voordat je weer je gebruikelijke onzin gaat spuien:

http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-standard.html
http://static.open-scap.org/ssg-guides/ssg-rhel8-guide-ospp.html

En verder:

https://www.open-scap.org/security-policies/choosing-policy/

"Unfortunately, there is no universal security policy that could be applied everywhere; each organization has different needs and different security requirements. Before applying a security policy, it is necessary to think about your needs and go through the available offerings."

er is inderdaad geen one-size-fits-all, maar:

1) je kunt minstens al een std policy gaan gebruiken en kijk hoeveel jouw-invented-by-me setup afwijkt van best practises

2) je kunt nu al met die std policy systemen dagelijks via SIEM monitoren en laten rapporteren om bijvoorbeeld te controleren of een beheerder niet iets 'getweaked' heeft of de updates wel gedaan zijn etc. etc. etc.

3) je kunt de gekozen std policy als basis voor je eigen organisatie policy gaan gebruiken en er extra afdwingende eisen of mitigaties aan toe voegen, of indien nodig vanuit de buisness, iets minder streng doen

efin welkom in de 21e eeuw.

Gaat het om veiliger, of gaat het om support?
Met RHEL krijg je natuurlijk heel lang support als bedrijf.

Wat een discussie over een onduidelijke vraag eigenlijk.

Herhaling: -> De policies van een organisaties zijn niet technisch maar die gaan over het specifiek bedrijf.
De iso27k serie en NEN 7510 zijn beiden ook niet technisch, de tactische invulling gaat nog het verst.
Ze geven houvast aan wat aan technische invullingen via een uitgewerkte bedrijfspolicy bereikt zou moeten worden.

Wat je toont is het gedrag van een techneut zoals een automonteur die een "veilige band" monteert en daarna niets heeft met het houden aan verkeersregels dan wel waarheen iemand veilig vervoerd wil worden (taxi). Die beperkte visie "mijn gemonteerde band is veilig" niet verder denken, dat werkt de verkeersonveiligheid in de hand.
Zet hem door naar informatieverwerking, roepen dat je een "veilige machine" hebt, dat werkt de informatieonveiligheid in de hand. Verkeerd gebruik met een veilige machine geeft slechtere resultaten dan verantwoord gebruikt met een minder veilige machine. Er valt nog het nodige te verbeteren merk ik.

@karma:

Te lezen op http://static.open-scap.org/ssg-guides/ssg-rhel8-guide-ospp.html:

"Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance."

Waarom reageer je eigenlijk? Je hebt de ballen verstand van Linux, dus jij hoort helemaal niet mee te discussiëren. Het is weer het gebruikelijke vinger wijzen en laf lopen afgeven op iets waar je totaal geen kaas van hebt gegeten. Als jij weet hoe het moet, laat het maar zien! Ik blijf het herhalen.

Kritiek afgeven op iets waaraan je actief mee kan ontwikkelen, maar het alleen maar bij oeverloos vinger wijzen blijft, daar kom je niet mee weg. Laat jij de wereld maar even zien hoe je een veilig systeem bouwt. Want jij weet het altijd beter dan die honderdduizenden ontwikkelaars. Put your money where your mouth is. Or else: button your lip!

Als je nu gezegd had welk systeem veiliger is kan je niet zomaar beantwoorden. Het ligt er aan wat je er mee gaat doen.

Meer dan je denkt. Helaas. Ze lijken ook niks met onze veiligheid te hebben.

Dat techneuten een apart slag mensen zijn klopt, en dat menig project echt wel de inbreng van meer dan één ander slag mensen kan gebruiken om werkelijk wat goeds op te leveren ook. Maar bedenk ook dat zonder die techneuten het hele vakgebied waar deze website over gaat niet had bestaan. Informatietechnologie bestaat niet zonder techneuten die de technische kanten ervan aankunnen, en de beveiliging ervan ook niet.

Je hebt zelf laatst nog duidelijk gedemonstreerd dat je geen idee hebt wat een algoritme is, waarmee duidelijk is dat je al die besturingssystemen en andere software die beheerd en beveiligd moeten worden onmogelijk zelf had kunnen realiseren. Je bent duidelijk geen techneut. Maar je doet alsof je techneuten de les kan lezen alsof je hun kennis ook wel beheerst, terwijl je regelmatig door de mand valt. Da's behoorlijk arrogant van je, karma4.

Een antwoord:
- RedHat (nu IBM) wordt veel met server oplossingen gebruikt.
De werkelijke informatieveiligheid komt echt aan bod als de "applicaties" er op gezet worden.
Laat je de serviceprovider ongecontroleerd alles met alle rechten toe dan heb je een open voordeur.
- Ubuntu heeft een probleem met servers https://ubuntu.com/blog/migrating-to-enterprise-servers-with-ubuntu-on-ibm-z
Het verkoopverhaal bevat een aantal contradicties.

Meerdere partijen in een ondersteuning zal makkelijk neerkomen in het wijzen naar elkaar zonder echte oplossing.
Zet daar de open source zoekmachines als Mongo Elastic en het open benaderen van buckets en je hebt de notoir onveilige situatie met de grootste datalekken. Het hangt er inderdaad van af wat je er mee gaat doen, dan moet je daar de nadruk op leggen en niet op een doosje neerzetten..

Service providers zetten niet alles er ongecontroleerd op. Wat je krijgt is meestal iets meer dan het minimum. Ongeveer 1G en dan is het centos of fedora. Redhat werkt met subscriptions en wordt niet door huis tuin en keuken providers aangeboden.

De verschillen in veiligheid en robuustheid tussen Linux versies zijn gerommel in de marge. Ze steken allemaal met kop en schouders boven de concurrende besturingssystemen uit.

Zien we intussen aan alle IOT en Cloud serverr problematiek. Nu gaat het weer met Zoom mis en het onderliggende OS zou alles oplossen? Rare insteek.


Serviceproviders zoals IBM (den aan Watson Blockchain) , Oracle Sap al dan niet via tussenstations leveren complete applicances die zij naar hun inzichten neerzetten en de verwerkingen van hun afnemers naar hun inzichten als externe leverancier. Dat is de situatie. Dan ga je als verwerker wat scrummen in een Safe 5.0 setting en je roept dat je aan continous deployment met de modernste technieken doet. Komt het op die manier bekend voor?

Wat ontbreekt er? informatieveiligheid inclusief de aandacht voor privacy by design.
Nee dat roepen dat je zoiets zou moeten doen vanuit een ivoren toren van een universiteit helpt niet echt.
Zodra er meerdere partijen betrokken raken en je met BI Big data aan de slag gaat dan gaat dat helemaal wringen.

Redhat en Ubuntu zijn distributies (geen single OS-en), i.e. een Linux kernel (het OS) met daarbij een rits aan (aanverwante) applicaties.

Er is wel degelijk verschil tussen de kernels van deze distributies, alsook de device-management ondersteuning. Denk eens aan bijvoorbeeld systemd. Ubuntu liep ver voor op RedHat.

Kop en schouders boven de concurrerende besturingssystemen uit? Debian is bijv. rete-stabiel; ideaal voor server doeleinde; en gemakkelijk je eigen kernel te integreren (via kernel.org). Maar dat is afhankelijk wat je doel is van de software.

Je hebt gelijk, ik drukte me onnauwkeurig en verwarrend uit. Er had beter Linux distributies kunnen staan.


Ik wilde het Windows woord niet gebruiken maar daaraan refereerde ik toen ik concurrerende besturingssystemen noemde.

systemd? je bedoeld de systemsuite origineel bedacht door Lennart Poettering tijdens de tijd dat hij voor RedHat werkte met steun van Redhat engineers en vele andere developers en waarvoor Fedora het testbed systeem van Redhat het voor het eerst geïntegreerd in werd?

Waar later na al dan niet verhitte discussies zoals werk vaker gaat ze binnen het Debian team het eens werden het te integreren en het daarna Mark Shuttleworth dacht hey handig dat is ook iets voor Ubuntu! Die systemd bedoel je?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708

Debian is een geweldig stabiele distributie en ik zal die altijd boven Ubuntu kiezen tenzij ze echt iets heel erg verknallen (wat ik niet zie gebeuren). Maar Debian is niet het end all er zijn zoveel smaken op de markt het gaat erom wat je persoonlijk of je organisatie nodig hebt en wat je klanten nodig hebben.

Kun je een favoriet hebben uiteraard maar het is en blijft een middel om iets te bereiken niets meer.
Waar het ene jaar eentje positiever in de community staat kan het volgende jaar zo weer veranderen. Wil niet zeggen dat je meteen over gaat schakelen natuurlijk ligt aan welke service je biedt maar grote kans dat jij niet bepaald wat het beste is dat laten je klanten wel weten.

Bedoel kijk naar UNIX Solaris was de end all in de oudere dagen toen kocht Oracle het werd de opensource project stopgezet wegens kosten, minder interesse en nu is het zeer zelden dat je er nog over hoort tenzij je te maken hebt met de hele grote gespecialiseerde bedrijven. Dat kan Redhat gebeuren dat kan Debian ook gebeuren. Hell het kan zelfs Linux gebeuren als er iets beters op de markt komt.

Maar is dat erg? Enkel als je geen innovatie wilt blijven zien volgens mij.

Gaan we weer. Het slappe aftreksel van Unix wat Torvald nabouwde wegens de licenties van AT&T kon niet tippen aan VMS wat als basis diende voor NT, de ondergang van OS/2 en het kon niet tippen aan MVS (het latere z/OS).
Het moest allemaal goedkoper, liefst gratis en voor niets daarmee ging de kwaliteit van security overboord.
Linux, het engie OS dat geen centraal gestandaardiseerd securitybeheer kent. Het moet met plak en pleisterwerk in applicateis opgelost worden.

Je maakt een grote denkfout.
Het is niet DE Linux, maar EEN Linux, waarmee we distributies bedoelen.
Iedere Linux distributie is anders, er bestaat dus niet iets als centraal gestandaardiseerd, want dat gaat per distributie.
Daarnaast is Ubuntu gebaseerd op Debian, waarbij de thuisgebruikers de testers zijn voor de professionele ondersteuning door, of namens Canonical.

Vergeet ook niet, dat wanneer we alles waar een besturingssysteem op werkt bekijken (inclusief Chromium en Android), dat Linux veruit in de meerderheid zit, en dat is niet voor de kosten, maar veelal voor de veiligheid en aanpasbaarheid.
Helaas zit er veel kaf onder het koren bij de goedkope dingen.........

Tot slot: Lees je eigen berichten na voordat je ze plaatst, dat komt de leesbaarheid alleen maar ten goede.

Karma4 kent maar één betekenis van het woord policy.
Karma4 reageert alsof ieder gebruik van het woord policy slaat op de context/betekenis waarin hij het kent.
Karma4 doet alsof hij ook wat weet van technische invullingen van policies in de betekenis die hij kent.


Opmerkelijk dat je in deze analogie bijna lijkt te begrijpen dat een woord als 'veiligheid' ook een veelvoud aan betekenissen kan hebben.
Er bestaan meer en minder veilige auto's letterlijk - en historisch zijn auto's _veiliger_ geworden.
Hoofdsteunen, gordels, kreukelzones, airbags (front, passenger, side ), ABS, brake assist en nog veel meer driver assists.
Daarnaast ook veiliger voor de 'gebotsten' - afgeronde ,'opscheppende' motorkappen in plaats van platte met bullbar .

Veiliger wegen - niet iedere weg is even (on)veilig. Dat hangt meer deels af van andere weggebruikers , ook de inrichting van de weg telt mee. Rotonde vs kruising .

En dan ook verkeerswetgeving en feitelijke handhaving - ook gericht op 'veiligheid' .

Inderdaad kan de (auto)techniek en infrastructuur een bestuurder niet tegen alles beschermen - maar wel degelijk verschil maken waar eenzelfde kwaliteit bestuurder wel of niet levend uitstapt.


Opmerkelijk genoeg slaag jij er altijd in, om in deze analogie , alleen maar de verkeerswet te zien en alles aan voertuigen en infrastructuur als gelijkwaardig en inwisselbaar te beschouwen.
En zo af en toe de groots mogelijke onzin over auto's te debiteren.
Max Verstappen kan mij er gegarandeerd uitrijden , zelfs als hij een Civic rijdt en ik een Porsche. Dat maakt het nog geen gelijkwaardige auto's.

N.B.: ik draai zelf (alleen maar) Debian!

Waarom niet Devuan? Of GuixOS?

Ik heb eigenlijk weinig problemen met systemd. GuixOS kende ik geloof ik niet. Lijkt nogal esoterisch? Update: maar wel interessant; ontbreken wel wat packages. Distributies met kleinere onderhoudsteams vind ik sowieso risicovol.

" Nu gaat het weer met Zoom mis en het onderliggende OS zou alles oplossen? "

Kun je even de bron / referentie melden? Ik heb namelijk sterk het vermoeden dat deze uitlating FUD is.

Het probleem van systemd is wanneer het eindigt, of beter gezegd waarmee het eindigt. GuixOS blijf ik interessant vinden maar eigenlijk vind ik dat alles static compiled zou moeten zijn. Dat scheelt een hele boel onzin in de systemen.

Lees even mijn bewering na:
- Linux het enige OS dat geen centrale security kent, alles is plak en pleisterwerk achteraf in applicaties.
Je kent vast wel de reacties van de Linux fanatici dat het aan PHP het brakke internet of waar dan ook aan ligt. Het is een signaal dat ze op dat moment iets fundamenteels mist in het OS Linux.... namelijk security informatieveiligheid voor een ander.

Het argument dat het het meest gebruikt is en daarom wel goed moet zijn is een foute veronderstelling.
Ooit was video2000 veel beter gekwalificeerd dan VHS. Denk wat verder na, vhs won de markt maar verloor daarna alles.

Ik weet niet of je buiten radiotechniek ook met meer OS systemen gewerkt hebt.
Verdiep je eens in SAF calls pre-emptive request SVC calls met een hardware key protection. Dan verbaas je je als veel van dat mist in een ander OS. Je bent al blij dat er iets centraal beheer is als een AD. Dan kom je in een volgende en je vind zelfs daarvan helemaal niets meer terug.

Dan heb je doosje die worden neergezet maar waar je voor de applicaties op die manier in het geheel niets aan hebt.
Kijk je wat verdere dan zitten er her en der in wat aparte kamertje wat grote ego's die tegenstrijdigheden zitten te verkondigen. De beslissers, het management zie je het zat worden en alles buiten de deur en in de cloud zien te krijgen.
Dan kun je niet meer verbaasd zijn dat met de chaos er zoveel misgaat met informatieveiligheid. Alles Agile lost het wel op.


,

Maar dat zou toch (te) veel bandbreedte bij updates geven? Want als een low-level library - die normaliter dynamisch gelinkt zou worden - geüpdatet wordt dan moeten alle afhankelijke libraries en executables die deze library statisch meegelinkt hebben worden vervangen. Dat doet me denken aan openSUSE Tumbleweed, een rolling release distributie die bij wijzigingen alle afhankelijke pakketten opnieuw bouwt en verspreidt als update. Op zich mooi spul maar je krijgt zomaar een gigabyte aan update download voor je kiezen.

Linux distributies hebben juist een centrale repository voor hun software zodat alles uit één bron komt. En de teams achter de distributie houden zich specifiek met veiligheid bezig [1] en updaten software in de centrale repository bij problemen (indien nodig zelfs voordat de onderhouders van pakketten daarmee aan de slag gaan). Een snel en goed werkend updatemechanisme doet de rest. Intrinsiek veel veiliger dan bv. Windows, waar software overal en nergens vandaan komt en je afhankelijk bent van een traag, slecht werkend, brak en rebootend updatemechnisme. En vendor lock-in.

Kortom: je weet weer eens niet waar je het over hebt. Dat begint een rode draad te worden in jouw bijdragen hier.

[1] bijvoorbeeld: https://www.debian.org/security/ en https://www.debian.org/security/faq

Dat is ook de reden waarom ik prefereer voor source code updates, als dat er een keer zou mogen komen. Dat in combinatie met een programmeertaal die snel compiled (dus niet C++ of Rust), maar liever ook geen C want C is de source van veel shit. Het probleem is dat het manuele geheugenmanagement van C voor velen gewoon te lastig is. Maar goed, dat is dus wachten op de toekomst... (http://vlang.io misschien)

Een tijdje geleden deze gepost:

https://www.security.nl/posting/648373/RH+security+rapportage

Nu extra interresant eens te bekijken.

Gezien dit topic en de oefenloze discussies hierboven, graag wat inhoud weer aan het geheel.

o.a. Gentoo Linux doet dat al jaren. Maar die compilatietijden gaan je inderdaad - hieronder - op een gegeven moment de neus uitkomen. Met name updates aan grote lappen code, zoals KDE, LibreOffice, zijn frustrerend.


Interessant, die kende ik nog niet. Maar heeft die een (betere) oplossing voor het geheugenmanagement?

"Je bent al blij dat er iets centraal beheer is als een AD. Dan kom je in een volgende en je vind zelfs daarvan helemaal niets meer terug."

https://access.redhat.com/products/red-hat-directory-server
www.freeipa.org
...
...
...

Je moet je wel realiseren dat een AD niet meer is dan een GUI is om DNS, LDAP, Kerberos etc. heen:

https://en.wikipedia.org/wiki/Active_Directory

Je kunt dus ook met Linux een AD gebruiken als je dat zou willen:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/sssd

Dus:

" Linux het enige OS dat geen centrale security kent, alles is plak en pleisterwerk achteraf in applicaties."

Ik zie graag een bron of referentie bij deze stelling. Het lijkt mij te sterk op FUD.

Heb ik gedaan, maar er staat veel onzin in, het bewijst alleen dat je mijn bericht niet begrepen hebt.Je hebt het inderdaad niet begrepen, en niet goed gelezen.
Sinds CP/M 2.2 heb ik alles gebruikt waar ik gratis aan kon komen.
Waaronder ook de beroemde Microsoft producten tot W98se, dat door een programmeer en ontwerpfout niet in staat bleek om één week aan te staan en dat niet meer aan kon dan 512MB geheugen.
(Dit is wel netjes opgelost, ik kreeg een XP licentie gratis)
Dat heb ik 2 jaar gebruikt, maar ik kon niet leven met de tekortkomingen.
Ook heb ik Vista, 7,8 en 10 bekeken, maar ik stoot steeds mijn hoofd :-)
Gelukkig ben ik nu van dit soort monopoly verlost.

All die red hat prut zit vol met spyware (bv. tracker en selinux) wat moet je er mee.
Ik hou er niet van om getracked te worden met activiteiten dus voor mij hoeft die
troep niet.

Tja hoe veilig je je systeem wilt hebben ligt verder aan je zelf,je kan het nog beter beveiligen met allemaal extra barricades aan software,of met de matrialen die je al aan boord hebt met je distributie.
Of je kan het via de command line instellen,of je kan het in de grafische schil nog wat aanscherpen.

Sorry, dat URL was fout en ik heb het al opgelost in mijn tekst. Het juiste URL is https://vlang.io/. V claimt redelijk wat en ik weet eerlijk gezegd niet wat ik ervan moet geloven maar *als* het allemaal klopt dan is dat een serieuze C kandidaat. Kijk gewoon even op de faq zou ik zeggen.

Ok je zegt het al, "waar je gratis aan kon komen". Ik zat aan de kant waar het niet gratis was en men zich druk maakte om het zo goed mogelijke te doen. Veel voor elkaar gekregen met alle beperkte technologie (vergeleken met nu).
Dat gratis en voor niets en kostenbesparing is er met de jaren in geslopen. De kwaliteit ging er mee verloren.

Nee mainframes waren echt niet gratis, met de opkomst van de pc dacht men dat de ICT problemen opgelost waren.

Wat je mist: https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zsecurity/zsecc_030.htm.
SAF System authorization facility via systeemcalls gekoppeld met Supervisor calls is een volledig geïntegreerde aanpak. "The SAF router provides a common focal point for all products providing resource control. This focal point encourages the use of common control functions shared across products and across systems."

Kan een interessante link zijn daar echter die werkt niet .
https://www.redhat.com/cms/managed-files/rh-2019-risk-report-overview-f21332wg-202003-en_0.pdf

hier wel...

De orignele link (in het andere artikel) niet, maar deze nieuwe idd wel.

We gaan eens fact-checken:

https://en.wikipedia.org/wiki/ACF2

een " discretionary access control " : https://en.wikipedia.org/wiki/Discretionary_access_control

met als key point

"The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control)".

Vergelijk dat nu eens met " mandatory access control ": https://en.wikipedia.org/wiki/Mandatory_access_control

met als key point

"With mandatory access control, this security policy is centrally controlled by a security policy administrator; users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes. (The traditional Unix system of users, groups, and read-write-execute permissions is an example of DAC.) MAC-enabled systems allow policy administrators to implement organization-wide security policies. Under MAC (and unlike DAC), users cannot override or modify this policy, either accidentally or intentionally. This allows security administrators to define a central policy that is guaranteed (in principle) to be enforced for all users. "

RHEL 7 komt standaard met SELinux in targeted mode en implementeerd dus (naast die reguliere UNIX DAC) ook een role based MAC. Dat kon op die z/OS systemen destijds niet eens. De tijd is verder gegaan en nogmaals welkom in de 21e eeuw.

tracker is een gnome dingetje en kan disabled worden:

https://access.redhat.com/solutions/3364861
https://www.putorius.net/disable-tracker-on-fedora-29.html
https://www.linuxuprising.com/2019/07/how-to-completely-disable-tracker.html

en dit is de one liner die ik gebruik bij uitrollen:

"sudo sed -i 's/X-GNOME-Autostart-enabled=true/X-GNOME-Autostart-enabled=false/g' /etc/xdg/autostart/tracker-*.desktop"

Voor de mensen hierboven die dieper op de SELinux in RHEL 7 willen in gaan:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/index

En wat meer over IdM middels RHDS (FreeIPA based):

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/index

[Dus de gemaakte opmerkingen van ene karma hierboven moeten sterk gerelativeerd worden.]

Je factchecking mist de hele basis van wat SAF echt betekende. We hebben het begin jaren midden jaren 80.
Zowel ACF2 als RACF zijn interfaces voor de administratie in een centraal beheer. Dus niet het afschuiven dat je het "naar de applicatie" moet het maar oplossen. Het is andersom je verwacht dat een DBMS en andere applicatie dat al inbouwen.
Je hebt acf2 gekozen. Dat is: https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/security/ca-acf2-for-z-os/16-0/getting-started/components.html let even op het noemen van CICS (front-end schermen) en IMS (back end database). Wat je stelt is dat velden op web-interface en de data in het achterliggende DBMS met Selinux dan DAC opgelost zouden kunnen worden. Je mist de functionele invullingen en de verschillen in de techniek volledig. Centraal verplicht geregeld is makkelijk als je MAC wilt.

Wil je MAC in je functionele beveiliging dan zal je met DAC het eigenaarschap een rol moeten gaan toekennen met Selinux heb je wel subsysteemprocessen maar je kan niets met functionele beveiliging daarbinnen. Op zijn best krijg je "applicatiebeheerders" die alle security moeten invullen maar een centrale organisatie als strand snel in het onbegrip.

Geen wonder al die datalekken waarbij de functionele kant niet echt goed te krijgen is. En jammer dat de OS fanatici tegelijkertijd dat het goed mis gaat zitten te roepen dat alles zo perfect is in hun ogen.

Het Selinux gebeuren is op zijn best met de memory ring protectie te vergelijken dat werd zelfs hardwarematig ondersteund met scheiding in subsystemen. Dat gaat terug tot inde jaren 60, Dan nog is selinux veel te beperkt.
https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zsecurity/zsecc_066.htm Dat was bedoeld om systeemprocessen gescheiden te houden en die buiten het gebied van applicaties te beschermen. De S0c4 was berucht bij code foutjes.

in je referentie staat letterlijk

" ... RACF is an add-on software product that provides ... "

het is dus niet een onderdeel van de kernel of OS zelf.

De rest lees ik niet eens omdat je relaas wderom alweer start met een onjuiste bewering.

op https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zsecurity/zsecc_030.html staat:

"The system authorization facility (SAF) conditionally directs control to RACF (if RACF is present), or to a user-supplied processing routine, or both, when receiving a request from a resource manager."

RACF is een add-on (net als de ACF2) en dus niet std onderdeel van kernel / OS en is ook nog eens user supplied (we lezen op https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zsecurity/zsecc_042.htm):

"Resource Access Control Facility or RACF provides the tools to manage user access to critical resources. RACF is an add-on software product that provides basic security for a mainframe system (examples of other security software packages include ACF2 and Top Secret, both from Computer Associates).

RACF protects resources by granting access only to authorized users of the protected resources. RACF retains information about users, resources, and access authorities in special structures called profiles in its database, and it refers to these profiles when deciding which users should be permitted access to protected system resources."


onjuist; het is dus meer dan een admin tooltje en het is ook nog eens een add-on.

SAF valt dus (op dat user supplied dingetje na van RACF en AFC2) te vergelijken met LSM (https://en.wikipedia.org/wiki/Linux_Security_Modules) die het mogelijk maken SELinux of AppArmor in de kernel te laten 'haken'. verschil is dat die dan niet user supplied zijn maar vanuit het OS weer.

dus... al met al... na het fact-checken van enkele onzorgvuldigheden, wat was de originele stelling ook al weer waar het hele verhaal mee gestart was?



1) ik denk dat het iedereen wel weer duidelijk is dat die stelling dus onjuist is.
2) het is duidelijk dat je geen inhoudelijk idee hebt van wat er na de tijd is gebeurt.
3) je beargumenteering is op zijn zachtsgezegd vol onjuistheden.
4) maar veer ergelijker, je fixeerd je duidelijk op verouderde technologie van een specifiek OS. en we hebben hier allemaal een grondige hekel aan mensen die alleen maar met een OS bezig zijn en niet verder denken over security op een pseudo abstracte (lees vaag en bla bla bla en jouw geval) manier. toch? dat zijn van die vervelende OS evangelisten die hun dingetje staan te predikeren!

je vertoont daarmee het typische gedrag van een has-been-couldn't-keep-up-not-quite-intelligent-enough-so-i-will-use-buzz-words persoon.

Het veiligste OS is het OS wat je het beste kent om te beveiligen. Nu zijn sommigen makkelijker te beveiligen dan anderen. Maar als jouw beheerder Redhat kan dromen en nog nooit wat met Ubuntu heeft gedaan.. dan heeft ie wel gelijk.

Hoe grappig. Redhat 7. Ik ben mijn carrière ooit begonnen met Redhat 6. Maar dat kwam van 4 floppy's! En daar zaten nog 2 dikke boeken bij met install instructies en configuratie van je netwerkkaart/telefoonmodem. Want internet was nog maar net uitgevonden!

En dat was in de jaren 90! Wat is er met Redhat gebeurd dat ze nu bij 7 zijn?

Edit: Aha:

Red Hat Linux, created by the company Red Hat, was a widely used Linux distribution until its discontinuation in 2004.[1]

https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux

On October 28, 2018, IBM announced its intent to acquire Red Hat for $34 billion.[8][9][10] The acquisition closed on July 9, 2019.[11] Red Hat's lead financial adviser in the transaction was Guggenheim Securities.

https://en.wikipedia.org/wiki/Red_Hat

Dat is grappig. Volgens mij had ik die ook. Het probleem is echter dat er -- volgens mij -- te veel programmeurs zijn in deze wereld die allemaal denken zoals dit https://xkcd.com/927/ en de behoefte hebben om compatibel te willen zijn met alles, waardoor alles zo groot (en log/traag) wordt. Maar ze vergeten wel dat "onze wereld" is gebouwd op drijfzand. Vandaar ook de duizenden bugs die in de systemen ronddwalen.

Omdat hij heel veel tijd en moeite gestoken heeft in het leren omgaan met Redhat, en geen zin heeft hetzelfde voor Ubuntu te moeten doen?

Ik heb zelf geleerd dat je eigenlijk elk besturingssysteem goed veilig kan krijgen en houden mits je weet hoe Unices en Windows werken en weet hoe je standaard ea kan hardenen.

Met dingen zoals:

- patches
- least privileges
- host based firewall
- less is more (qua software)

Kan je een heel eind komen op elk OS.

OpenBSD doet al veel van dit soort dingen out of the box en merk dat Windows en ook Linux distro's dat ook steeds meer doen out of the box.

RedHat != RHEL ;)

Onjuist want als het besturingssysteem aan elkaar hangt van de spaghetticode dan kan je hardenen wat je wilt maar je zal kwetsbaarder blijven dan bij gebruik van een besturingssysteem met kwaliteit en inzichtelijkheid (open source; waarbij je kan zien wat er onder de motorkap allemaal gebeurt). En vendor lock-in.

OSS Linux is berucht om zijn gebrek aan cohesie ofwel een doelgerichte structuur. Ik geef je gelijk met de oorzaak van het gebrek aan security. Het is er niet voor bedoeld, gewoon snel geld verdienen met wat bij elkaar plakken is veel lucratiever. Bezos is een fraai voorbeeld met zijn verplichting om de niet goed betaalde werknemers als persoonlijk kapitaal te zien.

Bedoel je met OSS Linux het Open Sound System Linux? Er bestaan meerdere kernel drivers om geluid te produceren. Elk heeft zo zijn voordelen; de ene is (near) realtime, de andere is buffered streaming. Het is principieel niet mogelijk om realtime sound streaming te bereiken waarbij de hardware niet op lokatie is (remote).

Het is aan de gebruiker om te kiezen wat voor hen geschikt is. Ben je een 'normale' gebruiker van het OS, een zgn. consument, dan volstaat bijv. Ubuntu. Wil je serieuze server toepassingen doen, kies dan voor Debian. Maar voor elke systeembeheerder is het ene pakket een oplossingen en het ander pakket een probleem.

Help liever je collega of vriend met het bepalen van de keuze, dan een heilige oorlog te starten met heilige huisjes.

COTS is veel erger, geen zicht op bugs of backdoors vaak contracten met leveranciers uit moeten spitten om te kijken wat er nu in de support zit en wat niet. Iedere tussenschakel wil een graantje meepikken.

Waar kan ik als consument terecht als mijn Windows machine weer eens niet doet wat het zou moeten doen? Bij Microsoft hoef je in elk geval niet aan te kloppen.

Ondertussen brandt de wereld.

Onbegrijpelijk dat het off topic getrol van ene karma4 hier niet wordt verwijderd.

Klopt. Het probleem is de hoeveelheid informatie die de diensten moeten verwerken. De experts begrijpen dat dit onwerkbaar is, teveel false-positives. Echter, in die omgeving zitten veel domme techies die more-is-better denken. Maar dit werkt averechts. De experts worden weggekocht of weggepest en de dommen blijven over.

Net zoals hier in Nederland; ken je het begrip Overheid + ICT = drama ?

Waarom zou een informatie-specialist zich bijvoorbeeld bij de AIVD aansluiten? Er is grote geheimhouding, de resultaten die ze behalen zijn minimaal, en er worden rare spelletjes gespeeld. Beter is het om bij bijvoorbeeld een Google of Philips te gaan werken; daar verdien je 3x het salaris en de omgeving bestaat uit leuke mensen.