Linux Foundation gaat kernel-repository beveiligen met two-factor-authenticatie

De Linux Foundation gaat two-factor-authenticatie invoeren voor developers die toegang hebben tot de broncode van de Linux-kernel. Daarvoor wordt onder andere het zogeheten YubiKey-token ingezet. De maatregel volgt drie jaar na een inbraak op Kernel.org.

In september 2011 werd Kernel.org, de website waarop de broncode voor de Linux-kernel wordt geplaatst, gekraakt. Daarbij werden bestanden van OpenSSH gewijzigd en werd een trojan geïnstalleerd. De schoonmaakoperatie door de beheerders vergde veel tijd en er werd besloten om het beveiligingsniveau flink te verhogen.

Een eerste stap was het invoeren van ssh-sleutels in plaats van wachtwoorden, maar de Linux Foundation wilde nog een tweede beveiligingsslag slaan door het invoeren van two-factor-authenticatie voor developers die direct code committen voor de Linux-kernel in de git-repositories van Kernel.org. Daarvoor is onder andere gekozen voor de YubiKey, een hardwarematig token dat vergelijkbaar is met bijvoorbeeld de SecurID-key van RSA. De fabrikant van de YubiKey heeft honderd tokens gedoneerd aan de Linux Foundation. De implementatie van two-factor-authenticatie is inmiddels op stoom gekomen en wordt binnenkort verplicht, meldt ZDnet.

Kernel.org gebruikt ook softwarematige two-factor-authenticatie. Zowel de hardwarematige als de softwarematige beveiligingslaag is gebaseerd op open IETF-protocollen, zoals het one-time password algorithm en de totp-standaard. Om niet steeds wachtwoorden en codes in te hoeven voeren, kunnen kerneldevelopers hun ip-adres tot maximaal dertig dagen op een whitelist plaatsen.

Reacties (52)

"De fabrikant van de YubiKey heeft honderd tokens gedoneerd aan de Linux Foundation."

Strakke actie van de fabrikant dan

Maar goed dat ze de laatste en belangrijkste laag van de kernel ontwikkeling extra afschermen. Hoeveel developers hebben daar eigenlijk toegang tot? Paar tientallen?

Edit: Ongeloofelijk hoeveel mensen hieronder wel niet zitten te klagen dat ze dit gratis hebben aangeboden. Ja er zijn zat alternatieven, maar dat maakt deze actie helemaal niet slecht?

[Reactie gewijzigd door NightFox89 op 20 augustus 2014 16:54]

Hoezo strakke actie. Gewoon een goedkope high-profile reclame actie. Zie ook mijn post hieronder. Er hebben volgens mij een aantal mensen van de Linux Foundation goed zitten te slapen toen deze deal gemaakt is, en Linus was vast op een lange duikvakantie. Git heeft voorzieningen (signed commits, server-side hooks) waardoor eigenlijk single factor authenticatie al nauwlijks nodig is, laat staan 2-factor. Een hw token voor het lokaal signen van commits was heel mooi geweest natuurlijk, deze oplossing is echter gewoon te suf voor woorden en het is gewoon genant dat mensen die heel goed weten hoe git werkt (ze hebben het potdomme zelf geschreven) nu met zo'n suffe oplossing komen die gewoon negeert wat Git zelf al als voorzieningen heeft, en hoe git over het algemeen gebruikt wordt (eerst lokaal aan de hand van kleine aanpassingen een aantal commits doen terwijl je nog perfect weet wat je net gedaan hebt, om vervolgens op een gegeven moment een push te doen naar de server waarin wel dagen aan commits kan zitten) en daar op geen enkele manier op aansluit.

Voor de duidelijkheid, de oplossing die ze nu lijken te gaan invoeren gaat dus over 2-factor authenticatie op 'push', terwijl je eigenlijk authenticatie op een 'per commit' basis moet hebben.
Git voorziet daar dus in met signed commits. Je kunt server-side commits uit een push wijgeren door gebruik van server side hooks. Kun je eignlijk beteen de hele ssh-key en IP whitelist en token zooi in een keer allemaal gewoon laten zitten.

