Perché le patch di grsecurity non sono incluse nel kernel Vanilla?


22

Quali sono i motivi per cui le grsecuritypatch (o le funzionalità di sicurezza che porta) non sono incluse nel kernel per impostazione predefinita. Quando si considerano i vantaggi per la sicurezza, sembra che il kernel vanilla sia piuttosto insicuro.

Se si tratta di un compromesso (alcune applicazioni in cui si desidera evitare le misure di sicurezza), grsecuritypotrebbe essere un'opzione da abilitare nel kernel vanilla.

Con così tante cose nel mainstream kernel vanilla, faccio fatica a capire i motivi per cui la community non vuole includere grsecurity.


Sembra essere un problema politico. Sembra che Torvalds pensi che alcune delle loro patch siano spazzatura. Vedi anche Qualys Security Advisory - Le vulnerabilità di Stack Clash e More CONFIG_VMAP_STACK, refcount_t UAF e un metodo di bypass / rootkit Secure Boot ignorato nella mailing list di OSS-Security.

Dai precedenti suggerimenti sulle mailing list crittografiche del kernel, io e gli altri siamo stati messi nel secchio etichette Torvalds "insane". Quindi non sono solo le persone di gresecurity ad affrontare il problema. Vedi anche random: avvisi del compilatore di silenzio e correzione di gara . Il thread è una discussione sulla fornitura di un dmesg per i driver che usano {u} in modo casuale prima che sia pronto. (Potresti non saperlo, ma un certo numero di driver usa i dispositivi prima che siano correttamente seminati. Cfr. Systemd legge da urandom prima dell'inizializzazione )

Risposte:


23

(Sono uno sviluppatore grsecurity.)

La risposta di jsbillings si basa su un post e-mail discusso in un articolo LWN .

Il contesto importante qui è che né grsecurity né gli sviluppatori PaX sono stati coinvolti in quella discussione sulla mailing list. Il commento del team PaX all'articolo LWN lo chiarisce. Non abbiamo mai inviato le patch per l'inclusione su mainline. Una semplice ragione è che siamo noi quelli con le idee e le implementazioni, che a monte non risolverebbe. Inoltre, dovremmo impegnarci in noiose discussioni sulla mailing list con un gruppo di sviluppatori che sono molto anti-sicurezza (vedi la mia presentazione H2HC del 2012per ulteriori discussioni su questo). Abbiamo tempo e risorse limitati, quindi scegliamo di spenderlo nel modo più efficace possibile: creare la tecnologia di sicurezza di domani e renderla disponibile a tutti gratuitamente. Come menziona il team PaX nel loro commento, abbiamo una visione particolarmente ampia della sicurezza e quindi non crediamo che ci sia molto merito nella divisione e upstream delle singole funzionalità.


Mi è piaciuto il link all'interessante articolo LWN. Grazie. Sono ancora in uno stato di confusione per leggere l'opinione che un gruppo di sviluppatori del kernel sarebbe "molto anti-sicurezza". Naturalmente non ho alcun tipo di intuizione, ma questo sembra preoccupante :(. La confusione è che presumo la sicurezza uno degli "argomenti più forti" per OpenSource e Linux. Al momento mi sento abbastanza minacciato sul mio sistema basato su Ubuntu. Rimanere un po 'indietro, quale sarebbe "più occhi possono guardare" - sicurezza del sistema operativo se fossimo ignoranti? Mi piace comunque la sicurezza, grazie per questo.
umanità e

10

Sembra che gli sviluppatori di grsecurity abbiano avuto problemi in passato convincendo Linus ad accettare cambiamenti nel kernel. I problemi sembrano essere:

  1. Invio di una gigantesca goccia di codice e non frammentazione
  2. Linus considera molti dei cambiamenti "pazzi", il che probabilmente è il modo in cui Linus afferma che non funziona con i suoi piani per lo sviluppo futuro.

Questi sono alcuni punti interessanti. Sto ancora imparando: non ero nemmeno a conoscenza del BLOB (che è una cosa di dati binari, giusto, qualcosa che non è open source immagino). Bene, l'informazione è buona. Se i motivi indicati sono veri, è ancora un peccato. Mi piace l'idea del miglioramento della sicurezza correlata al patchset di grsecurity.
umanità e

1
@humanityANDpeace "blob" può significare "oggetto binario di grandi dimensioni" (di solito nel senso del database, ma a volte anche altrove), oppure può essere gergale per "grosso pezzo di qualunque cosa". In questo caso, lo prendo jsbillings significava quest'ultimo: un grosso pezzo di codice sorgente che non è ulteriormente suddiviso. Essendo un programmatore, so esattamente quanto possano essere frustranti lavorare con loro, per non parlare della recensione.
un CVn il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.