Lennart Poettering vuole pensionare SUID: ecco quindi a voi run0, la versione Systemd di sudo!

Qualcuno sentiva la mancanza di notizie in merito al sistema di init che ormai è default sulla quasi totalità delle distribuzioni Linux? Stiamo ovviamente parlando di Systemd, la creatura di Lennart Poettering che procede spedita nei suoi sviluppi e nell’intento di voler coprire tutti gli aspetti relativi alla gestione del sistema Linux.

Se dopo i recenti systemd-boot, rimpiazzo di GRUB, ed il generatore di BSOD che ha portato “la schermata blu della morte” su Linux, ecco all’orizzonte un nuovo terreno di conquista per Systemd, ossia l’esecuzione di azioni privilegiate da parte di utenti che non lo sono, operazioni che fino ad oggi ciascuno Linux operator ha da sempre svolto mediante sudo, ma che d’ora in poi vedranno l’avvento di run0, ossia il sudo di Systemd.

L’annuncio di questa nuova tecnologia è stato dato dallo stesso Poettering mediante un post sulla piattaforma Mastodon, e riportato nell’ottimo articolo di FOSS Outpost nel quale appare chiaro il suo punto di vista:

I personally think that the biggest problem with sudo is the fact it’s a SUID binary though – the big attack surface, the plugins, network access and so on that come after it it just make the key problem worse, but are not in themselves the main issue with sudo. SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended for and controlled by unprivileged code. By execution context I mean the myriad of properties that a process has on Linux these days, from environment variables, process scheduling properties, cgroup assignments, security contexts, file descriptors passed, and so on and so on.

Personalmente penso che il problema più grande di sudo sia il fatto che è un binario SUID: la grande superficie di attacco, i plugin, l’accesso alla rete e così via che vengono dopo non fanno altro che peggiorare il problema chiave, ma non sono di per sé il principale problema. I processi SUID sono concetti strani: vengono invocati da codice non privilegiato ed ereditano il contesto di esecuzione previsto e controllato da codice non privilegiato. Per contesto di esecuzione intendo la miriade di proprietà che un processo ha su Linux al giorno d’oggi, dalle variabili di ambiente, alle proprietà di pianificazione del processo, alle assegnazioni di cgroup, ai contesti di sicurezza, ai descrittori di file passati e così via.

Perciò il problema è semplice: SUID, il meccanismo classico di elevazione dei privilegi in ambito *nix, andrà mandato in pensione, poiché oggi rispetto a quando è stato introdotto (più o meno con UNIX, una quarantina di anni fa…) la superficie di esposizione dei sistemi è cambiata sensibilmente.

Ecco quindi arrivare run0:

With systemd v256 we are going one step towards this. There’s a new tool in systemd, called “run0”. Or actually, it’s not a new tool, it’s actually the long-existing tool “systemd-run”, but when invoked under the “run0” name (via a symlink) it behaves a lot like a sudo clone. But with one key difference: it’s not in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY.

Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that’s an explicit exception, i.e. allowlist rather than denylist).

One could say, “run0” is closer to behaviour of “ssh” than to “sudo”, in many ways.

Con systemd v256 stiamo facendo un passo avanti verso questo [l’eliminazione di SUID]. C’è un nuovo strumento in systemd, chiamato “run0”. O in realtà, non è uno strumento nuovo, in realtà è lo strumento “systemd-run” esistente da molto tempo, ma quando invocato con il nome “run0” (tramite un link simbolico) si comporta in modo molto simile a un clone sudo. Ma con una differenza fondamentale: in realtà non è SUID. Chiede invece semplicemente al gestore del servizio di invocare un comando o una shell con l’UID dell’utente di destinazione. Assegna un nuovo PTY per questo, quindi sposta i dati avanti e indietro dal TTY di origine e da questo PTY.

O in altre parole: il comando di destinazione viene invocato in un contesto exec isolato, appena biforcato dal PID 1, senza ereditare alcun contesto dal client (beh, è vero, propaghiamo $TERM, ma questa è un’eccezione esplicita, cioè la lista consentita anziché lista negata).

