Spcnet.it

2026-07-30 08:49:45

Podman: l’alternativa a Docker che ogni sysadmin Linux dovrebbe conoscere

Per anni Docker è stato il default indiscusso quando si parlava di container su Linux. Ma l’architettura basata su un daemon centrale che gira come root ha sempre lasciato sul tavolo un problema di superficie d’attacco: se qualcuno compromette dockerd, ha di fatto accesso root all’intero host. Podman nasce proprio per chiudere questo gap, offrendo un motore container daemonless, compatibile con le immagini OCI e con la CLI Docker, che si integra in modo molto più nativo con systemd e con il modello di permessi di Linux.

Vediamo come installarlo, come si differenzia realmente da Docker oltre gli slogan, e come portarlo in produzione con systemd e le Quadlet, che sono probabilmente la ragione migliore per prenderlo sul serio.

Cos’è Podman, in pratica

Podman (da Pod Manager) è un motore container open source senza demone centrale. Ogni container gira come processo figlio dell’utente che lo ha avviato, non come figlio di un servizio di sistema con privilegi elevati. Questo significa che è possibile eseguire container completamente rootless, senza mai invocare sudo, riducendo drasticamente cosa un container compromesso può effettivamente toccare sull’host.

Sotto il cofano Podman usa gli stessi runtime OCI di Docker e parla lo stesso formato immagine, quindi la stragrande maggioranza dei comandi Docker funziona invariata sostituendo semplicemente il nome del binario (o creando un alias docker=podman, oppure installando il pacchetto podman-docker che fa da shim trasparente).

Un concetto che Docker non ha nativamente è quello di pod: gruppi di uno o più container che condividono rete e storage, concettualmente vicini ai pod di Kubernetes. Comodo quando si vogliono far girare insieme più container che devono comunicare come se fossero sulla stessa macchina.

Installazione

# Debian/Ubuntu (Debian 11+, Ubuntu 20.10+)
sudo apt-get update
sudo apt-get -y install podman

# Fedora/CentOS/RHEL 8+
sudo dnf -y install podman

# openSUSE
sudo zypper install podman

# Arch/Manjaro
sudo pacman -S podman

Verifica dell’installazione:

podman --version
podman info
podman run hello-world

Se l’ultimo comando restituisce il messaggio di benvenuto di Podman, l’installazione è a posto.

Uso quotidiano: i comandi non cambiano quasi nulla

Shell interattiva dentro un container Ubuntu:

podman run -it ubuntu bash

Servizio in background, con Nginx esposto sulla porta 8080 dell’host:

podman run -d --name web -p 8080:80 nginx
podman ps

Il resto della CLI ricalca Docker praticamente 1:1: podman pull, podman images, podman stop/start, podman rm/rmi. Dietro le quinte, podman build è in realtà un wrapper attorno a Buildah, mentre lo spostamento di immagini tra registry passa per Skopeo: strumenti separati che Podman orchestra per te, senza che serva conoscerli nel dettaglio per l’uso base.

Dove Docker e Podman divergono davvero

La compatibilità è alta ma non totale, e i problemi emergono quasi sempre dal modello rootless. Il caso più comune sono i bind mount: poiché i container rootless usano user namespace e mapping subuid/subgid, una directory montata dall’host non sempre ha la proprietà che il container si aspetta. Su sistemi con SELinux attivo serve anche il suffisso :z o :Z per far ri-etichettare correttamente i file:

podman run -v /host/path:/container/path:Z myimage

:z minuscolo condivide il volume tra più container, :Z maiuscolo lo rende privato per un singolo container. Se serve far coincidere esattamente la proprietà con quella dell’host, l’opzione --uidmap permette un controllo fine, oppure si può far girare il container in modalità rootful per replicare il comportamento di Docker.

Altri attriti da conoscere prima di migrare: l’accesso GPU da container rootless è limitato (NVIDIA richiede nvidia-container-toolkit e setup CDI, con i container da ricreare a ogni aggiornamento driver), e i Docker secrets insieme ad alcune configurazioni di rete non hanno una corrispondenza 1:1. Niente di bloccante, ma va testato prima di assumere che la migrazione sia un semplice “find and replace”.

Container come servizi systemd: le Quadlet

Questo è probabilmente il motivo migliore per scegliere Podman in un contesto server. Invece di lasciare un demone in background a gestire lo stato dei container, si delega tutto a systemd, che diventa responsabile di avvio, riavvio e supervisione, esattamente come per qualsiasi altro servizio di sistema.

Il meccanismo si chiama Quadlet: un file dichiarativo con estensione .container che Podman traduce automaticamente in una unit systemd. Per un servizio utente rootless, il file va in ~/.config/containers/systemd/. Esempio minimo per Nginx:

[Container]
ContainerName=web
Image=docker.io/library/nginx:latest
PublishPort=8080:80

[Install]
WantedBy=default.target

Attivazione:

systemctl --user daemon-reload
systemctl --user start web

Da questo momento il container è gestito da systemd come un servizio qualsiasi: si riavvia in caso di crash, si integra con i log di journald, si può abilitare al boot. Aggiungendo l’etichetta AutoUpdate=registry a un container, inoltre, podman auto-update può controllare periodicamente nuove versioni dell’immagine e riavviare il servizio in automatico, senza bisogno di Watchtower o strumenti equivalenti.

Migrare da Docker Compose

Chi ha un’infrastruttura basata su Compose ha due strade percorribili. La prima è continuare a usare Compose così com’è: il binario standalone docker compose può puntare al socket di Podman senza toccare i file docker-compose.yml esistenti:

systemctl --user enable --now podman.socket

La seconda è convertire i file Compose in Quadlet, così che sia systemd a gestire tutto nativamente. Scrivere le unit a mano è tedioso, quindi conviene usare podlet, un tool che legge un docker-compose.yml e genera i file Quadlet corrispondenti. C’è una curva di apprendimento, ma è comunque più veloce che partire da zero.

Docker resta rilevante

Nonostante i vantaggi di Podman, Docker non sta scomparendo. L’ecosistema attorno a Docker (Compose, Swarm, e tutta la tooling che si integra con esso, inclusi molti sistemi CI/CD già configurati per il socket Docker) resta enorme, e non tutte le piattaforme gestiscono bene le peculiarità rootless di Podman. Se un team è già standardizzato su Docker, spesso ha più senso restare sull’esistente piuttosto che affrontare una migrazione per un guadagno marginale.

Dove Podman convince davvero è quando si parte da zero: setup più sicuro per default, nessun demone da tenere sotto controllo, integrazione diretta con systemd per la gestione del ciclo di vita dei servizi.

Conclusione

Podman è un motore container completo, compatibile con Docker, che funziona senza demone e senza bisogno di privilegi root. Per l’uso quotidiano è quasi un drop-in replacement: si installa dal repository della distribuzione, si usano gli stessi comandi (o si crea l’alias docker=podman), e si ottengono benefici di sicurezza concreti senza dover reimparare nulla. I limiti di compatibilità, soprattutto su bind mount, GPU e secrets, vanno conosciuti e testati prima di una migrazione in produzione, ma per chi sta impostando nuovi ambienti containerizzati su Linux, specialmente se pensa di gestirli con systemd e Quadlet, vale decisamente la pena valutarlo.

Fonte originale: Hayden James, “Docker Alternative: Podman on Linux”, LinuxBlog.io.

Docker Alternative: Podman on Linux | LinuxBlog.io

This article is inspired by our LinuxCommunity.io forum discussion thread (thanks to users @tmick and @shybry747 for the feedback). Let's walk through

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-07-30 08:49:28

C# 15 introduce le union: basta OneOf e Results per modellare i tipi (.NET 11 Preview 6)

Da anni gli sviluppatori C# aspettano un modo nativo per dire “questo valore è esattamente uno tra questi tipi, e nient’altro”, con il compilatore in grado di garantirlo. In assenza di un supporto di linguaggio, la community si è arrangiata con pattern come Results<T> di ASP.NET Core Minimal API o con librerie come OneOf. Funzionano, ma con un limite strutturale: se aggiungi un quarto caso possibile a una funzione che prima ne restituiva tre, nessuno ti avvisa che uno switch a valle non gestisce il nuovo tipo. Manca l’esaustività, che è poi il punto centrale delle discriminated union.

Con .NET 11 Preview 6 (rilasciata il 14 luglio 2026) e C# 15, questa lacuna si chiude: arriva la parola chiave union, insieme a un intero pacchetto di funzionalità correlate (conversioni implicite, pattern matching esaustivo, gestione della nullabilità) che rendono i union type un cittadino di prima classe del linguaggio.

La sintassi: dichiarare un union type

La forma più semplice è la union declaration, una sintassi compatta che genera automaticamente uno struct:

public union Pet(Cat, Dog, Bird);

Questa singola riga dice al compilatore che un Pet è esattamente un Cat, un Dog o un Bird, e nient’altro. Sotto il cofano, il compilatore genera uno struct che implementa l’interfaccia System.Runtime.CompilerServices.IUnion e conserva il valore effettivo in una proprietà Value di tipo object?.

I union generici sono immediatamente utili per modellare risultati di operazioni che possono fallire, un caso d’uso ricorrentissimo in codice di produzione:

public union Result<TSuccess, TError>(TSuccess, TError);

Result<User, Error> Register(string username)
{
    if (string.IsNullOrEmpty(username))
        return new Error("Username cannot be empty");

    return new User(username);
}

Da notare l’ultima riga: nessun wrapping esplicito, nessuna chiamata a un factory method. Il valore User o Error viene convertito implicitamente in Result<User, Error> grazie alle union conversion generate automaticamente per ogni case type.

Pattern matching esaustivo, finalmente

Il vero salto di qualità è nel matching. Se dimentichi un caso in uno switch su un union type, il compilatore te lo dice:

string Describe(Pet pet) => pet switch
{
    Dog d => d.Name,
    Cat c => c.Name,
    // CS8509: switch expression does not handle all
    // possible values of its input type (Bird)
};

Aggiungendo il caso mancante, l’avviso scompare, e non serve più il classico _ => throw new InvalidOperationException("unreachable") per zittire il compilatore:

string Describe(Pet pet) => pet switch
{
    Dog d => d.Name,
    Cat c => c.Name,
    Bird b => b.Name,
};

Il punto interessante è che questa esaustività è dinamica: se in futuro aggiungi un nuovo case type al union (per esempio un quarto animale), ogni switch esistente che non lo gestisce si illumina di un warning. Per chi ha inseguito bug di produzione causati da un case dimenticato in un evento di dominio, è un cambiamento non da poco.

I pattern si applicano direttamente al union, senza bisogno di accedere manualmente a .Value: il compilatore effettua l’unwrapping in automatico, anche negli if pattern classici:

if (pet is Dog d)
{
    Console.WriteLine(d.Name);
}

Gestione del null

Il valore di default di un union type ha Value == null, ed è possibile intercettarlo esplicitamente con il pattern null:

string Describe(Pet pet) => pet switch
{
    null => "nessun animale",
    Dog d => d.Name,
    Cat c => c.Name,
    Bird b => b.Name,
};

La necessità o meno del ramo null dipende dal fatto che il parametro o il campo union-typed sia nullable: l’analisi di nullabilità del compilatore guida correttamente questi casi, in coerenza con le annotazioni #nullable enable già in uso nella maggior parte delle codebase moderne.

Un caso pratico: modellare eventi di dominio

I union type diventano davvero interessanti quando li si combina con i record per il domain modeling, per esempio in un sistema di elaborazione ordini con eventi distinti:

public record OrderPlaced(Guid OrderId, decimal Total);
public record OrderShipped(Guid OrderId, string TrackingNumber);
public record OrderCancelled(Guid OrderId, string Reason);
public union OrderEvent(OrderPlaced, OrderShipped, OrderCancelled);

string Summarize(OrderEvent evt) => evt switch
{
    OrderPlaced p    => $"Ordine {p.OrderId} piazzato per {p.Total:C}",
    OrderShipped s   => $"Ordine {s.OrderId} spedito, tracking: {s.TrackingNumber}",
    OrderCancelled c => $"Ordine {c.OrderId} annullato: {c.Reason}",
};

Quando tra tre mesi qualcuno aggiungerà OrderRefunded al union, ogni handler che non lo gestisce lancerà un warning in fase di compilazione, invece di fallire silenziosamente in produzione. È il compilatore che fa da revisore di esaustività al posto tuo.

I union possono anche esporre metodi e proprietà calcolate (ma non campi d’istanza), utile per incapsulare logica di conversione:

public union Length(Meters, Feet)
{
    public double TotalMeters => this switch
    {
        Meters m => m.Value,
        Feet f   => f.Value * 0.3048,
        _        => throw new InvalidOperationException(),
    };
}

Union personalizzati con l’attributo [Union]

La parola chiave union genera sempre uno struct. Se per motivi di identità, ereditarietà o layout di memoria serve un tipo reference, è possibile costruire un union personalizzato applicando direttamente l’attributo System.Runtime.CompilerServices.UnionAttribute e implementando l’interfaccia IUnion:

[System.Runtime.CompilerServices.Union]
public class Shape : System.Runtime.CompilerServices.IUnion
{
    private readonly object? _value;
    public Shape(Circle value)    { _value = value; }
    public Shape(Rectangle value) { _value = value; }
    public object? Value => _value;
}

Nella grande maggioranza dei casi, però, la sintassi union compatta copre già ogni esigenza pratica: l’approccio con attributo è pensato per scenari con requisiti specifici che lo struct generato non può soddisfare.

Come provarlo oggi

I union type sono attualmente in preview. Per sperimentarli serve l’SDK .NET 11 Preview e questa configurazione nel file di progetto:

<PropertyGroup>
    <LangVersion>preview</LangVersion>
    <TargetFramework>net11.0</TargetFramework>
</PropertyGroup>

Vale la pena ricordare che si tratta di una feature specification ancora in evoluzione: alcuni dettagli di comportamento (per esempio le regole esatte su nullabilità di default o sulle conversioni sollevate/”lifted”) sono ancora oggetto di discussione nel repository dotnet/csharplang, quindi è normale osservare piccoli cambiamenti tra una preview e l’altra prima del rilascio finale.

Conclusioni

F# ha le discriminated union fin dalle origini, e la richiesta di un equivalente in C# (csharplang issue #113) è aperta da anni. Con l’arrivo dei union type, non ogni problema di modellazione richiede più una gerarchia di classi: per rappresentare “uno tra un insieme chiuso di tipi”, ora esiste un costrutto di linguaggio dedicato, con conversioni implicite, pattern matching esaustivo e un’ottima integrazione con i record esistenti. Per chi lavora ogni giorno con API che possono restituire risultati eterogenei, o con event sourcing e domain modeling, è una delle novità più concrete della prossima versione di C#.

Fonte: .NET Blog, C# language reference proposal: Unions e Maarten Balliauw.

Discriminated unions in C# and .NET 11 (for real this time) | Maarten Balliauw {blog}

Back in 2023, I wrote about discriminated unions in C# and how C# developers had to work around the lack of language support using things like ASP.NET Core’s Results type or the OneOf NuGet package.

^{Maarten Balliauw (Maarten Balliauw {blog})}

Pirati.io

2026-07-24 14:07:35

I governi dell'UE hanno voluto il ritorno di Chat Control 1.0 – Breyer: “I veri perdenti sono i nostri figli”

#ChatControl 1.0 è tornato: i governi UE (tranne 🇭🇺+🇧🇪) hanno prorogato la scansione indiscriminata dei messaggi privati da parte dei servizi USA fino al 2028, aggirando il Parlamento europeo. Cosa cambia ora e i prossimi passi

pirati.io/2026/07/i-governi-de…

@privacypride

I governi dell’UE hanno voluto il ritorno di Chat Control 1.0 – Breyer: “I veri perdenti sono i nostri figli”

ChatControl 1.0 è tornato: i governi UE (tranne 🇭🇺+🇧🇪) hanno prorogato la scansione indiscriminata dei messaggi privati da parte dei servizi USA fino al 2028, aggirando il Parlamento europeo.

^{macfranc (Pirati.io)}

(in)sicurezza digitale

2026-07-27 17:09:45

JadeProx: il cluster cinese che si è tradito da solo mentre colpiva ospedali, ministeri e università in Asia

Un server Alibaba Cloud lasciato aperto per errore ha smascherato un intero cluster di cyberspionaggio China-nexus: intrusioni attive contro un ospedale vietnamita, il Ministero degli Esteri malese, decine di istituti universitari di Hong Kong e persino un pacchetto di spear-phishing indirizzato al Congresso dell’Honduras. Group-IB lo chiama JadeProx, e la sua tradecraft ruota attorno a un loader Windows mai documentato prima, il TriBack Loader, distribuito anche tramite un finto installer di Claude.

Un errore operativo che vale un intero dossier

A metà aprile 2026 i ricercatori di Group-IB hanno individuato, nella regione Singapore di Alibaba Cloud, un server di staging esposto senza alcuna autenticazione. Al momento della pubblicazione del report, il 23 luglio 2026, il server era già stato smantellato, ma la sua cronologia bash, i pacchetti di phishing, gli strumenti post-exploitation e i path dei webshell hanno permesso di ricostruire in dettaglio un’operazione attiva su tre continenti diversi.

Gli obiettivi identificati sono eterogenei ma coerenti con un mandato di raccolta informativa ad ampio spettro tipico degli operatori legati alla Cina: il sistema di imaging medicale (PACS, Picture Archiving and Communications System) di un ospedale pubblico vietnamita, da cui transitano radiografie, TAC e risonanze dei pazienti; il Ministero degli Esteri della Malesia, violato con webshell e strumenti di tunneling; l’infrastruttura universitaria di Hong Kong, colpita con una scansione massiva; e un pacchetto di spear-phishing con decoy finanziario indirizzato al Congresso Nazionale dell’Honduras. Gli operatori sono arrivati al server dell’ospedale vietnamita attraverso webshell piazzate su un’interfaccia di gestione Java esposta su Internet.

TriBack Loader: un unico loader, quattro varianti

Al centro della tradecraft c’è un loader Windows che Group-IB battezza TriBack Loader, mai documentato in precedenza. Compare in quattro catene di infezione, tutte costruite attorno al DLL sideloading: un eseguibile legittimo firmato viene abbinato a una DLL malevola e a un payload cifrato in formato .dat o .log.

La DLL inverte i byte del payload, li decifra con XOR a chiave rotante, ed esegue lo shellcode tramite chiamate Win32 che gli EDR monitorano meno rispetto alla classica CreateThread. Le quattro varianti si differenziano proprio nella chiamata finale usata per l’esecuzione: due si affidano a InitOnceExecuteOnce e a un callback TimerQueue, una terza sfrutta EtwpCreateEtwThread, una routine non documentata di ntdll per la creazione di thread. Anche il binario firmato ospite cambia da variante a variante. Per i ricercatori, la ripetizione sistematica della stessa sequenza di API suggerisce l’esistenza di un builder automatizzato per la generazione del loader.

Due varianti distribuiscono AdaptixC2, framework open source di post-exploitation già osservato in altre campagne ransomware. Una terza variante, particolarmente insidiosa, si maschera da software Claude: usa DonutLoader per eseguire Beagle, una backdoor documentata per la prima volta da Sophos. La quarta variante resta un mistero: il file cifrato che ne conteneva il payload non è mai stato recuperato.

L’esca perfetta: un finto Claude con MSI malevolo

Uno degli aspetti più rilevanti per un pubblico di professionisti è la campagna di impersonificazione del software Anthropic. Il dominio claude-pro[.]com, registrato il 28 marzo 2026, ha distribuito un installer MSI malevolo che, superato un prompt UAC, posizionava la catena di sideloading nella cartella di avvio di Windows per garantirsi la persistenza. La backdoor Beagle consegnata da questa variante comunicava con license[.]claude-pro[.]com come infrastruttura di comando e controllo.

Sophos, lavorando a partire dal sito fasullo, dalla sua infrastruttura di hosting e dai campioni di malware raccolti, ha rilevato la stessa chiave XOR riutilizzata in build risalenti a febbraio 2026, ma ha specificato che una chiave condivisa non basta da sola a confermare un singolo attore dietro tutte le campagne: nell’ecosistema China-nexus gli strumenti circolano liberamente tra gruppi diversi. Lo stesso approccio prudente vale per Group-IB, che raggruppa le intrusioni asiatiche sotto l’etichetta JadeProx senza attribuirle in modo definitivo a un gruppo APT già catalogato.

