Linux suporta a tecnologia NX de proteção contra código malicioso

Deixa ver se entendi.

Certos processadores estão vindo com registros internos que demarcam a área que programas executáveis tem direito de usar.Deixando estas áreas para o kernel.
Desta forma não poderá ocorrer invasão de espaços de memória por programas maliciosos que se aproveitam de falhas no kernel.
Bom, acho que não elimina problemas com executáveis que possuam exploits, pois programas podem se aproveitar de falhas em programas com SUID e bagunçar tudo.
Seria bom somente para o Kernel se manter "indestrutível".
Certo ?

Não, é bem mais que isso. Ataques baseados na inserção e execução de código através de buffer overflows contra aplicativos ou daemons também ficam bastante prejudicados.

Ou seja, uma boa solução para firewalls, ou soluções que se utilizem de funçoes do kernel exclusivamente.

Não, Daniel. A solução não selimita às funções do kernel. Ela protege aplicativos e outros softwares em execução, indistintamente.

Ou seja, uma boa solução para firewalls, ou soluções que se utilizem de funçoes do kernel exclusivamente.
Não sei como a Mircosoft se beneficia disto...

Querem apostar que a implementação do Windows vai vir com um bug, que sera descoberto logo em seguida e que poderá gerar virus ainda mais poderosos. Não sei como isso será possível tecnicamente, mas a MS vai conseguir ferrar.

Não, Daniel. A solução não selimita às funções do kernel. Ela protege aplicativos e outros softwares em execução, indistintamente.

Mas então os tais registros tem que ter informações sobre estes programas em execução, que então será repassada pelo kernel ao tal registro NX.
Reservando as áreas de memória destes programas podem se tornar seguros, retiro o que disse.

Não Daniel, na verdade é bem mais simples. O que ocorre é que ao alocar as áreas de dados, por requisição ou necessidade de qualquer programa, o kernel já irá marcá-las (por default) com a flag NX, e aí nada poderá ser executado nestas áreas.

É simples, elegante, independente de alterações nas camadas superiores (exceto em aplicações que executem código na sua área de dados, o que é em si um problema sério de projeto), e pode funcionar bem em qualquer sistema operacional ou aplicação.

Aqui tem um pouco mais de explicações técnicas sobre como funciona: http://www.linuxelectrons.com/article.php/20040606105136214

Só falta agora alguém patentear e cobrar de alguém o invento.
Entendo que há proteções e mesmo legislações que protejam este tipo de situação, mas as leis de patentes(ou a sua burocracia) são absurdas e vergonhosas.
Desculpe por fugir do assunto.

Tá desculpado... inclusive por fugir do assunto :)

Bom agora acho que entendi.
Toda a área de dados de um programa pode ser invadida por um código malicioso em tipos de ataque Buffer overflow ou outros se esta área não tiver uma proteção do tipo PROT-EXEC(Proteção para executar).
Foi implementado em alguns processadores um bit de paginação de memória que define a área como executável ou não, ou seja o processador não executa nenhuma instrução nestas áreas mapeadas.
O kernel neste caso que estiver com esta função ao carregar um programa seta os bits mapeando áreas específicas para a execução de programas e de trabalho com dados, não impedindo que estas áreas sejam invadidas por falhas do programa mas impedindo que sejam executados os dados dentro destas áreas.
Engraçado é que o próprio programa deve repassar ao kernel quais áreas são de dados e de execução, o que não é muito seguro, ou estou errado ?
É mais difícil do que parece :-).

Não, Daniel, o programa não precisa repassar nada além do que já repassa hoje.

Abraços
Augusto

Exatamente.
Se ocorrer algum erro de programação talvez possa ocorrer de algumas áreas que o programa requisita para trabalhar com dados se fundirem com as áreas de execução.
Falhas e bugs no kernel nas funções de carregamento de programas podem também gerar este tipo de situação.
Claro que depende de falhas humanas, o que não é muito incomum.

Então teria que arrumar uma maneira de fazer o kernel "desmarcar" essas flags para ai sim inserir o código executável. Seria isso mesmo ou viajei na maionese ?

É, de fato, se o programa ativamente marcar como sendo de código uma área que é para ser de dados, acredito que a solução do NX não vá resolver o problema. Mas aí nada mais solucionaria também. Não entendi bem qual é o teu ponto.

Acho que não.
Se estou entendendo bem pode ocorrer situações do tipo:
Kernel aloca enderços 111ff - eeeff para execução e aloca digamos aaaff - bbbff para área de dados.
Ou seja áreas fundidas, sem flags de proteção para execução.
Ou mesmo algum bug na função de carregamento do kernel pode realizar este procedimento.
O que no caso permitiria a inserção de códigos maliciosos.

Tudo bem, ainda que exista a possibilidade de falhas: qual teu ponto?

Na situação atual, não existe proteção contra execução nestas áreas. Na situação nova, existe, e vai funcionar na absoluta maioria dos casos, segundo os desenvolvedores.

Tu está criticando a adoção da solução, está propondo alguma outra, ou está só comentando sobre o quanto o mundo poderia ser mais perfeito? :-)

Abraços
Augusto

Não tem ponto, só contra-ponto :-).
Acho que destrinchamos bem a solução para o pessoal e eu entender.
Acho esta área no limite do hardware e do software o meu maior interesse.
Sem mais.

Sinceramente, vocês respeitam os desenvolvedores da M$ como profissionais de verdade? Eu não, afinal, como uma empressa consegue fazer programas de nível tão ruim se tem um nível de profissionais elevado? Talvez o cache seja elevado mas o domínio deles...

Quem pode ajudar na demarcação das regiões de memória é o compilador ou o interpretador. Ele demarca a que tipos regiões de memória certos dados devem ser alocados, como dados e código.

As regiões de dados (como strings estáticas, região de memória heap e assemelhados) não tem permissão de execução (e não vejo porque mudar isso em runtime), com acesso do tipo "rw-"

As regiões de código óbviamente têm este acesso o acesso "r-x".

Isso é uma beleza.
Este recurso já existe a algum temponos processadores, mas nenhum SO ainda havia feito uso dele.
É uma grande ajuda na proteção contra falhas nos programas, basta que as áreas de memória sejam corretamente demarcadas e será extremamente díficil um evento externo inexperado bagunçar as coisas.

Isso é mais uma prova do potencial do OpenSource, mais uma vez o LINUX sai na frente com inovações de segurança.