Functionaliteit die ze nodig hebben, en die veel fijnmaziger (en dus veiliger) kan werken dan wat ze nu gaan doen, zit dus allemaal al in het versie beheer systeem dat ze "ZELF GEMAAKT HEBBEN"!

Tokens als 2e factor? Leuk idee, maar gebruik dan een token waarmee je je private key op kunt zetten en waarmee je je commits kunt signen, een aantal jaar geleden warejn daar oplossingen voor, zullen vast nog wel te koop zijn ergens, en zo nee, mischien eens met de gasten van Trezor praten, als ze het voor een bitcoin wallet kunnen, dan moet het voor het signen van commits ook kunnen.

Inderdaad een mooi gebaar.

Maar toch, dit kan er wel voor zorgen dat nieuwe developpers er een afkeer van nemen net omdat het moeilijker wordt om te gaan bijdragen. In één keer wordt alles heel formeel en is er administratie die moet gedaan worden op te mogen bijdragen aan zo'n knap project. Het zit mij toch een beetje dwars met tov het idee van open source, al begrijp ik ook wel de reden waarom natuurlijk.

Overigens werken er een enkele honderden mee aan linux, ze sturen verbeteringen in die dan door een core groep van ontwikkelaars worden nageken enzo dacht ik.

Het wordt voor gewone mensen niet moeilijker om bij te dragen. Behalve een selecte groep had niemand rechten om rechtstreeks code aan Linux toe te voegen, dat zou een mooie bende worden.

Als jij een patch hebt zul je die nog steeds moeten laten goedkeuren en moet hij door een paar lagen review heen totdat uiteindelijk een van de selecte groep mensen met "schrijftoegang" het toevoegt. Deze authenticatie geldt alleen voor die selecte groep mensen, voor de rest verandert er niets.

Yes, maar het gaat nu toch over de core groep ontwikkelaars die zo'n sleutel nodig hebben? Je kunt als ontwikkelaar dan toch nog steeds gewoon pull requests doen?

Ja pull requests zeker, maar commits kan niet iedereen maken.

maar de Linux Foundation wilde nog een tweede beveiligingsslag slaan door het invoeren van two-factor-authenticatie voor developers die direct code committen voor de Linux-kernel in de git-repositories van Kernel.org.

"heel formeel" de echte kernel word nu zeer veilig opgeslagen, maar een kopie zal nog altijd vrij beschikbaar zijn lijkt mij?

Iedereen kan nog steeds de source code bekijken/downloaden. Alleen het wijzigen word dus streng beveiligd zodat een aantal dev's alle input kunnen nakijken en eventueel doorvoeren....Dit is altijd al zo geweest bij open source volgens mij .

Het punt hiervan is dan ook niet dat niemand meer naar de code mag kijken. De kernel is en blijft opensource.

Pas als je rechtstreeks code wilt toevoegen aan de kernel heb je een yubikey nodig.

Voor nieuwe developers moet je sowieso toch tich van lagen en is dit in principe niet relevant totdat je de relevante rechten verwerft... en betwijfel dat je dat snel lukt bij de linux kernel.

En het is ook enkel die kerngroep van oudgedienden die code mag sturen naar de repo van kernel.org, en het zijn dan ook enkel zij die gebruik gaan maken van deze 2-factor authentication. Voor mensen die dus willen beginnen met bijdragen aan de linux kernel veranderd er met andere woorden eigenlijk niets.

Het is niet alsof je als nieuwe developer nu zomaar kernel code kan comitten... op z'n best kan je op je eigen lokale repo patches ontwikkelen en als dat lekker werkt kan je die op de mailinglist publiceren voor het relevante onderdeel en als het dan geaccepteerd wordt gaat iemand anders het wel comitten.

Het is niet alsof de duizenden developers die iets aan de kernel bijdragen ook allemaal directe toegang tot de repo's van kernel.org hebben.

Daarnaast heb je dat ook niet perse nodig als je iets aan een kernel wil aanpassen. Je kan ook gewoon lokaal je eigen sources bewerken en opslaan, en het gewoon niet publiceren. Alles kan.

