sudo och minsta möjliga rättigheter

Modul 3: Användare, rättigheter och sudo · Lästid: 11 minuter

Lärandemål: Efter den här lektionen kan du arbeta som vanlig användare med sudo, lägga till en administratör på ett säkert sätt, ändra sudo-inställningarna utan att låsa ute dig själv och förklara varför minsta möjliga rättigheter skyddar din server.

Nyckelbegrepp: sudo, gruppen sudo, gruppen wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, låsa root, sudo-loggen, minsta möjliga rättigheter (least privilege), tjänsteanvändare

Varför inte bara arbeta som root?

Efter installationen loggar du ofta in som root. Det är bekvämt: allt är tillåtet. Men just det är problemet:

• Ett enda skrivfel räcker. rm -rf / home/anna/oud (observera mellanslaget efter det första snedstrecket) raderar hela din server om du är root. Som vanlig användare får du ett felmeddelande.
• Allt körs som root. Ett skript du klistrar in från internet, ett program du testar: allt får fullständiga rättigheter.
• Inga spår. Om tre personer arbetar som root vet ingen i efterhand vem som gjorde vad.
• Root är namnet som varje angripare provar. Inloggning som root bör du helst stänga av helt (lektion 2.2), men det går först när du har en annan väg till administratörsrättigheter.

Den andra vägen är sudo: du loggar in som dig själv och skriver sudo bara framför ett kommando som behöver administratörsrättigheter.

anna@web1:~$ apt update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
anna@web1:~$ sudo apt update
[sudo] password for anna:
Hit:1 http://deb.debian.org/debian trixie InRelease
...

(Ubuntu använder sedan version 25.10 som standard sudo-rs, en ny implementation av sudo. För allt i den här lektionen fungerar den likadant.)

sudo frågar efter ditt lösenord, inte roots. Därefter kommer det ihåg det i en kvart som standard, så att du inte behöver ange det vid varje kommando. Varje kommando du kör med sudo hamnar i loggen.

Skapa en administratör

På Debian och Ubuntu får alla i gruppen sudo göra allt via sudo. Det står i /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL

Läs det som: medlemmar i gruppen sudo (%) får på alla maskiner (ALL) som vilken användare och grupp som helst ((ALL:ALL)) köra vilket kommando som helst (ALL).

Att lägga till en administratör görs alltså i två steg, som root:

root@web1:~# adduser anna
root@web1:~# adduser anna sudo

Lägg sedan Annas publika nyckel i /home/anna/.ssh/authorized_keys med rätt ägare och rättigheter:

root@web1:~# mkdir -p /home/anna/.ssh
root@web1:~# cp /root/.ssh/authorized_keys /home/anna/.ssh/
root@web1:~# chown -R anna:anna /home/anna/.ssh
root@web1:~# chmod 700 /home/anna/.ssh
root@web1:~# chmod 600 /home/anna/.ssh/authorized_keys

Glöm inte chown: kopierad av root tillhör filen root, och då kan Anna inte logga in med sin nyckel.

Testa nu i ett andra fönster, medan din root-session är öppen:

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$ sudo -l
[sudo] password for anna:
User anna may run the following commands on web1:
    (ALL : ALL) ALL
anna@web1:~$ sudo whoami
root

Först när det fungerar ställer du in PermitRootLogin no i dina SSH-inställningar (lektion 2.2). Från och med då loggar du alltid in som Anna.

En sak att komma ihåg: Anna behöver nu ett lösenord för sudo. Spara det i din lösenordshanterare. Inloggning sker med nyckeln, sudo med lösenordet: två olika saker som en inkräktare måste ha båda.

Ändra sudo-inställningar: alltid med visudo

Ett fel i /etc/sudoers kan innebära att sudo slutar fungera helt. Om root inte heller kan logga in sitter du fast. Därför redigerar du aldrig sudo-inställningar med en vanlig editor, utan med visudo. Den öppnar en tillfällig kopia och kontrollerar innehållet innan den sparar:

root@web1:~# visudo -f /etc/sudoers.d/backup

Precis som med SSH använder du hellre en egen fil i /etc/sudoers.d/ än huvudfilen. Observera två regler för den katalogen:

• Filer vars namn innehåller en punkt eller slutar på ~ hoppas över. backup.conf fungerar alltså inte, men backup gör det. Det är tänkt för att ignorera kopior från editorer, men det överraskar många.
• Filen måste ägas av root och inte vara skrivbar för andra (440 är vanligt; visudo ordnar det).

Vill du kontrollera en befintlig fil utan att redigera den: visudo -c kontrollerar allt.

NOPASSWD: praktiskt, men vet vad du gör

Med NOPASSWD frågar sudo inte längre efter lösenord:

anna ALL=(ALL:ALL) NOPASSWD: ALL

