{"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\/news\/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 accolto nel kernel un documento che regolamenta il processo di gestione degli errori legati alla sicurezza, definisce un modello di minacce, spiega quali errori nel kernel sono considerati vulnerabilit\u00e0 e analizza le azioni sugli errori identificati grazie all'AI. Il documento \u00e8 stato redatto da Willy Tarreau, autore di HAProxy e sviluppatore di lungo corso del kernel Linux, che ha gestito il mantenimento di diversi rami stabili del kernel. Come base sono stati utilizzati gli accordi raggiunti durante la discussione delle 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 creare immediatamente exploit funzionanti. <\/p>\n
Si prevede che la maggior parte degli errori di sicurezza venga gestita pubblicamente, per attrarre il pi\u00f9 ampio pubblico possibile e trovare la soluzione ottimale. Solo i messaggi urgenti sulle vulnerabilit\u00e0 facilmente sfruttabili, che rappresentano una minaccia per molti utenti e consentono di ottenere privilegi o capacit\u00e0 estese, vengono proposti per invio a una lista di distribuzione privata. <\/p>\n
Le vulnerabilit\u00e0 identificate con l'aiuto degli assistenti AI dovrebbero sempre essere discusse pubblicamente, poich\u00e9 tali problemi vengono spesso scoperti contemporaneamente da pi\u00f9 ricercatori. Tuttavia, non \u00e8 necessario rivelare nell'analisi l'exploit \u2014 \u00e8 sufficiente menzionare che \u00e8 disponibile e inviarlo in privato in risposta a una richiesta del responsabile. <\/p>\n
Vengono descritte separatamente le regole per la trasmissione dei rapporti redatti con l'assistenza degli AI. Vengono inviati molti di questi rapporti e grazie a loro si riesce di tanto in tanto a identificare errori in parti di codice poco revisionate, ma gli accompagnatori tendono spesso a ignorarli a causa della bassa qualit\u00e0 e delle imprecisioni. I requisiti principali per i rapporti creati con l'assistenza dell'AI sono: <\/p>\n
\n
Essere concisi, senza fronzoli e con l'indicazione del contenuto e dei dettagli importanti all'inizio.\n
Solo testo semplice senza tag Markdown e decorazioni.\n
Comprendere il modello di minaccia e fornire fatti verificabili (ad esempio, \u00abl'errore consente a qualsiasi utente di ottenere CAP_NET_ADMIN\u00bb), invece di congetture e speculazioni teoriche sugli effetti della vulnerabilit\u00e0.\n
Prima di inviare il rapporto, \u00e8 fondamentale testare accuratamente il funzionamento dell'exploit generato tramite AI e assicurarsi di poter riprodurre il problema.\n
Coinvolgere l'AI per lo sviluppo e il collaudo della correzione del problema identificato. <\/ul>\n
Secondo le statistiche degli accompagnatori, la maggior parte dei rapporti sugli errori inviati come risoluzione delle vulnerabilit\u00e0 non lo \u00e8 realmente e devono essere trattati come errori normali. Per separare le vulnerabilit\u00e0 dagli errori comuni \u00e8 stata descritta una modello di minacce del kernel Linux. Tra le possibilit\u00e0 e garanzie, la cui violazione pu\u00f2 essere considerata una vulnerabilit\u00e0: <\/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 IPC e delle comunicazioni di rete.\n
Protezione basata sulle capacit\u00e0: 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 monitorare i processi di altri utenti.\n
Lo spazio dei nomi degli identificatori degli utenti (CONFIG_USER_NS) consente agli utenti non privilegiati di creare i propri ambienti isolati, dai quali non \u00e8 possibile influenzare l'ambiente globale, ad esempio modificando l'ora, caricando moduli e montando dispositivi a blocchi.\n
Le interfacce di debug (\/proc\/kmsg, perf, debugfs), attraverso le quali \u00e8 possibile accedere a informazioni riservate, sono disponibili solo dopo esplicita concessione di accesso da parte dell'amministratore. <\/ul>\n
Le capacit\u00e0 che non sono considerate vulnerabilit\u00e0: <\/p>\n
\n
Utilizzo di versioni obsolete del kernel.\n
Compilazione con l'inclusione di opzioni per sviluppatori o riduttive per la sicurezza (ad esempio, CONFIG_NOMMU).\n
Impostazioni sysctl non sicure, opzioni della riga di comando, permessi nel FS, capacit\u00e0 o concessione di accesso a interfacce privilegiate a utenti non privilegiati (ad esempio, accesso in scrittura a procfs e debugfs).\n
Problemi nelle funzioni destinate esclusivamente allo sviluppo e al debug del kernel, come LOCKDEP, KASAN e FAULT_INJECTION, che non sono destinate a essere incluse nelle configurazioni di lavoro.\n
Problemi nei driver, moduli e sottosistemi presenti nella sezione STAGING o contrassegnati come sperimentali, non sicuri o non funzionanti.\n
Uso di moduli del kernel di terze parti o fork del kernel non ufficiali.\n
Richiesta di privilegi eccessivi, come la necessit\u00e0 di eseguire azioni con diritti root o da parte di un utente con diritti 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 irrealistiche (ad esempio, sistemi con decine di migliaia di core CPU).\n
Evasione dei meccanismi di protezione (ad esempio, ASLR) senza dimostrazione di exploit. Mancanza di controlli sugli argomenti e sul codice di errore restituito, privi di conseguenze evidenti.\n
Fughe casuali di informazioni, fuori dal controllo degli aggressori, come dati residui nei messaggi di errore e fughe di indirizzi\/puntatori della memoria del kernel senza possibilit\u00e0 diretta di sfruttamento.\n
Errori nel montaggio di immagini disco danneggiate, se il driver non \u00e8 dichiarato idoneo per l'uso con supporti non affidabili. Problemi con le immagini disco identificabili e risolvibili avviando l'utility fsck.\n
Attacchi che richiedono accesso fisico all'hardware, modifica dell'hardware o collegamento di dispositivi hardware, come schede per attacchi DMA e analizzatori logici, se il sistema non \u00e8 specificamente configurato per proteggersi contro tali attacchi (IOMMU).\n
Regressioni nella funzionalit\u00e0 e nelle prestazioni, risolvibili configurando diritti e limiti. <\/ul>\n