Strakke actie van de fabrikant dan

Veel goedkoper kun je als bedrijf geen reclame maken. Dit nieuws gaat gepost worden op alle zich zelf respecterende tech sites in de wereld en wordt door miljoenen mensen gelezen. Daar kun je wel een paar honderd/duizend dollar op stuk gooien.

OT: Goede zaak. De veiligheid van het halve internet valt en staat bij een betrouwbare Linux kernel.

Volgens mij was tot voor kort Linus Torvalds himself zelfs de enige die de main branche onderhield. Inmiddels zit hier een team op (geen idee hoe groot), maar dit is uiteraard een select gezelschap. Anders zou het een janboel worden.

Ik geloof dat de hiërarchie Linus Torvalds - Reviewers - Devs is.

"Strakke actie van de fabrikant dan"

Inderdaad erg aardig van ze maar het is meer een marketing/publiciteits actie...
Niks mis mee hoor, maar laten we het wel even in perspectief houden.

Een Ubikey kost zo'n 30/35 euro end-user prijs, productie kosten een factor 10 minder.
Dus 100 x 5 ofzo = 500 euri aan kosten.

Die dingen kosten een paar dollar om te produceren, nog niet eens waarschijnlijk. Ik wil daarbij geen afbreuk doen aan het gebaar, want het is zeker een mooi gebaar maar ik wil even duidelijk maken dat het geen RSA tokens van 500 euro per stuk zijn voordat mensen dit gaan denken.

Wat me verder verbaast is dat er pas sinds vorig jaar gebruik wordt gemaakt van SSH public key authenticatie. Dat is toch wel heel erg slecht dat dat toen pas is ingevoerd. Zo zie je maar dat programmeren en het opzetten van een goede veilige infrastructuur toch twee heel verschillende expertises zijn ook al hebben beiden er dagelijks mee te maken.

Die dingen kosten een paar dollar om te produceren, nog niet eens waarschijnlijk. Ik wil daarbij geen afbreuk doen aan het gebaar, want het is zeker een mooi gebaar maar ik wil even duidelijk maken dat het geen RSA tokens van 500 euro per stuk zijn voordat mensen dit gaan denken.

Dat doet niets af aan de veiligheid. Een voorbeeld van het tegendeel. Het doet ook niets af aan het mooie gebaar van de fabrikant (iets over een gegeven paard).

En het is goed dat de YubiKey best wel voordelig is. Dat maakt het gebruik een stuk toegankelijker.

[Reactie gewijzigd door The Zep Man op 20 augustus 2014 13:25]

IP op een whitelist, de NSA kan een ip adress niet rerouten.

Dan kunnen we misschien het privé IPv6 nemen, is toch per MAC adres verschillend en kan opgeslaan worden ter controle (met maximum van 3 verschillende adressen)?

Dan kunnen we misschien het privé IPv6 nemen, is toch per MAC adres verschillend en kan opgeslaan worden ter controle (met maximum van 3 verschillende adressen)?

In de meeste setups, en dat wordt ook aanbevolen, roteerd het IP adres wat je gebruikt automatisch. Dus jouw voorstel gaat denk ik niet echt lekker werken.

Op m'n Mac's bijvoorbeeld, heb ik 1 EUI64 IPv6 Adres, wat zeg maar z'n vaste adres is. (wordt opgebouwd op basis van prefix, en een verhakseling van 't mac adres). Vervolgens genereert ie daar met de loop van de tijd nog een lading dynamische adressen bij, die allemaal in diezelfde /64 prefix zitten, maar continue anders zijn.

bijvoorbeeld:
inet6 xxxx:xxxx:xxxx:xxxx:225:4bff:fea4:84e0 prefixlen 64 autoconf
inet6 xxxx:xxxx:xxxx:xxxx:6920:ee4b:b53e:9a31 prefixlen 64 autoconf temporary

de eerste is m'n 'statische' adres, die ik eventueel in DNS zou hangen als ik die machine vanaf internet zou willen kunnen bereiken. De tweede is volledig dynamisch, en dat is het adres wat een server waarmee ik connect ziet.

