Makkelijk aanmelden bij Linux

Linux ondersteunt makkelijke aanmeldmethoden zoals gezichtsherkenning. In het c't-project ‘Hallo Linux’ beschrijven we hoe je dat goed en vooral veilig instelt.

Een beetje geïrriteerd keek ik naar mijn collega's. Terwijl zij zich met een grijns op hun gezicht aanmeldden met Windows Hello, typte ik voor Linux mijn superveilige en natuurlijk ellenlange en eigenlijk nauwelijks te onthouden wachtwoord in. Dat moest in Linux toch ook handiger kunnen?!

En dat blijkt ook te kunnen: ook al zit de oplossing nog niet in de standaardtools van een typische Linux-distributie, de basis voor een makkelijke maar toch veilige aanmelding zit al in het systeem verwerkt. Je hoeft alleen maar de interne koppelingen even te regelen.

Zo begon onze reis naar het binnenste van een modern Linux-systeem, in dit geval Ubuntu Desktop 18.04 LTS. Dat kostte de nodige tijd en moeite, maar uiteindelijk hadden we toch het gewenste resultaat

bereikt: een Linux-pc die met de nieuwste techniek is beveiligd en toch makkelijk te gebruiken is. Lees verder als je je wilt onderdompelen in de wereld van gezichtsherkenning, Pluggable Authentication Modules (PAM) en de Gnome-desktop. Daar heb je trouwens ook wat aan als je een andere Linux-distributie dan Ubuntu gebruikt zoals Fedora. De concepten zijn namelijk vergelijkbaar.

We gaan in dit artikel en het volgende artikel in op concrete voorbeelden voor een configuratie. Daarnaast gaan we ook in op de veiligheidsoverwegingen en hoe je tot de juiste combinatie komt van beveiliging en gebruiksgemak. Aan de hand daarvan kun je zelf voor een bepaalde oplossing kiezen om je Linuxpc te beveiligen. Die oplossing kan best afwijken van wat we hier aanraden. Uiteindelijk zul je zelf moeten bepalen hoeveel veiligheid je wilt inleveren voor meer gebruiksgemak.

Het is daarbij handig om wat te weten over de werking van PAM, hardware-tokens en de Gnomedesktop, zonder dat we daar in deze serie artikelen al te uitgebreid op ingaan. We concentreren ons hier even op wat relevant is voor dit project, maar als je eventueel meer achtergrondinformatie wilt, staan er

in de tekst en bij de links bij de artikelen genoeg aanknopingspunten.

COMFORTABEL AANMELDEN

Het doel is om de pc bij je afwezigheid (bijvoorbeeld bij de lange wandeling naar het toilet) veilig te vergrendelen. Dat kan op zich heel makkelijk.

Om het comfortabel te maken, moet die vergrendeling echter ook weer makkelijk opgeheven kunnen worden. Als je bij de zoveelste hittegolf netjes je twee liter water per dag drinkt gaat dat waarschijnlijk ook gepaard met wat meer toiletbezoeken. En dan tellen we de koffie nog niet eens mee. Je wilt dan niet elke keer dat je bij je pc terugkomt een 12-cijferig wachtwoord moeten intypen met speciale tekens en cijfers en zowel kleine als hoofdletters.

Iets met biometrie, zoals gezichtsherkenning, ligt dan voor de hand. Maar een systeem dat je collega's al om de tuin kunnen leiden met een geprinte foto is niet echt veilig. Daarom leek een tweefactorauthenticatie met gezichtsherkenning en een snel ingevoerde pincode een mooi en veiliger alternatief. Zoiets werd het ook, maar de uiteindelijke oplossing zag er anders uit dan verwacht.

De eerste aanmelding bij het systeem moest per se ongewijzigd blijven: het aanmelden bij het aanzetten van de pc of bij een herstart. Daarbij moet nog steeds naar het 12-cijferige wachtwoord gevraagd worden. Daaraan is namelijk onder meer de versleuteling van het opslagmedium gekoppeld. Dat zou je eventueel ook nog kunnen uitbreiden met 2-factorauthenticatie, maar dat is een vervolgproject. We willen nu eerst meer gebruiksgemak toevoegen zonder de beveiliging al te veel geweld aan te doen.

PAM: PLUGGABLE AUTHENTICATION

Als je iets wilt veranderen aan de aanmeldmechanismen van een Linux-systeem, stuit je waarschijnlijk al vrij snel op PAM. Die Pluggable Authentication Modules zijn een uitgekiende architectuur waarmee je in principe heel makkelijk een wachtwoordvraag kunt vervangen door bijvoorbeeld een vingerafdrukcontrole. Daarvoor hoeft aan de programma's niets gewijzigd te worden.

De PAM-configuratie gebeurt in de directory /etc/pam.d/. Daar slaan toepassingen als sudo en ssh al in hun eigen configuratiebestanden op hoe gebruikers hun bevoegdheid moeten aantonen voor de betreffende dienst. De basis wordt gevormd door bestanden waarvan de naam begint met common. Bij common-password gaat het om het wijzigen van het wachtwoord, common-sessie gaat over sessiebeheer en common-auth vormt de basis voor normale authenticatie. De meeste programma's maken gebruik van het common-bestand met @include common-auth en vullen dat naar behoefte aan met eigen richtlijnen voor auth, session en password. Aanpassingen aan de common- bestanden hebben dus potentieel invloed op alle programma's op het systeem en zou je bij het zelf knutselen eigenlijk moeten vermijden. In plaats daarvan kun je beter de configuratiebestanden van de afzonderlijke diensten aanpassen.

Het voor dit project relevante onderdeel is de authenticatie. Die vindt standaard plaats op basis van common-auth middels het invoeren van wachtwoorden. Maar zoals je op pagina 86 ziet zitten de entry’s van dat bestand ingewikkelder in elkaar dan je misschien zou verwachten.

De eerste regel beschrijft het doel, in dit geval de authenticatie. De tweede de relevantie voor het betreffende doel, hier bijvoorbeeld ‘required’. De derde regel geeft de gebruikte PAM-module aan, en alles wat daarna komt zijn de bijbehorende parameters. De namen van de modules eindigen altijd op .so, omdat het moet gaan om bibliotheken die elk programma kan benutten.

Die PAM-regels worden van boven naar beneden afgewerkt, behalve als een regel dat verloop rechtstreeks aanpast. Zo zorgt success=1 ervoor dat in geval van succes de volgende regel wordt overgeslagen. Pam.unix.so is de normale Unix-wachtwoordcontrole, de optie nullok_secure betekent dat ook lege wachtwoorden worden geaccepteerd – als de huidige terminal tenminste als veilig is gekenmerkt (zie /etc/securetty).

Als een gebruiker dus het juiste wachtwoord intypt bij de wachtwoordvraag die door pam_unix is gestart, springt PAM meteen een regel verder naar pam_permit.so op de derde regel. Daarmee wordt het systeem ontgrendeld. In alle andere gevallen wordt de tweede regel verwerkt en zorgt pam_deny ervoor dat de toegang geweigerd wordt. Dat ziet er misschien nodeloos ingewikkeld uit, maar maakt erg flexibele regels mogelijk zoals je verderop ziet.

De sleutelwoorden required en requisite geven aan dat de beide modules voor een geslaagde

De uiteindelijke oplossing zag er anders uit dan verwacht

voortgang – per se – met succes afgerond moeten worden. Bij required gaat PAM ook bij mislukken door naar de volgende regel, maar als de regel met requisite niet werkt, wordt PAM zonder meer gestopt. Modules met optional hebben geen invloed op het resultaat van de authenticatie. Ze zorgen er bijvoorbeeld voor dat een versleuteld station ook meteen wordt gemount met het opgegeven wachtwoord.

Bij de eerste PAM-experimenten kun je beter niet meteen beginnen met het aanmeldscherm, de screensaver of een vergrendelingsscherm. Als er iets verkeerd gaat, kom je dan namelijk zelf niet meer in het systeem. Het is beter om nieuwe mechanismen bijvoorbeeld met sudo te testen.

Dat kan bijvoorbeeld als volgt: open een nieuw terminalvenster en start met sudo -i een root-shell. Die moet je vervolgens niet sluiten totdat je klaar bent: op die manier zorg je er namelijk voor dat je wijzigingen eventueel ongedaan kunt maken als er iets verkeerd gaat.

Maak daarna van elk bestand dat je wilt wijzigen eerst een back-up: cd /etc/pam.d cp sudo sudo-org

Dan kun je bijvoorbeeld proberen de wachtwoordvraag uit te schakelen. Dat kan eenvoudig: zet in het bestand sudo voor de regel met common-auth een hekje om er commentaar van te maken en voeg daaronder een wel erg ruimhartige regel toe:

# @include common-auth auth required pam_permit.so

Het is trouwens handig om dat met vi te doen, omdat de syntaxis-highlighting daarvan meteen aangeeft of je wel een geldige regel hebt gemaakt. Maak je een typfout als reqired, dan zie je dat meteen aan de kleur van de markering. Meer tips om problemen met PAM op te sporen staan trouwens in het kader ‘PAM-problemen?’.