Si potrebbe dire che “run0” è più vicino al comportamento di “ssh” che a “sudo”, in molti modi.

Quindi il terreno era già stato preparato, perché a tutti gli effetti questo run0 è un link simbolico a systemd-run che ad oggi tutti i sistemi Linux già montano.

Quali e quante distribuzioni useranno run0? Chi può dirlo, staremo a vedere, ma some per tutte le altre componenti l’ingresso sarà silente, e dall’oggi al domani la risposta di un operatore che chiederà “Scusa ma dov’è sudo?” potrà essere “Marò come sei vecchio, qui usiamo run0!”.

Si chiude con l’ultima affermazione, carica di quella che potremmo definire la “consueta simpatia Poetteringhiana“:

The tool is also a lot more fun to use than sudo. For example, by default, it will tint your terminal background in a reddish tone while you are operating with elevated privileges. That is supposed to act as a friendly reminder that you haven’t given up the privileges yet, and marks the output of all commands that ran with privileges appropriately. It also inserts a red dot (unicode ftw) in the window title while you operate with privileges, and drops it afterwards.

Il tool è anche molto più divertente [sic] da usare rispetto a sudo. Ad esempio, per impostazione predefinita, tingerà lo sfondo del tuo terminale con un tono rossastro mentre operi con privilegi elevati. Questo dovrebbe fungere da promemoria amichevole che non hai ancora rinunciato ai privilegi e contrassegnare l’output di tutti i comandi eseguiti con i privilegi in modo appropriato. Inserisce anche un punto rosso (unicode ftw) nel titolo della finestra mentre si opera con i privilegi e lo rilascia in seguito.

Quindi dopo la schermata blu, avremo anche lo sfondo rosso.

First things first.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

8 risposte a “Lennart Poettering vuole pensionare SUID: ecco quindi a voi run0, la versione Systemd di sudo!”

  1. Avatar Alessandro Scarozza
    Alessandro Scarozza

    per me dopo Stallman e Torvalds, Poettering è la figura più importante del mondo gnu/linux, piu passa il tempo e piu il termine “systemd/linux” acquista valore

    PS le traduzioni alle citazioni sono veramente minuscole 🙂

  2. Avatar Raoul Scarazzini

    Hai ragione su entrambe le cose: del peso di Poettering e della grandezza del carattere delle traduzioni, che ho ingrandito di un paio di pixel. Grazie.

  3. Avatar JustATiredMan
    JustATiredMan

    Prima di preoccuparsi della superficie di attacco di suid, Poettering dovrebbe preoccuparsi di quella di systemd.
    Il bailamme dietro xz, (anche se relativo piu al metodo con cui è stato condotto l’ attacco) ha avuto efficacia solo perchè usato da systemd. Le distro che non usano systemd non erano vulnerabili.

  4. Avatar gerlos

    Systemd è un target perché è il sistema di init usato dalla maggior parte dei server. Che è la stessa ragione per cui Linux è un target.

    Non c’è ragione di spendere tutte quelle risorse (nel caso xz parliamo di un attacco che ha richiesto anni di lavoro, con molta ingegneria sociale) per attaccare lo zero virgola zero qualcosa dei sistemi.

  5. Avatar floriano
    floriano

    è in arrivo un altro sabotaggio targato redhat, ovviamente cercherò di evitare pure questo.

  6. Avatar floriano
    floriano

    è per questo che lo evito, syatemd è troppo contorto…

  7. Avatar JustATiredMan
    JustATiredMan

    Più che contorto, è che è troppo invasivo, gestisce troppe cose e altri software ne sono troppo dipendenti. Se salta fuori una vulnerabilità da qualche parte, sia in systemd stesso, che in un altro software da cui dipende, può compromettere l’intero sistema.

  8. Avatar JustATiredMan
    JustATiredMan

    appunto… oltre al kernel, stai aggiungendo un altro elemento che ha la stessa importanza del s.o. sottostante. In pratica stai raddoppiando la superficie di attacco.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *