Por que os patches grsecurity não estão incluídos no Vanilla Kernel?

22

Quais são os motivos pelos quais os grsecuritypatches (ou os recursos de segurança que ele traz) não são incluídos no kernel por padrão. Ao analisar os benefícios de segurança, parece que o kernel da baunilha é bastante inseguro.

Se for um trade-off (alguns aplicativos em que você deseja evitar as medidas de segurança), parece que grsecuritypode ser uma opção a ser ativada no kernel vanilla.

Com tantas coisas no kernel básico da baunilha, tenho dificuldade em entender as razões pelas quais a comunidade não deseja incluir grsecurity.

linux kernel grsecurity

— humanidade e paz
fonte

Parece ser um problema político. Parece que Torvalds acha que alguns de seus remendos são lixo. Consulte também Qualys Security Advisory - The Stack Clash e mais vulnerabilidades CONFIG_VMAP_STACK, refcount_t UAF e um método ignorado de desvio / rootkit do Secure Boot ignorado na lista de discussão OSS-Security.

Das sugestões anteriores nas listas de discussão sobre criptografia do kernel, eu e outras pessoas fomos colocadas no balde dos rótulos de Torvalds "insanos". Portanto, não são apenas as pessoas que enfrentam o problema. Veja também aleatório: silencie os avisos do compilador e corrija a corrida . O tópico é uma discussão sobre o fornecimento de um dmesg para drivers que usam {u} aleatoriamente antes de estarem prontos. (Você pode não saber, mas um número de motoristas a usar os dispositivos antes de serem devidamente semeado Cf.. Systemd lê urandom antes da inicialização )

23

(Sou desenvolvedor de segurança grossa.)

A resposta de jsbillings é baseada em uma postagem de email discutida em um artigo do LWN .

O contexto importante aqui é que nem grsecurity nem desenvolvedores de PaX estavam envolvidos nessa discussão da lista de discussão. O comentário da equipe PaX ao artigo do LWN esclarece isso. Nunca enviamos os patches para inclusão na linha principal. Uma razão simples é que somos nós que temos as idéias e implementações, que o upstreaming não resolveria. Além disso, teríamos que nos envolver em argumentos cansativos da lista de discussão com um grupo de desenvolvedores que são muito anti-segurança (veja minha apresentação do H2HC de 2012para mais discussão sobre isso). Como dispomos de tempo e recursos limitados, escolhemos gastá-lo da maneira mais eficaz possível: criando a tecnologia de segurança de amanhã e disponibilizando-a gratuitamente a todos. Como a equipe PaX menciona em seu comentário, temos uma visão abrangente abrangente de segurança e, portanto, não acreditamos que haja muito mérito na divisão e otimização de recursos individuais.

— Brad Spengler
fonte

Gostei do link para o interessante artigo do LWN. Obrigado. Ainda estou confuso ao ler a opinião de que um grupo de desenvolvedores do Kernel seria "muito anti-segurança". É claro que não tenho nenhum tipo de insight, mas isso parece preocupante :(. A confusão é que assumo a segurança um dos "argumentos mais fortes" para OpenSource e Linux. No momento, sinto-me bastante ameaçado no meu sistema baseado no ubuntu. continuam a ser um pouco deixado para trás com, o que seria "mais olhos pode olhar" -Segurança de OS werth se fôssemos ignorante eu como grsecurity de qualquer forma, obrigado por isso?.

— humanityANDpeace

10

Parece que os desenvolvedores da grsecurity tiveram problemas no passado convencendo Linus a aceitar alterações no kernel. Os problemas parecem ser:

Enviar um blob gigante de código e não dividi-lo em pedaços
Linus considera muitas das mudanças "insanas", o que provavelmente é a maneira de Linus dizer que não funciona com seus planos de desenvolvimento futuro.

— jsbillings
fonte

Estes são alguns pontos interessantes. Ainda aprendendo - eu nem estava ciente do BLOB (isso é uma coisa de dados binários, certo, algo que não é de código aberto, eu acho). Bem, a informação é boa. Se as razões expostas forem verdadeiras, ainda é uma pena. Gosto da ideia da melhoria de segurança relacionada ao patchset grsecurity.

— Humanandpeace

1

@humanityANDpeace "blob" pode significar "objeto grande binário" (geralmente no sentido de banco de dados, mas às vezes também em outros lugares), ou pode ser uma gíria para "grande parte de qualquer coisa". Nesse caso, considero que jsbillings significava o último: um grande pedaço de código-fonte que não é mais subdividido. Sendo eu mesmo programador, sei exatamente como isso pode ser frustrante, sem falar na revisão.

— um CVn