{"id":170830,"date":"2026-05-16T18:24:39","date_gmt":"2026-05-16T16:24:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux"},"modified":"2026-05-16T18:24:39","modified_gmt":"2026-05-16T16:24:39","slug":"model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","title":{"rendered":"Modello di minacce e caratteristiche della valutazione delle vulnerabilit\u00e0 nel kernel Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Linus Torvalds ha incluso nel kernel un documento che regola il processo di gestione degli errori relativi alla sicurezza, definendo il modello delle minacce e spiegando quali errori nel kernel sono considerati vulnerabilit\u00e0, trattando le azioni da intraprendere con gli errori identificati tramite AI. Il documento \u00e8 stato redatto da Willy Tarreau, autore di HAProxy e da lungo tempo sviluppatore del kernel Linux, responsabile della manutenzione di diversi rami stabili del kernel. Come base, sono stati utilizzati gli accordi raggiunti durante le discussioni su recenti vulnerabilit\u00e0 critiche nel kernel (1, 2, 3, 4), rivelate prima della pubblicazione delle correzioni e per le quali, grazie all'AI, \u00e8 stato possibile generare immediatamente exploit funzionanti. <\/p>\n
La maggior parte degli errori associati alla sicurezza deve essere gestita pubblicamente, al fine di coinvolgere il pubblico pi\u00f9 ampio possibile e trovare la soluzione ottimale. Solo le comunicazioni urgenti riguardanti vulnerabilit\u00e0 facilmente sfruttabili, che rappresentano una minaccia per molti utenti e che consentono di ottenere privilegi o capacit\u00e0 estesi, devono essere inviate a un elenco di distribuzione privato. <\/p>\n
Le vulnerabilit\u00e0 identificate con l'ausilio di assistenti AI dovrebbero sempre essere discusse pubblicamente, poich\u00e9 tali problemi vengono spesso scoperti simultaneamente da pi\u00f9 ricercatori. Tuttavia, non \u00e8 necessario rivelare l'exploit nel report - \u00e8 sufficiente menzionare che \u00e8 disponibile e consegnarlo privatamente su richiesta del responsabile. <\/p>\n
Le regole per la consegna dei rapporti generati con assistenti AI sono descritte separatamente. Vengono ricevuti molti rapporti di questo tipo e grazie a essi si riesce occasionalmente a identificare errori in parti di codice poco revisionate, ma i revisori spesso li ignorano a causa della bassa qualit\u00e0 e delle imprecisioni. I requisiti principali per i rapporti generati con il contributo dell'AI sono: <\/p>\n
\n
Sintesi, senza fronzoli e con l'indicazione della sostanza e dei dettagli importanti all'inizio.\n
Solo testo semplice senza tag Markdown e decorazioni.\n
Comprendere il modello delle minacce e specificare i fatti verificabili (ad esempio, \u00abl'errore consente a qualsiasi utente di ottenere CAP_NET_ADMIN\u00bb), piuttosto che teorie e congetture sulle conseguenze della vulnerabilit\u00e0.\n
Prima di inviare il rapporto, \u00e8 fondamentale testare a fondo il funzionamento dell'exploit generato tramite AI e assicurarsi di poter riprodurre il problema.\n
Coinvolgere l'AI per lo sviluppo e il test della correzione del problema identificato. <\/ul>\n
Secondo le statistiche degli accompagnatori, la maggior parte dei rapporti di errore inviati come risoluzioni delle vulnerabilit\u00e0 non lo sono realmente e devono essere trattati come normali errori. Per distinguere tra vulnerabilit\u00e0 e errori normali \u00e8 stato descritto un modello di minaccia del kernel Linux. Tra le possibilit\u00e0 e le garanzie la cui violazione pu\u00f2 essere considerata una vulnerabilit\u00e0 ci sono: <\/p>\n
\n
Isolamento a livello utente: accesso ai file solo per il proprietario, la memoria del processo non \u00e8 accessibile ad altri utenti, ptrace \u00e8 vietato per i processi di altri, isolamento della IPC e delle comunicazioni di rete.\n
Protezione basata su capabilities: senza CAP_SYS_ADMIN non \u00e8 possibile modificare la configurazione del kernel, la memoria, lo stato del sistema; senza CAP_NET_ADMIN non \u00e8 possibile modificare le impostazioni di rete o intercettare il traffico; senza CAP_SYS_PTRACE non \u00e8 possibile tracciare i processi di altri utenti.\n
Lo spazio dei nomi degli identificatori utente (CONFIG_USER_NS) consente agli utenti non privilegiati di creare i propri ambienti isolati, dai quali non \u00e8 possibile influenzare lo spazio dei nomi globale, ad esempio, modificare l'orario, caricare moduli e montare dispositivi a blocchi.\n
Le interfacce di debug (\/proc\/kmsg, perf, debugfs), attraverso le quali \u00e8 possibile accedere a informazioni sensibili, sono disponibili solo dopo un'esplicita concessione di accesso da parte dell'amministratore. <\/ul>\n
Capacit\u00e0 che non sono considerate vulnerabilit\u00e0: <\/p>\n
\n
Utilizzo di versioni obsolete del kernel.\n
Compilazione con l'attivazione di opzioni per sviluppatori o che riducono la sicurezza (ad esempio, CONFIG_NOMMU).\n
Impostazione di configurazioni sysctl insicure, opzioni della riga di comando, diritti di accesso nel FS, capabilities o apertura di accesso a interfacce privilegiate per utenti non privilegiati (ad esempio, accesso in scrittura a procfs e debugfs).\n
Problemi nelle funzioni destinate solo allo sviluppo e al debug del kernel, come LOCKDEP, KASAN e FAULT_INJECTION, che non sono destinate ad essere incluse nelle configurazioni di produzione.\n
Problemi nei driver, nei moduli e nei sottosistemi nella sezione STAGING o contrassegnati come sperimentali, non sicuri o non funzionanti.\n
Utilizzo di moduli del kernel di terze parti o fork non ufficiali del kernel.\n
Richiesta di privilegi eccessivi, come la necessit\u00e0 di eseguire azioni con i diritti di root o da un utente con privilegi CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO e CAP_SYS_MODULE.\n
Attacchi teorici che richiedono condizioni di laboratorio, miliardi di tentativi, emulazione o modifica dell'hardware, costi sproporzionati e configurazioni non realistiche (ad esempio, sistemi con decine di migliaia di core CPU).\n
Elusione dei meccanismi di protezione (ad esempio, ASLR) senza dimostrazione di exploit. Assenza di controlli sugli argomenti e sui codici di errore restituiti, senza conseguenze ovvie.\n
Fughe di informazioni casuali, non controllabili dagli aggressori, come dati residui nei messaggi di errore e fughe di indirizzi\/punteri della memoria del kernel senza possibilit\u00e0 diretta di sfruttamento.\n
Errori nel montaggio di immagini disco danneggiate, se il driver non \u00e8 dichiarato come idoneo per l'uso con supporti non affidabili. Problemi con le immagini disco identificati e risolti tramite l'esecuzione dell'utilit\u00e0 fsck.\n
Attacchi che richiedono accesso fisico all'hardware, modifica dell'hardware o connessione di dispositivi hardware, come schede per attacchi DMA e analizzatori logici, se il sistema non \u00e8 specificamente configurato per difendersi da tali attacchi (IOMMU).\n
Regressioni nella funzionalit\u00e0 e nelle prestazioni risolvibili tramite la configurazione dei diritti e dei limiti. <\/ul>\n