Publiquei na internet minha monografia de conclusão da pós-graduação em Gerência e Segurança de Redes de Computadores. A monografia aborda o uso de SELinux para aumentar a segurança de servidores Linux. Como não encontrei muita documentação em português sobre SELinux, caso tenha interesse em ler poderá acessá-la em:
http://jczucco.blogspot.com/2010/06/monografia-sobre-selinux.html
sábado, abril 26, 2008
terça-feira, abril 08, 2008
terça-feira, março 25, 2008
Resolvendo problemas do wine com winetricks
Winetricks é um script que realiza download e instalação automática de várias bibliotecas, fontes e codecs que algumas vezes são necessárias para execução de programas windows através do wine.
Esse script muito útil pode ser obtido aqui: http://wiki.winehq.org/winetricks
Esse script muito útil pode ser obtido aqui: http://wiki.winehq.org/winetricks
quarta-feira, março 19, 2008
SELinux disponível para o Ubuntu 8.04 - “Hardy Heron”
A partir da versão do Ubuntu 8.04, você pode optar por usar AppArmor ou SELinux.
O AppArmor continua sendo a opção padrão na instalação. Apesar de o projeto SELinux ser aberto e independente de distribuição, frequentemente o seu uso é associado com algumas distribuições, como Fedora, Red Hat, etc. A adoção do SELinux pelo Ubuntu irá ajudar a sua popularização e a dispersar esses mitos, incluindo o que diz que o SELinux é difícil de usar.
Para remover o AppArmor e instalar o SELinux, basta dar o seguinte comando:
sudo aptitude install selinux
Para maiores detalhes:
How To Install SELinux on Ubuntu 8.04 “Hardy Heron”
O AppArmor continua sendo a opção padrão na instalação. Apesar de o projeto SELinux ser aberto e independente de distribuição, frequentemente o seu uso é associado com algumas distribuições, como Fedora, Red Hat, etc. A adoção do SELinux pelo Ubuntu irá ajudar a sua popularização e a dispersar esses mitos, incluindo o que diz que o SELinux é difícil de usar.
Para remover o AppArmor e instalar o SELinux, basta dar o seguinte comando:
sudo aptitude install selinux
Para maiores detalhes:
How To Install SELinux on Ubuntu 8.04 “Hardy Heron”
segunda-feira, março 10, 2008
Vídeos sobre SELinux
Se você quer saber mais sobre SELinux, uma forma rápida é assistir esses vídeos para ter uma idéia do poder que ele dá ao administrador. Os vídeos abordam a administração básica do SELinux, e demonstra uma das proteções aplicadas ao servidor apache.
SELinux Permissive mode intro
Use chcon in SELinux to alter security context for Apache
Peruse the targeted SELinux policy
SELinux Permissive mode intro
Use chcon in SELinux to alter security context for Apache
Peruse the targeted SELinux policy
sábado, fevereiro 23, 2008
Mais vídeos sobre segurança na Red Hat Magazine
Mark Cox - líder do Red Hat Security Response Team - fala sobre problemas de segurança, políticas de atualizações na RHN, e dicas para manter o Linux mais seguro.
Episode 1: The Vendor
Episode 2: Policies
Episode 3: Tips for a secure system
Episode 4: Security issues and metrics
Fonte: Red Hat Magazine
Episode 1: The Vendor
Episode 2: Policies
Episode 3: Tips for a secure system
Episode 4: Security issues and metrics
Fonte: Red Hat Magazine
sexta-feira, fevereiro 22, 2008
quarta-feira, fevereiro 06, 2008
SELinux Slogans
Post muito engraçado (ou não, depende do seu ponto de vista) feito por Spencer Shimko em http://beyondabstraction.net/2008/01/10/selinux-slogans
- SELinux - Because users do weird shit.
- SELinux - Fuck root.
- SELinux - Hampering administrators since before it was cool.
- SELinux - High-security gone haywire.
- SELinux - Turning it off is like removing the batteries from a smoke detector. Sure it sounds better but you might get burned.
- SELinux - Because life is too simple.
- SELinux - AppArmor sucks.
- SELinux - It’s too early in the morning to be cleaning up after 11-year old kiddies.
- SELinux - Too powerful for our own good.
- SELinux - Here’s our root password, what’s yours?
- SELinux - Didn’t they teach you about using protection in high-school?
- SELinux - Blind faith not required
- SELinux will save you tons of money, your TCO will go down and your ROI will go up.
- SELinux supports 3-letter acronyms out of the box, no complex policy changes required.
- Zero day vulnerabilities are a fact. Do something about it.
- Trusted Solaris has been end-of-lifed and you’re not in the government space to begin with.
- Path-named based access control is weak.
- Implicitly trusting admins doesn’t have to be SOP.
- You’re not a security expert, let us do the hard work.
- The US military (and others) trust SELinux with their information, shouldn’t you?
quarta-feira, janeiro 30, 2008
Desenvolvedor do AppArmor é contratado pela Microsoft
Crispin Cowan, desenvolvedor do AppArmor e ex-funcionário da Novell foi contratado pela Microsoft [1]. (Observação: a equipe desenvolvedora do AppArmor foi demitida pela Novell em outubro de 2007 sem muitas explicações [2], e Crispin criou a Mercenary Linux [3] para dar continuidade ao desenvolvimento do AppArmor).
Além de colocar em dúvida a continuidade do desenvolvimento do AppArmor, esse fato impediu que Crispin Cowan desse sua palestra na LinuxConf Austrália desse ano. Crispin havia convidado o desenvolvedor do SELinux Russel Coker para um debate público que iria expor as diferenças das duas tecnologias, o qual Russel não aceitou [4]. Como Crispin nem ninguém compareceu para substituí-lo, a palestra iria ser cancelada, quando Russel se ofereceu para falar sobre SELinux, e sua palestra foi muito bem recebida [5].
Qual será agora o futuro do AppArmor? O Suse Linux e mais recentemente, o Ubuntu Linux ainda continuarão usando essa tecnologia? Pelo menos já existem esforços para que o SELinux seja portado para Ubuntu pela equipe Ubuntu-Hardened [6].
Referências:
[1]: http://blogs.msdn.com/michael_howard/archive/2008/01/17/crispin-cowan-joins-the-windows-security-team.aspx
[2]: http://www.heise.de/english/newsticker/news/97383/from/rss09
[3]: http://www.mercenarylinux.com
[4]: http://linux.conf.au/programme/detail?TalkID=210
[5]: http://etbe.coker.com.au/2008/01/30/my-lca-talk
[6]: https://wiki.ubuntu.com/HardySELinux
Além de colocar em dúvida a continuidade do desenvolvimento do AppArmor, esse fato impediu que Crispin Cowan desse sua palestra na LinuxConf Austrália desse ano. Crispin havia convidado o desenvolvedor do SELinux Russel Coker para um debate público que iria expor as diferenças das duas tecnologias, o qual Russel não aceitou [4]. Como Crispin nem ninguém compareceu para substituí-lo, a palestra iria ser cancelada, quando Russel se ofereceu para falar sobre SELinux, e sua palestra foi muito bem recebida [5].
Qual será agora o futuro do AppArmor? O Suse Linux e mais recentemente, o Ubuntu Linux ainda continuarão usando essa tecnologia? Pelo menos já existem esforços para que o SELinux seja portado para Ubuntu pela equipe Ubuntu-Hardened [6].
Referências:
[1]: http://blogs.msdn.com/michael_howard/archive/2008/01/17/crispin-cowan-joins-the-windows-security-team.aspx
[2]: http://www.heise.de/english/newsticker/news/97383/from/rss09
[3]: http://www.mercenarylinux.com
[4]: http://linux.conf.au/programme/detail?TalkID=210
[5]: http://etbe.coker.com.au/2008/01/30/my-lca-talk
[6]: https://wiki.ubuntu.com/HardySELinux
sexta-feira, janeiro 04, 2008
Wireless Intel 3945ABG no Fedora 8
Apesar de o Fedora 8 reconhecer na instalação a placa de rede wireless Intel 3945, ela não funciona imediatamente assim como no Ubuntu, é preciso fazer uma configuração para que ela funcione.
Primeiro, para verificar se o Fedora reconheceu corretamente a placa de rede wireless, os seguintes comandos devem ter resultados como esse:
# lspci | grep Wireless
02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
# rpm -qa | grep 3945
iwl3945-firmware-2.14.1.5-2
# dmesg | grep 3945
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.1.19kds
iwl3945: Copyright(c) 2003-2007 Intel Corporation
iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels
Agora a dica que faz a placa funcionar:
O arquivo /etc/modprobe.conf deve possuir as seguintes entradas:
alias wlan0 iwl3945
options iwl3945 disable_hw_scan=0
A segunda entrada "options iwl3945 disable_hw_scan=0" é que resolveu o problema do meu notebook. Caso você esteja com o mesmo problema, espero que essa dica lhe ajude como me ajudou. :-)
Depois de editar o arquivo /etc/modprobe.conf, basta reiniciar o linux e configurar a rede wireless normalmente.
Primeiro, para verificar se o Fedora reconheceu corretamente a placa de rede wireless, os seguintes comandos devem ter resultados como esse:
# lspci | grep Wireless
02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
# rpm -qa | grep 3945
iwl3945-firmware-2.14.1.5-2
# dmesg | grep 3945
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.1.19kds
iwl3945: Copyright(c) 2003-2007 Intel Corporation
iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels
Agora a dica que faz a placa funcionar:
O arquivo /etc/modprobe.conf deve possuir as seguintes entradas:
alias wlan0 iwl3945
options iwl3945 disable_hw_scan=0
A segunda entrada "options iwl3945 disable_hw_scan=0" é que resolveu o problema do meu notebook. Caso você esteja com o mesmo problema, espero que essa dica lhe ajude como me ajudou. :-)
Depois de editar o arquivo /etc/modprobe.conf, basta reiniciar o linux e configurar a rede wireless normalmente.
sábado, dezembro 08, 2007
Tipos de Políticas de Segurança SELinux
- Política Strict:
Um sistema que usa a política de segurança strict é aquele onde tudo é negado por padrão, é nescessário habilitar regras na política de segurança para cada tarefa que cada aplicação ou processo irá realizar. O SELinux foi concebido originalmente para atender à política strict, pois as políticas são somente de permissão e não de bloqueio.
Para um sistema generalista como é o Linux, atender ao uso de uma política strict é uma grande e complexa tarefa. As primeiras experiências de uso da política strict no sistema operacional Linux foram na distribuição Fedora Core versão 2, onde a política era desabilitada por padrão. Esse novo recurso causou curiosidade em muitos administradores de sistemas, que por desejo de tornar o seu sistema mais seguro, habilitaram o uso da política strict durante a instalação. Como a política strict ainda não era madura o suficiente para seu uso em sistemas comerciais (o Linux Fedora Core é uma distribuição usada pela Red Hat para testar novos recursos e amadurecimento de versões de aplicações para depois então serem aplicados no Red Hat Linux) e não atendia todos os programas disponíveis na distribuição Fedora, acabaram ocorrendo muitos problemas em seu uso, e esse deve ter sido o fato que motivou a "má fama" que o SELinux ganhou de ser um sistema muito complexo, que apenas trazia mais problemas para serem contornados pelos administradores de sistemas, tanto que a principal pergunta em fóruns de internet sobre segurança e SELinux da época era: "Como desabilito o SELinux?" [1]
Desde então muita coisa mudou no SELinux até os dias atuais, pois hoje a política strict se mostra utilizável em sistemas Linux para muitos casos. Os incidentes ocorridos nas distribuições Fedora 2 levaram a criação de uma nova política de segurança SELinux, a targeted, e a criação de um novo domínio chamado unconfined_t. [2]
- Política Targeted:
Através da política targeted, cada sujeito e objeto roda em um domínio chamado unconfined_t exceto alguns serviços alvos que possuem políticas pré-definidas. Objetos que estão no domínio unconfined_t não possuem restrições e usam a segurança Linux padrão (DAC), ou seja, rodam como se não existisse o SELinux para realizar os controles de segurança. Os serviços que fazem parte da política targeted rodam em seus próprios domínios e são restritos à política para cada operação que realizam no sistema, dessa forma se esses serviços forem comprometidos ou de alguma maneira explorados por suas vulnerabilidades, os danos são limitados e até mesmo podem ser controlados.
Como exemplo, o servidor web apache é protegido pela política targeted, e não poderá comprometer os outros serviços do sistema, como servidor de nomes, servidor ssh, arquivos privados de usuários, etc, conforme a política pré-definida. No formato padrão DAC, isso não acontece, um bom exemplo disso é a vulnerabilidade no aplicativo gerenciador de conteúdo web chamado Mambo, que na versão 4.0.14 é vulnerável ao ataque descrito na CVE-2005-3738 [3]. O SELinux é capaz de limitar esse ataque a ponto de torná-lo inútil. [4]
A política targeted é a padrão na maioria das distribuições Linux que usam SELinux, como Fedora 3 ou superior e Red Hat 4 ou superior.
OBS: Na versão 8 do Fedora Core Linux lançada em novembro de 2007, que é a distribuição Linux onde a maioria do desenvolvimento do SELinux é realizada e são propostos e implementados novos recursos e várias mudanças, a política strict deixou de existir como uma política totalmente isolada da política targeted, foi criada uma política híbrida onde tanto a política targeted quanto a strict é utilizada. No Fedora 8 é possível usar a política strict por usuário, adicionando o usuário em um domínio strict (domínio guest ou xguest, por exemplo), e esse usuário estará com limitações de acessos como era antigamente usando-se a política strict. Por padrão, os usuários serão criados ainda no domínio unconfined_t. Para remover totalmente a habilidade de processos executarem no domínio unconfined_t, pode-se remover o módulo unconfined com o comando "semodule -r unconfined". [5]
No próximo post, comentarei sobre políticas MLS e MCS no SELinux.
Referências:
[1]: http://selinux-symposium.org/2005/presentations/session4/4-1-walsh.pdf
[2]: http://danwalsh.livejournal.com/9031.html
[3]: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3738
[4]: http://www.linuxjournal.com/article/9176
[5]: http://fedoraproject.org/wiki/Interviews/SELinux
Um sistema que usa a política de segurança strict é aquele onde tudo é negado por padrão, é nescessário habilitar regras na política de segurança para cada tarefa que cada aplicação ou processo irá realizar. O SELinux foi concebido originalmente para atender à política strict, pois as políticas são somente de permissão e não de bloqueio.
Para um sistema generalista como é o Linux, atender ao uso de uma política strict é uma grande e complexa tarefa. As primeiras experiências de uso da política strict no sistema operacional Linux foram na distribuição Fedora Core versão 2, onde a política era desabilitada por padrão. Esse novo recurso causou curiosidade em muitos administradores de sistemas, que por desejo de tornar o seu sistema mais seguro, habilitaram o uso da política strict durante a instalação. Como a política strict ainda não era madura o suficiente para seu uso em sistemas comerciais (o Linux Fedora Core é uma distribuição usada pela Red Hat para testar novos recursos e amadurecimento de versões de aplicações para depois então serem aplicados no Red Hat Linux) e não atendia todos os programas disponíveis na distribuição Fedora, acabaram ocorrendo muitos problemas em seu uso, e esse deve ter sido o fato que motivou a "má fama" que o SELinux ganhou de ser um sistema muito complexo, que apenas trazia mais problemas para serem contornados pelos administradores de sistemas, tanto que a principal pergunta em fóruns de internet sobre segurança e SELinux da época era: "Como desabilito o SELinux?" [1]
Desde então muita coisa mudou no SELinux até os dias atuais, pois hoje a política strict se mostra utilizável em sistemas Linux para muitos casos. Os incidentes ocorridos nas distribuições Fedora 2 levaram a criação de uma nova política de segurança SELinux, a targeted, e a criação de um novo domínio chamado unconfined_t. [2]
- Política Targeted:
Através da política targeted, cada sujeito e objeto roda em um domínio chamado unconfined_t exceto alguns serviços alvos que possuem políticas pré-definidas. Objetos que estão no domínio unconfined_t não possuem restrições e usam a segurança Linux padrão (DAC), ou seja, rodam como se não existisse o SELinux para realizar os controles de segurança. Os serviços que fazem parte da política targeted rodam em seus próprios domínios e são restritos à política para cada operação que realizam no sistema, dessa forma se esses serviços forem comprometidos ou de alguma maneira explorados por suas vulnerabilidades, os danos são limitados e até mesmo podem ser controlados.
Como exemplo, o servidor web apache é protegido pela política targeted, e não poderá comprometer os outros serviços do sistema, como servidor de nomes, servidor ssh, arquivos privados de usuários, etc, conforme a política pré-definida. No formato padrão DAC, isso não acontece, um bom exemplo disso é a vulnerabilidade no aplicativo gerenciador de conteúdo web chamado Mambo, que na versão 4.0.14 é vulnerável ao ataque descrito na CVE-2005-3738 [3]. O SELinux é capaz de limitar esse ataque a ponto de torná-lo inútil. [4]
A política targeted é a padrão na maioria das distribuições Linux que usam SELinux, como Fedora 3 ou superior e Red Hat 4 ou superior.
OBS: Na versão 8 do Fedora Core Linux lançada em novembro de 2007, que é a distribuição Linux onde a maioria do desenvolvimento do SELinux é realizada e são propostos e implementados novos recursos e várias mudanças, a política strict deixou de existir como uma política totalmente isolada da política targeted, foi criada uma política híbrida onde tanto a política targeted quanto a strict é utilizada. No Fedora 8 é possível usar a política strict por usuário, adicionando o usuário em um domínio strict (domínio guest ou xguest, por exemplo), e esse usuário estará com limitações de acessos como era antigamente usando-se a política strict. Por padrão, os usuários serão criados ainda no domínio unconfined_t. Para remover totalmente a habilidade de processos executarem no domínio unconfined_t, pode-se remover o módulo unconfined com o comando "semodule -r unconfined". [5]
No próximo post, comentarei sobre políticas MLS e MCS no SELinux.
Referências:
[1]: http://selinux-symposium.org/2005/presentations/session4/4-1-walsh.pdf
[2]: http://danwalsh.livejournal.com/9031.html
[3]: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3738
[4]: http://www.linuxjournal.com/article/9176
[5]: http://fedoraproject.org/wiki/Interviews/SELinux
domingo, dezembro 02, 2007
Quais são os objetivos de uso do SELinux?
O uso do SELinux tem por objetivos de segurança primários:
- Isolamento das aplicações: buscando o nível do menor privilégio no uso de aplicações, um problema de segurança em uma aplicação isolada (como bugs, vulnerabilidades e zero-days) não influencia o sistema como um todo, não comprometendo o funcionamento das outras aplicações e diminuindo o efeito da exploração de vulnerabilidades, limitando a propagação de erros;
- Fluxo de informações: garantia de que a informação deve seguir caminhos pré-definidos para acesso entre os processos;
- Confidencialidade: a informação não estará disponível ou será divulgada a indivíduos, entidades ou processos sem a devida autorização;
- Integridade: disponibilidade de informações confiáveis, corretas e dispostas em formato compatível com o de sua utilização. A informação manipulada mantém todas as características originais estabelecidas pelo proprietário da informação, incluindo controle de mudanças e garantia do seu ciclo de vida (nascimento,manutenção e destruição).
- Auto-proteção: como o SELinux é aplicado diretamente sobre o kernel do Linux, além de proteger as políticas ele também tem por objetivo proteger o próprio sistema operacional (binários, configurações, recursos, etc) para se auto proteger;
- Menor privilégio: garante que as políticas aplicadas estão corretas e de que os processos possuem apenas o acesso nescessário para realizar a sua função, e nada mais do que isso;
- Separação de papéis: definição das permissões de usuários e processos para evitar a elevação de privilégios e suas consequências.
- Isolamento das aplicações: buscando o nível do menor privilégio no uso de aplicações, um problema de segurança em uma aplicação isolada (como bugs, vulnerabilidades e zero-days) não influencia o sistema como um todo, não comprometendo o funcionamento das outras aplicações e diminuindo o efeito da exploração de vulnerabilidades, limitando a propagação de erros;
- Fluxo de informações: garantia de que a informação deve seguir caminhos pré-definidos para acesso entre os processos;
- Confidencialidade: a informação não estará disponível ou será divulgada a indivíduos, entidades ou processos sem a devida autorização;
- Integridade: disponibilidade de informações confiáveis, corretas e dispostas em formato compatível com o de sua utilização. A informação manipulada mantém todas as características originais estabelecidas pelo proprietário da informação, incluindo controle de mudanças e garantia do seu ciclo de vida (nascimento,manutenção e destruição).
- Auto-proteção: como o SELinux é aplicado diretamente sobre o kernel do Linux, além de proteger as políticas ele também tem por objetivo proteger o próprio sistema operacional (binários, configurações, recursos, etc) para se auto proteger;
- Menor privilégio: garante que as políticas aplicadas estão corretas e de que os processos possuem apenas o acesso nescessário para realizar a sua função, e nada mais do que isso;
- Separação de papéis: definição das permissões de usuários e processos para evitar a elevação de privilégios e suas consequências.
sábado, novembro 24, 2007
SELinux vs chroot
Uma questão frequentemente feita é qual a melhor maneira de restringir um programa? Usando a maneira tradicional com chroot, ou usar SELinux para fazer isso?
No mundo Unix, chroot é uma maneira de rodar um programa com um conjunto restrito de arquivos e diretórios disponíveis. Essa técnica de isolamento de programas é conhecida como sandbox, e o chroot é uma maneira de implementá-la. O chroot pode ser implementado como um daemon (usando a chamada de sistema chroot) ou por um shell script usando o comando "chroot". A desvantagem do chroot é que é possível escapar dele, um processo rodando em chroot tem a capacidade de ver a existência de processos que não estão rodando em chroot (ps e programas similares funcionam da mesma maneira em ambientes chroot) e IPC's (Inter-Process Communication) não são prevenidos. Uma solução para esse problema é ter um ambiente chroot avançado (que normalmente requer um patch de kernel) onde os processos chroot não podem rodar comandos como o ps sem restrições e outros têm outros limites aplicados (existem vários patches do kernel que implementam essas restrições).
Configurar um ambiente em chroot é incoveniente. Se ele é configurado da maneira tradicional (copiando arquivos para o chroot ao invés de montar com bind os diretórios) então versões antigas de programas podem existir no ambiente chroot enquanto novas versões de programas com correções de segurança são instalados no ambiente principal.
SELinux provê uma segurança melhor do que um ambiente chroot típico controlando todas as interações entre os processos. Ele provê mais flexibilidade do que um ambiente chroot avançado porque pode ser configurado inteiramente por políticas e a recompilação do kernel não é nescessária para mudar a maneira de como ela funciona. Eu acredito que é mais correto abandonar a maneira tradicional de criar ambientes chroot e usar SELinux.
Baseado no post de Russel Coker, desenvolvedor do SELinux:
http://etbe.coker.com.au/2007/08/22/se-linux-vs-chroot
No mundo Unix, chroot é uma maneira de rodar um programa com um conjunto restrito de arquivos e diretórios disponíveis. Essa técnica de isolamento de programas é conhecida como sandbox, e o chroot é uma maneira de implementá-la. O chroot pode ser implementado como um daemon (usando a chamada de sistema chroot) ou por um shell script usando o comando "chroot". A desvantagem do chroot é que é possível escapar dele, um processo rodando em chroot tem a capacidade de ver a existência de processos que não estão rodando em chroot (ps e programas similares funcionam da mesma maneira em ambientes chroot) e IPC's (Inter-Process Communication) não são prevenidos. Uma solução para esse problema é ter um ambiente chroot avançado (que normalmente requer um patch de kernel) onde os processos chroot não podem rodar comandos como o ps sem restrições e outros têm outros limites aplicados (existem vários patches do kernel que implementam essas restrições).
Configurar um ambiente em chroot é incoveniente. Se ele é configurado da maneira tradicional (copiando arquivos para o chroot ao invés de montar com bind os diretórios) então versões antigas de programas podem existir no ambiente chroot enquanto novas versões de programas com correções de segurança são instalados no ambiente principal.
SELinux provê uma segurança melhor do que um ambiente chroot típico controlando todas as interações entre os processos. Ele provê mais flexibilidade do que um ambiente chroot avançado porque pode ser configurado inteiramente por políticas e a recompilação do kernel não é nescessária para mudar a maneira de como ela funciona. Eu acredito que é mais correto abandonar a maneira tradicional de criar ambientes chroot e usar SELinux.
Baseado no post de Russel Coker, desenvolvedor do SELinux:
http://etbe.coker.com.au/2007/08/22/se-linux-vs-chroot
sexta-feira, novembro 23, 2007
Como verificar se o seu sistema suporta SELinux
O SELinux é compilado no kernel, e é suportado via LSM (Logical Security Modules). Para determinar se o seu kernel foi compilado com suporte a SELinux, devemos primeiro determinar qual versão do kernel está rodando:
# uname -r
2.6.23.1-49.fc8
Depois que determinamos a versão do kernel que está rodando, podemos consultar o arquivo de configuração que foi usado para compilar o kernel:
# grep -i selinux /boot/config-2.6.23.1-49.fc8
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
A opção CONFIG_SECURITY_SELINUX está configurada como 'yes'. Isso siginifica que o suporte a SELinux está habilitado no kernel. A opção CONFIG_SECURITY_SELINUX_DISABLE também está configurada como 'yes'. Portante, apesar de o suporte a SELinux estar habilitado no kernel, ele não está habilitado por padrão.
Outra maneira de determinar o suporte a SELinux no kernel é dar o comando para verificar o systema de arquivos virtual do SELinux:
grep selinuxfs /proc/filesystems
Para verificar o estado corrente do SELinux no seu sistema:
# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted
Obrigado ao amigo dgrift pela sua disposição em ensinar o mundo SELinux. O post original em inglês você pode acessar aqui:
http://domg444.blogspot.com/2007/11/how-to-determine-if-our-system-supports.html
# uname -r
2.6.23.1-49.fc8
Depois que determinamos a versão do kernel que está rodando, podemos consultar o arquivo de configuração que foi usado para compilar o kernel:
# grep -i selinux /boot/config-2.6.23.1-49.fc8
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
A opção CONFIG_SECURITY_SELINUX está configurada como 'yes'. Isso siginifica que o suporte a SELinux está habilitado no kernel. A opção CONFIG_SECURITY_SELINUX_DISABLE também está configurada como 'yes'. Portante, apesar de o suporte a SELinux estar habilitado no kernel, ele não está habilitado por padrão.
Outra maneira de determinar o suporte a SELinux no kernel é dar o comando para verificar o systema de arquivos virtual do SELinux:
grep selinuxfs /proc/filesystems
Para verificar o estado corrente do SELinux no seu sistema:
# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted
Obrigado ao amigo dgrift pela sua disposição em ensinar o mundo SELinux. O post original em inglês você pode acessar aqui:
http://domg444.blogspot.com/2007/11/how-to-determine-if-our-system-supports.html
domingo, novembro 11, 2007
SELinux by Example
Estou estudando SELinux à algum tempo. Para quem deseja fazer o mesmo, recomendo esse livro:
OBS: Sem querer assustar ninguém, mas existem vários motivos para o sabre de luz jedi estar na capa do livro :-)
Para quem ainda não sabe o que é SELinux (ou só ouviu falar quando instala o Red Hat e o desabilita) , assista esse vídeo:
http://www.redhat.com/v/swf/SELinux
OBS: Sem querer assustar ninguém, mas existem vários motivos para o sabre de luz jedi estar na capa do livro :-)
Para quem ainda não sabe o que é SELinux (ou só ouviu falar quando instala o Red Hat e o desabilita) , assista esse vídeo:
http://www.redhat.com/v/swf/SELinux
terça-feira, novembro 06, 2007
Mais vídeos sobre segurança
Dessa vez, voltado ao usuário final. Foi um concurso de vídeos apresentado no GTS 10. Alguns vídeos são muito interessantes, e até engraçados.
Pegue os vídeos em:
ftp://ftp.registro.br/pub/gts/gts10/08-videocontest.tar
Pegue os vídeos em:
ftp://ftp.registro.br/pub/gts/gts10/08-videocontest.tar
domingo, novembro 04, 2007
Demorei...
Congratulations; you are already an Ubuntero, having signed the Ubuntu Code of Conduct.
Teams:
https://launchpad.net/~ubuntu-hardened
Teams:
https://launchpad.net/~ubuntu-hardened
sábado, outubro 27, 2007
quinta-feira, outubro 04, 2007
Forçando uma placa de rede a 1 Gigabit
Para forçar a placa de rede para 1000 full duplex:
ethtool -s eth0 speed 1000 duplex full autoneg off
Para deixar a mudança permanente, edite ou adicione a variável ETHTOOL_OPT em /etc/sysconfig/network-scripts/ifcfg-eth0:
ETHTOOL_OPTS="speed 1000 duplex full autoneg off"
ethtool -s eth0 speed 1000 duplex full autoneg off
Para deixar a mudança permanente, edite ou adicione a variável ETHTOOL_OPT em /etc/sysconfig/network-scripts/ifcfg-eth0:
ETHTOOL_OPTS="speed 1000 duplex full autoneg off"
domingo, setembro 23, 2007
O primeiro computador que tive contato
Seção nostalgia: decidi lembrar quando e qual foi o primeiro computador que tive contato.
Em 1989 abriu a primeira escola de informática na minha cidade, e me inscrevi na primeira turma. Resolvi fazer o curso de um ano, que era introdução ao DOS-CPM, Visicalc (planilha de cálculo), wordstar (editor de texto) e dbase (banco de dados).
Os computadores usados na escola eram clones do Apple II fabricados no Brasil, quase no fim da reserva de mercado de informática. Essa reserva deixava o Brasil na época muito defasado em tecnologia, pois além de caros, os equipamentos deveriam ser produzidos aqui. Na época, apenas com 13 anos, eu já havia decidido que iria trabalhar com informática. Talvez porque fui seduzido pelos jogos karateka ou Grand Prix que eu rodava nesses computadores :-)
Mais especificamente, o computador era o TK-3000 da Microdigital. Seguem fotos dele:
Em 1989 abriu a primeira escola de informática na minha cidade, e me inscrevi na primeira turma. Resolvi fazer o curso de um ano, que era introdução ao DOS-CPM, Visicalc (planilha de cálculo), wordstar (editor de texto) e dbase (banco de dados).
Os computadores usados na escola eram clones do Apple II fabricados no Brasil, quase no fim da reserva de mercado de informática. Essa reserva deixava o Brasil na época muito defasado em tecnologia, pois além de caros, os equipamentos deveriam ser produzidos aqui. Na época, apenas com 13 anos, eu já havia decidido que iria trabalhar com informática. Talvez porque fui seduzido pelos jogos karateka ou Grand Prix que eu rodava nesses computadores :-)
Mais especificamente, o computador era o TK-3000 da Microdigital. Seguem fotos dele:
Assinar:
Postagens (Atom)
Postagens