[Reactie gewijzigd door arjankoole op 20 augustus 2014 13:04]

IP whitelist adressen zijn makkelijk te omzeilen. Die kun je spoofen.

Daarvoor is de 2factor authenticatie. Met whitelisting hou je wel makkelijk bijvoorbeeld wat chinese hackers buiten de deur die weer afhaken als het iets te veel moeite kost

Elke systeembeheerder van een beetje router die niet goed heeft opgelet bij de BGP lessen kan dat (met alle gevolgen vandien) onbedoeld. De NSA zal het dus vast ook wel kunnen denk ik zo.

IP op een whitelist, de NSA kan een ip adress niet rerouten.

Niet eenvoudig, niet zonder dat het opvalt, en bovendien moeten ze dan ook nog de ontwikkelaar z'n public/private SSH keys hebben.

Bovendien worden ALLE commits in de smiezen gehouden, en kennen alle core devs elkaar, als er eentje dan 'rare' wijzigingen gaat lopen doen, gaan er vrij snel wat alarmen af.

En als je je echt zorgen maakt over de NSA, SELinux is van de NSA, en die zit al tijden in de kernel.

(en er was zelfs een hele tijd terug een exploit, waarmee je als non-privileged user root kon worden via een bug in SELinux.)

Als een geheime dienst een dev gaat dwingen om iets in te bouwen dan zal dat vast niet iets zijn wat opvalt. Iets wat verklaart kan worden als een simpele verschrijving. En gedurende een jaar of langer worden er een aantal van dat soort aanpassingen doorgevoerd die tesamen het (on)gewenste effect hebben.

Opzich heel tof en een flinke barriere voor kwaadwillenden. Maar, waar een wil is, is een weg. Doet me denken aan de cryptonerds: http://xkcd.com/538

Alleen dient deze crypto niet om informatie te verbergen zoals in die xkcd, maar wel om te voorkomen dat er malafide figuren in slagen om aanpassingen te doen aan de data.

Uiteraard, ik doelde meer op het overkoepelende thema dat mensen van vlees en bloed altijd nog gechanteerd, omgekocht, gemanipuleerd, gedwongen e.d. kunnen worden.

Ja, maar dat gaat dus alleen maar werken als dat met ALLE developers tegelijk gebeurt. En dan moet je ook zorgen dat ALLE gebruikers hun sources niet controleren.

Het is niet alsof je met 1 foute dev de sources van kernel.org kan contamineren.

Nog steeds blijft de mens een kwetsbaar punt voor diezelfde malafide figuren en het punt van XKCD staan, alleen nog luguberder.

Als een kwaadwillende nu een malafide commit wil doen en het is technisch allemaal te afgetikt, dan kan hij met een wapen en het adres van iemand met toegang een heel eind komen.

Een beetje hetzelfde principe als dat sinds banken allemaal tijdsloten op de kluizen hebbem, het mode is geworden om bankmedewerkers en/of hun familie te gijzelen. (voorbeeld)

Niet dat ik verwacht dat mensen tot zulke lengte zullen willen gaan voor een kwaadaardige commit op de linuxkernel, simpelweg dat het stripje wel degelijk relevant is.

[Reactie gewijzigd door Keypunchie op 20 augustus 2014 11:40]

Als het doel is dat er geen commits gebeuren zonder dat de developer het zelf weet, OK, dan werkt dit (whitelisting even buiten beschouwing latend). Maar vermoedelijk willen ze toch eerder dat de inhoud van die commits 100% juist is en dat kan je nog altijd niet garanderen op deze manier: als het systeem van de developer is overgenomen, kan je niet vertrouwen wat je diff tool je vertelt, en kan er dus nog altijd verkeerde code binnenkomen...

Dat klopt, maar dit zijn enkel het handvol core committers van het Linux kernel. Toch wel mensen die aangetoond hebben kritisch naar de code te kijken. Als je als developer code opgenomen wilt hebben in het kernel dan moet dit door enkele lagen van reviews heen voordat het door deze mensen gemerged wordt.

Kans op een gekraakt systeem is altijd aanwezig, maar ik zie niet hoe men dit verder makkelijk kan reduceren. Daarnaast staan hun commits dan in versiebeheer, met hun naam. Zodra er signalen zijn dat de commits van een committer niet te vertrouwen zijn dan is terugdraaien mogelijk.

Vergeet daarbij niet dat het allerminst zeker is dat jouw distributie ook een veilige kernel bevat. Aan de kernel van bijv. de Raspberry Pi (Brits*), Cubox-I en de Hummingboard (Israelisch*), BananaPi (Chinees*) werken allemaal ontwikkelaars onafhankelijk van kernel ontwikkelaars van de basis linux kernel. Deze stap biedt dus alleen maar zekerheid voor de broncode op kernel.org. Dat je met bekende distributies zoals Ubuntu, Debian, e.d. een veilige kernel hebt op een van deze platforms is dus maar de vraag. Zo worden er op de genoemde platforms kernel patches gebruikt die nog niet goedgekeurd zijn door de basis kernel ontwikkelaars, maar hun nut in de praktijk wel hebben bewezen. Of daarmee ook backdoors zijn binnengehaald?

*Niet om een politieke discussie te starten, maar het men begrijpt denk ik wel wat ik bedoel.

Idd, het aantal mensen dat zelf zijn eigen kernels van kernel.org heeft compiled is minuscuul tov de honderden miljoenen mensen die simpelweg vertrouwen dat de Android telefoon of Synology NAS met de juiste kernel sources is gebouwd.

De meeste mensen vertrouwen echter dat het Debian review en management systeem net zo goed is als dat van Kernel.org en dat zolang de GPG handtekeningen maar kloppen er niet met je software gerommeld is.

[... ] de honderden miljoenen mensen die simpelweg vertrouwen dat de Android telefoon of Synology NAS met de juiste kernel sources is gebouwd.

Dat is dan toch ook de kern van de zaak. Kernel.org heeft verregaande beveiligingsmaatregelen, maar hoe zit dat met die van andere kernel clones. Die ontwikkelaars voeren meestal ook weer hun eigen patches door. Dan moet je vervolgens weer op hun professionaliteit en neutraliteit vertrouwen. Wie gaat nu stap voor stap een diff doen op de hele kernel. Vrijwel niemand.

Op die manier kan het ondanks deze maatregelen toch gebeuren dat er een backdoor in je router zit die bepaalde poorten openzet voor een bepaald IP adres.

Dat zegt overigens niks over de goede zet van kernel.org. Echter blijft het met de vele clones in linux land toch ook een stukje schijnveiligheid.

Ach ja, je moet overal wel iemands beveiliging vertrouwen. Het slot in je auto, op je voordeur, de kluis van de bank. Je kan wel je eigen blokhut in de bergen gaan bouwen en de hele dag aardappels verbouwen, maar "where's the fun in that?".

[Reactie gewijzigd door Dreamvoid op 20 augustus 2014 13:40]

Daarom zeg ik. De ketting is zo sterk als de zwakste schakel. Ook als het gaat om de linux kernel die je dagelijks gebruikt

Je kan bij sommige distro's prima herleiden hoe bijv. je kernel tot stand komt.
Bij Debian bijvoorbeeld door dat de sources van de kernel en de Debian patches gescheiden zijn, en pas bij het compileren samengevoegd worden. Dan kan je dus een diff doen tussen de kernel sources voor je Debian installatie en de versie van kernel.org en dan weet je of je sources kloppen, daarna kan je de Debian patches controleren en daarna de boel compileren en installeren.

De meeste mensen vertrouwen echter dat het Debian review en management systeem net zo goed is als dat van Kernel.org en dat zolang de GPG handtekeningen maar kloppen er niet met je software gerommeld is.

Ik zou vooral niet al te veel vertouwen op de kwaliteit van bestaande oplossingen zoals Debian. Daar zien we bij XBian (en vertrouw ook niet teveel onze kwaliteit ) toch regelmatig rare dingen voorbij komen als het gaat om upstart/systemd compatibiliteit, rare deb dependencies, heringevoerde kernel bugs o.a. in BTRFS enz. Ik wil niet teveel in detail treden, maar het punt is denk ik gemaakt i.c.m. mijn post hieronder.

Ik doelde ook niet perse op integratie-niveau betrouwbaarheid, maar integere sources en packages.

Ik ben bekend met de YubiKey-tokens en dit werkt prima.
Goede stap naar de toekomst toe om misbruik te voorkomen.
Wat ik me afvraag is waarom er niet naar andere opties wordt gekeken waarbij niet noodzakelijk een fysiek token nodig is, zoals bv. de Google Authenticator. Lijkt mij dat ze hier kosten mee kunnen besparen.
Aan de andere kant kan je je ook afvragen hoe veilig de Google Authenticator is ...

edit:

Ik moet toch echt beter lezen voordat ik reageer ...

[Reactie gewijzigd door ddkiller0900 op 20 augustus 2014 11:14]

Het protocol dat Google Authenticator gebruikt is open en verder onafhankelijk van google zelf. Anderen kunnen dit protocol implementeren zonder ook maar iets met google van doen te hebben.

En in het artikel wordt dit protocol al genoemd (totp), dus het wordt ook al gebruikt.

de protocol heeft niks met Google Authenticator te maken en overal waar de naam van google staat heeft google IETS te maken kijk na whatsapp... als je t niet wist zou je niet eens denken dat die van facebook is toch?

Google Authenticator is een app die dit protocol (rfc6238) implementeert. Die app is van google inderdaad. Maar iemand anders die totp implementeert kan dit doen zonder maar ook iets van Google af te hangen.

Andere gebruikers Google Authenticator dan kunnen gebruiken om die tokens te verschaffen, maar ze kunnen net zo goed elke andere app of hardware gebruiken om die tokens te verschaffen.

Dat klopt, Microsoft Authenticator werkt er ook mee.
Erg handig gezien ze vaak gebruiken worden voor 2 factor authentication. Nu heb je gewoon een lijstje met codes, en kun je de juiste eruit vissen in plaats van een stapel USB keys. Tevens ook makkelijker te vervangen indien het een keertje onderuit gaat en niet meer veilig is.

Er staat in de tekst: Kernel.org gebruikt ook softwarematige two-factor-authenticatie.

Ik dacht dat git signed-commits had voor deze ongein. Zie dan ook niet in wat 2-factor authenticatie hierin moet betekenen. Git + Pgp -> signed commits, probleem opgelost en geen enkele authenticatie nogig verder. Nieuwe commit zonder signature of van onbekende signer, Git heeft ook nog eens server-side hooks die daar naar kunnen kijken en de commit kunnen tegengaan.
Linus heeft potdomme Git zelf ontwikkeld, dus als de Linux Foundation en Linus mischien even met elkaar gepraat hadden ofzo, dan was deze ongein (die meer een reclamestunt van YubiKey lijkt) volgens mij niet nodig geweest. Maarja, het is vakantie tijd, Linus is zeker een maandje aan het duiken op de Seychellen ofzo ;-)

Ok ik heb het enorm mis, zou ook kunnen natuurlijk, als dat zo is, kan iemand mij dan uitleggen waar bovenstaande gedachte scheef gaat?

Je vergeet toegang tot de systemen van de ontwikkelaars , als ze gehackt worden kunnen dingen gesigned gecommit worden zonder dat ze er weet van hebben. Met deze sleutel is altijd een fysieke actie nodig (en kan dus niet op afstand geactiveerd worden)
Edit: Kan er echter misschien nog altijd op bestaande commits meegelift worden

[Reactie gewijzigd door Anoniem: 28333 op 20 augustus 2014 21:49]

Strakke aktie!

Zelf heb ik ook een Yubikey voor verschillende zaken. Works like a charm...

Tevens zie je ze steeds vaker... kijk naar mailbox.org. deze bieden het op hun maildienst aan.

Een beetje vaag de titel maar weer. Nu lijkt het of het in de broncode zelf wordt geplaatst . Maar dus alleen op de servers waar de broncode staat dus.