Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!
…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe - quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Contato: jczucco at gmail dot com

kerneloops.org: Você também pode ajudar a melhorar o kernel do linux

kerneloops.org é um site que procura ajudar os desenvolvedores do kernel linux coletando "kernel oops", que são assinaturas que o kernel gera quando ele tem problemas de crash. Os "oopses" coletados são estatisticamente processados para apresentar informações aos desenvolvedores, como:

- Quais são as assinaturas de crash mais correm (e que obviamente precisam ser corrigidas mais urgentemente);
- Quando foi a primeira vez que um determinado tipo de crash ocorreu?
- Quais são as funções da API do kernel que apresentam mais erros?


Os kerneloops podem ser submetidos no site, ou automaticamente pela ferramenta disponível no site, como mostra essa captura de tela no Fedora 9:

Todos os videos do You Sh0t the Sheriff 1.0

Finalmente todos os videos do YSTS 1.0 estão no ar. A maioria das palestras em PDF tambem.

Divirtam-se.

Abertura do Luiz Eduardo
Video Palestra

Nick Farr - Building the Global Hacker Community
Video Palestra

Augusto P. de Barros - Detecção de ameaças internas: Alternativas, tendências e novidades
Video Palestra

Luis Miras - Reverse engineering analysis of various vulnerabilities
Video Palestra

Eduardo Neves - Sobrevivendo no Mercado: As Carreiras em Segurança da Informação
Video Palestra

Rodrigo R. Branco - KIDS - Kernel Intrusion Detection System
Video Palestra

Mike Reavey - MSRC’s historical perspective on security ecosystem
Video

Adriano Cansian - Forjando o código: Desafios e progressos da formação profissional em segurança
Video Palestra

Felix "FX" Lindner - iPhone vs. Windows Mobile vs. BlackBerry vs. Symbian
Video

Eldon Sprickerhoff - Attacks of Nortel VoIP Implementations
Video Palestra

Emmanuel Goldstein
Video


--


Posted By Willian Caprino to i shot the sheriff at 6/14/2008 02:29:00 P

Core SELinux version R080611 released

An updated public release of SELinux was made available today. Some highlights of this release are listed below:

* New support for permissive domains in libsepol and checkpolicy.
* New support for user and role remapping in libsepol (required for use in optionals).
* Fixed endianness bug in handling network node addresses in libsepol.
* Fixed semanage port to use --proto.
* Updated audit2allow to report dontaudit cases.
* Revised the policy load logic in libselinux to try loading the maximum supported version of the kernel or libsepol.
* Fixed matchpathcon -V support and changed it to report success/failure via exit status.
* Fixed memory leaks in matchpathcon in libselinux.

Fonte: National Security Agency

Palestra que ministrei no Forum Internacional de Software Livre em 2007, sobre Técnicas e Ferramentas de Código Aberto Para Combate ao SPAM. Os slides podem ser pegos aqui.

Debian/OpenSSL Weak Key Detector

Para verificar se o seu Debian está afetado pelo bug do openssl:


wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
Assinatura PGP: dowkd.pl.gz.asc (opcionalmente verifique a assinatura do script)


gunzip dowkd.pl.gz
chmod u+x dowkd.pl


./dowkd.pl user
./dowkd.pl host


Fonte: http://ubuntu-tutorials.com/2008/05/13/openssh-openssh-vulnerabilities-confirm-fix-instructions/

Monografia sobre SELinux

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

Phishing: Pare - Pense - Clique

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

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”

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

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

Disk encryption - useless ?

Fonte:

http://isc.sans.org/diary.html?storyid=4006

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?

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

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.

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

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.

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

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