Vissa VPS-avbildningar ställer in detta för standardanvändaren, så att du blir administratör direkt efter att ha loggat in med en nyckel. Kontrollera med sudo -l vad som gäller hos dig. Följden: den som har Annas nyckel är direkt root. Det finns inget andra lås längre. För en personlig server kan du välja det, men gör det medvetet.

Mycket bättre är NOPASSWD bara för ett visst kommando, till exempel för ett skript för säkerhetskopior som ska kunna köras automatiskt:

backup ALL=(root) NOPASSWD: /usr/local/bin/maak-backup

Användaren backup får då köra exakt det enda skriptet som root, utan lösenord, och inget annat. Två fallgropar:

• Använd alltid den fullständiga sökvägen. Med bara maak-backup kan någon lägga ett eget program med det namnet först i sin sökväg.
• Själva skriptet får inte vara skrivbart för den användaren. Annars kan användaren ändra det och sedan köra godtyckliga kommandon som root. Detsamma gäller kommandon som själva kan öppna ett skal, som en editor (vim, nano) eller less: den som får starta dem via sudo kan öppna ett root-skal inifrån programmet. Ge aldrig ut sådana kommandon separat via sudo.

Vad som loggas

Varje gång någon använder sudo hamnar en rad i journalen (och på system med rsyslog även i /var/log/auth.log):

anna@web1:~$ sudo journalctl _COMM=sudo --since today
Nov 09 10:31:02 web1 sudo[2214]:     anna : TTY=pts/0 ; PWD=/home/anna ; USER=root ; COMMAND=/usr/bin/apt update

Du ser vem, var, som vem och vilket kommando. Det är ett av skälen till att inte arbeta som root med flera personer. Misslyckade sudo-försök ("incorrect password attempts") från ett konto som inte är ditt är en varningssignal.

Minsta möjliga rättigheter i stort

sudo är en tillämpning av en allmän princip: minsta möjliga rättigheter (least privilege). Varje användare och varje tjänst får exakt de rättigheter som behövs, och inte fler. På en server innebär det bland annat:

• du arbetar som vanlig användare och använder sudo bara när det behövs;
• varje tjänst körs under en egen användare utan skal (lektion 3.1), inte som root;
• en webbapplikation får en databasanvändare som bara får använda sin egen databas, inte administratören för databasservern;
• ett skript för säkerhetskopior får bara köra det enda kommando det behöver (NOPASSWD med fullständig sökväg);
• en kollega som bara uppdaterar webbplatsen får skrivrätt till /var/www/example.com via en grupp, inte sudo.

Tanken: om något går fel (en sårbarhet i ett tillägg, en stulen nyckel) begränsas skadan till just den användaren eller tjänsten. I CIS-principerna och lektionen om härdning (10.1) återkommer detta hela tiden.

På AlmaLinux och Rocky Linux

Där heter administratörsgruppen wheel i stället för sudo: usermod -aG wheel anna. Raden i /etc/sudoers är %wheel ALL=(ALL) ALL. visudo och /etc/sudoers.d fungerar likadant. Sudo-meddelanden finns där även i /var/log/secure.

Sammanfattning

• Arbeta som vanlig användare och använd sudo för administration; sudo frågar efter ditt eget lösenord och loggar varje kommando.
• Skapa en administratör: adduser anna, adduser anna sudo (wheel på RHEL-liknande system), nyckel med rätt ägare och rättigheter, testa i ett andra fönster, stäng först därefter av root-inloggning.
• Redigera sudo-regler bara med visudo, helst i en egen fil i /etc/sudoers.d/ utan punkt i namnet.
• NOPASSWD för allt tar bort ett lås; använd det hellre bara för ett kommando med fullständig sökväg som användaren inte kan ändra.
• Minsta möjliga rättigheter: varje användare och tjänst får exakt det som behövs, så att ett fel eller en sårbarhet förblir liten.

Quiz

Uppgift

Uppgift O3.2: En administratör med sudo. Skapa en vanlig administratör på din server (till exempel anna), ordna din nyckel, testa inloggning och sudo -l i ett andra fönster och stäng sedan av root-inloggning via SSH (PermitRootLogin no). Bocka av stegen, klistra in utdata från id (bara namn och grupper) och besvara frågorna: vilken rad ger din administratör rättigheter, står det NOPASSWD någonstans, och hur kommer du in om du glömmer ditt lösenord?

Läs mer

Stegen i de här artiklarna gäller för WebOkés VPS:er; hos andra leverantörer fungerar det på liknande sätt.

• Skydda din VPS: de första fem minuterna
• Ingen åtkomst till din VPS längre: vad gör du?
• DirectAdmin-guide 12.2: Databasanvändare, behörigheter och lösenord
• Ubuntu Server: User management: https://ubuntu.com/server/docs/how-to/security/user-management/
• Debians manual för sudoers: https://manpages.debian.org/trixie/sudo/sudoers.5.en.html