Se la valutazione di Sophos è corretta e il sito fasullo faceva parte di una campagna di malvertising attiva, l’esposizione va ben oltre ministeri e ospedali: raggiunge chiunque, nel mondo, stesse semplicemente cercando di scaricare Claude.

Vulnerabilità vecchie di anni per colpire infrastrutture nuove

Sul fronte dello scanning contro l’istruzione di Hong Kong, gli operatori hanno lanciato Nuclei con template a severità critica contro una lista di 14.653 URL legati al settore educativo, individuando 13 vulnerabilità uniche. Il report non specifica quanti tentativi di sfruttamento successivi abbiano avuto successo, ma indica quattro CVE specifiche tentate contro singoli host, tutte con punteggio CVSS 9.8: CVE-2018-11511 (ASUSTOR ADM), CVE-2021-24139 (plugin WordPress 10Web Photo Gallery), CVE-2021-31755 (router Tenda AC11) e CVE-2021-32305 (WebSVN).

Il dettaglio interessante per i difensori è che la falla su Tenda AC11 è nel catalogo KEV (Known Exploited Vulnerabilities) di CISA dal 3 novembre 2021, con una scadenza di remediation federale spirata appena due settimane dopo. In altre parole: la parte “artigianale” e sofisticata di questa operazione — loader custom, sideloading, ETW abuse — si appoggia a un ingresso iniziale banale, fatto di CVE pubbliche e non patchate da anni. L’ingegneria del loader conta poco se la porta d’ingresso resta aperta dal 2021.

Cosa monitorare

Group-IB e i ricercatori coinvolti raccomandano di concentrare il rilevamento sulla catena di sideloading piuttosto che sui singoli indicatori di rete, dato che nomi file e host firmati cambiano a ogni build:

• Segnalare binari vendor firmati eseguiti da directory scrivibili dall’utente, temporanee o dalla cartella Startup, specialmente in presenza di file .dat o .log cifrati nella stessa cartella.
• Cercare copie sospette di hostfxr.dll, avk.dll o MpClient.dll, insieme a cartelle annidate del tipo _CL_###### e allo script ~del.vbs.bat.
• Bloccare o investigare i domini del cluster: claude-pro[.]com, license[.]claude-pro[.]com, sylverixstrategy[.]com, gouvvbo[.]top, vertextrust-advisors[.]com, e tre domini civetta che imitano vendor di sicurezza condividendo lo stesso IP — update-trellix[.]com, update-crowdstrike[.]com, update-sentinelone[.]com.
• Dare priorità alle applicazioni Java esposte su Internet, quindi a qualsiasi sistema pubblico con una falla non patchata di severità 9.8, incluse le quattro citate.

Indicatori di compromissione

Domini:
claude-pro[.]com (registrato 28/03/2026)
license[.]claude-pro[.]com
sylverixstrategy[.]com
gouvvbo[.]top
vertextrust-advisors[.]com
update-trellix[.]com
update-crowdstrike[.]com
update-sentinelone[.]com

Infrastruttura di staging:
43.106.71[.]28:8000

CVE sfruttate (CVSS 9.8):
CVE-2018-11511 - ASUSTOR ADM
CVE-2021-24139 - 10Web Photo Gallery (WordPress)
CVE-2021-31755 - Tenda AC11 (KEV CISA dal 03/11/2021)
CVE-2021-32305 - WebSVN

Artefatti su disco:
hostfxr.dll / avk.dll / MpClient.dll (copie sospette)
_CL_###### (cartelle annidate)
~del.vbs.bat

Malware associato:
TriBack Loader (loader custom, DLL sideloading)
AdaptixC2 (post-exploitation open source)
DonutLoader -> Beagle backdoor

Fonti: report Group-IB, The Hacker News, Sophos.

JadeProx: Tracing a China-nexus Operation Through an OPSEC Mistake

During ongoing monitoring of malicious infrastructure, Group-IB identified an exposed staging server that uncovered an active China-nexus operation.

^{Sathwik Ram Prakki (Group-IB)}