Of de aanpassing is gelukt, kun je controleren in een nieuw terminalvenster met gewone gebruikersrechten. Het commando sudo -k id vraagt normaliter naar een wachtwoord. De -k verwijdert de aanwezige authenticatie-tokens, die er bijvoorbeeld voor zorgen dat je na een geslaagde sudo enkele minuten verder kunt werken als root zonder je opnieuw te hoeven aanmelden. Met de nieuwe PAM-configuratie vervalt die wachtwoordvraag helemaal.

Maar sudo zonder wachtwoord is misschien wel handig, maar vreselijk onveilig. Dus moet je in een root-venster de oorspronkelijke toestand weer herstellen: cp sudo-org sudo

Als je dat een keer succesvol geoefend hebt, ben je een beetje voorbereid op grotere klussen zoals de geplande tweefactor-verificatie. Dat instellen is eigenlijk niet zo moeilijk, want

Auth required pam_factor1.so

Auth required pam_factor2.so vereist al twee verplicht succesvolle authenticaties. Een reeks PAM-modules die je kunt inzetten als factor1/2 presenteren we in het volgende artikel op pagina 88. Dat kan bijvoorbeeld het invoeren van een korte pincode zijn in combinatie met een geslaagde gezichtsherkenning.

DE AFRONDING

Het uiteindelijk doel is om verschillende aanmeldopties te krijgen. Bij het starten van het systeem en de eerste keer aanmelden moet het lange en veilige wachtwoord worden ingevoerd. Bij het ontgrendelen na een toilet- of koffiepauze of een sudo tijdens het gebruik moet echter een makkelijke authenticatie volgen.

Dat laatste kan bijvoorbeeld een geslaagde gezichtsherkenning zijn in combinatie met het intypen van een (korte) pincode of het activeren van een hardware-token. Maar het wachtwoord moet in alle gevallen als fallback blijven functioneren, bijvoorbeeld voor als je de sleutelbos met het token thuis hebt laten liggen. Of als je remote wilt inloggen via SSH en daardoor de gezichtsherkenning of een lokaal aangesloten U2F-token geen beschikbare mogelijkheid zijn.

De regels in het kader ‘PAM-gemak met fallback’ zijn daar een concrete uitwerking van. In het volgende artikel bespreken we de gebruikte PAM-modules

en hoe je ze instelt. Natuurlijk kun je dat idee aanpassen. Heb je bijvoorbeeld een Linux-notebook met een vingerafdrukscanner, dan kun je pam_fprintd gebruiken. In plaats van een pincode-invoer via pam_ userdb.so kun je bijvoorbeeld een U2F-token gebruiken. Daarvoor hoef je alleen pam_userdb.so … te vervangen door pam_u2f.so.

De U2F-methode is in tegenstelling tot wachtwoorden en gezichtsherkenning voor zover bekend normaliter niet te omzeilen: zonder token krijg je geen toegang. Je kunt die dan ook gerust gebruiken als enige authenticatie voor sudo. Daarvoor moet je de eerste regel van een commentaar-hekje voorzien en geef je op de tweede regel pam_u2f op. Iemand die de token steelt, moet tenslotte eerst bij de commandline komen om een sudo- commando te kunnen uitvoeren. En daarvoor moet eerst de aanmelding of de schermvergrendeling gepasseerd worden.

Als uitgangspunt voor eigen experimenten staan bij de link op deze pagina deze en enkele andere voorbeeldconfiguraties met toelichting in de commentaarregels. Die kun je als vervanging gebruiken voor common-auth in het PAM-configuratiebestand /etc/pam.d/sudo. Dat werkt natuurlijk niet alleen met sudo, maar ook met andere programma's die hun authenticatie afhandelen via PAM. De PolicyKit in moderne Linux-systemen maakt bijvoorbeeld ook gebruik van PAM en houdt zich daarbij aan de regels in /etc/pam.d/polkit-1. Je kunt dat makkelijk testen via pkexec id.

Dan hoef je eigenlijk alleen nog de schermvergrendeling te voorzien van een makkelijke aanmelding met wachtwoord-fallback. Maar om dat zo te laten functioneren als je zou willen, zijn er nog enkele uitstapjes nodig naar onder andere de Gnomedesktopconfiguratie, Ubuntu's Hotkey-beheer en het Linux-apparaatbeheer via udev. Meer daarover lees je in het derde artikel in deze serie. Maar in het volgende artikel gaan we eerst verder in op Howdy en U2F.