Tuesday, February 28, 2006

Quod Libet na veia

Depois de ameaçar São Longuinho de morte várias vezes, finalmente encontrei.Só com a dica do rockz da Freenode achei um programa alternativo ao Amarok, pro GNOME. O Quod Libet, além de não depender de nada QT, é escrito em Python e PyGTK.
Quod Libet

Ele tem todas as funcionalidades do Amarok que eu utilizava: baixa letras da internet (e salva!), baixa figura do álbum, visualiza informações na Wikipedia. Tem também outras coisas muito boas, como o sistema de organização e edição de tags "em batch". É muito mais organizado e os modos de reprodução dele são bem mais inteligentes, inclusive.

O Quod Libet é tão promissor que a comunidade tentou melhorá-lo - HEHEHE. Foi baseado no Quod Libet que um sonso escreveu o listen - só esqueceu de dar o devido crédito ao autor. Foi uma confusão digna de PSL-Brasil. Deve ter sido a violação de GPL mais mocoronga da história.

Veja a seguir instruções de instalação do Quod Libet.

Tuesday, February 21, 2006

Vulnerabilidade "congênita" em software para sysadmin

Há uma intensa e inacabável discussão sobre softwares que facilitem a administração de serviços e servidores, debate esse que fica ainda mais acalorado quando se menciona administradores em interface web.

O ponto principal do debate é que, para que se dê acesso limitado da administração de serviços a um usuário, o software vai precisar enjaular esse usuário muito bem, fazendo um controle de acesso muito complexo e com diversos possíveis pontos de falha.

No caso do Webmin, por exemplo, o daemon roda com usuário root e é necessário gerenciar não só a autenticação do usuário, como também controlar seu acesso. Para quem não conhece, o webmin permite delegar a um usuário o controle de apenas um serviço X, ou ainda apenas a componentes específicos de X (como controlar sistemas de arquivo, porém modificar os dados apenas do diretório /var/www/usuario/).

O histórico do webmin mostra que a complexidade dos seus mecanismos de controle de acesso e o potencial impacto ("root remoto", direto) da descoberta de vulnerabilidade no programa levaram à descoberta de diversas vulnerabilidade, algumas, se não me falha a memória, ainda na fase pré-autenticação(!!).
Recentemente o webmin foi retirado do Debian-sid, depois que o mantenedor compreensivelmente jogou a toalha, culpando inclusive a qualidade dos pacotes do webmin:
It is better to drop them now rather than perpetrate the cruel joke
that these are Debian-quality packages; especially because newbies often
rely on webmin to administer their systems and keep them secure. And we owe
it to Jamie Cameron, the author of webmin, not to besmirch his name and product
with buggy crap.

Mesmo que todos saibam do riscos que essas interfaces de gerenciamento possam representar, a oferta de ferramentas semelhantes só aumenta. Recentemente ouvi falar de outras duas: o ebox e o gosa.

Sistemas para facilitar a administração de servidores são ferramentas essenciais para os iniciantes e, considerando-se nessa categoria aqueles softwares de grande porte como o cpanel, há milhares de empresas cuja continuidade e segurança dos negócios dependem de interfaces de administração de serviços (penso numa empresa de hosting).

Eu mesmo me confesso simpático e reconhecedor da utilidade dessas ferramentas, desde que muito bem desenhadas e implementadas. Estou tendo uma grande preocupação com o desenvolvimento do meu nwu, visto que envolve a execução de tarefas como root nas máquinas gerenciadas.

Minha estratégia para tentar garantir um nível razoável de segurança passa por: utilizar criptografia na transmissão (HTTPS) e na autenticação (HMAC) das mensagens; não supor que o cliente seja confiável, mesmo que autenticado e; principalmente, mapear todos os possíveis pontos de risco da aplicação e auditá-los sempre.

Não tenho dúvida que fazer software seguro exige muito esforço e, tcha-na-nãs, tempo livre. Afinal de contas, só consideram questões de segurança quando não há prazo a ser cumprido :-).

Tuesday, February 14, 2006

Mais um assinante do Safari da O'Reilly satisfeito

Estou assinando, ainda em periodo de testes, o Safari da O'Reilly.

Através do Safari, posso ler on-line os livros da O'Reilly e outras editoras famosas (incluíndo Microsoft Press e Prentice Hall). Boa idéia pra quem gosta de ler textos no computador. Eu até prefiro.

Atualmente na minha prateleira - ao assinar o plano normal você recebe um espaço para leitura simultânea de 10 livros - tenho apenas o Learning Python e o Understanding the Linux Kernel, 3a edição, nova, já atualizada com relação ao Linux 2.6. É provável que eu adicione também Linux Debugging and Performance Tuning: Tips and Techniques - só que fico com dó de gastar slots à toa hehe.

Fiquei empolgado com a possibilidade de ler livros enquanto estão sendo escritos, através dos Rough Cuts, como o Ubuntu Hacks - previsto para junho de 2006. O problema é que os assinantes do Safari não podem adicionar este livro como os outros. Têm que comprar o acesso, separadamente. USD $14.99. Esse, hipotético leitor, é o preço de querer saber tudo antes de todos - mania do meu ídolo e colega de trabalho César Cardoso.

Aliás, César, seu blog tá muito interessante.



(Você pergunta: por que seu site tem propagandas? Eu respondo: uai, porque vai que eu ganho dinheiro, ué.)

Monday, February 13, 2006

Como bloquear em seu proxy o acesso ao Google Talk interno do Gmail

Muitas organizações têm como política não permitir a utilização de softwares de "mensageria instantânea", ou instant messaging.

Isso pode não ser uma abordagem muito eficiente, pois a tendência é que os usuários começem a utilizar o próprio e-mail como sistema de mensagem instantânea. A gerência deve ter consciência que esta provavelmente não é a melhor forma de se melhorar a produtividade da equipe.

Por outro lado, já vi muitos gerentes experientes colocando rédeas curtas em sua equipe não por incompetência de liderança, mas em consequência da imaturidade de colaboradores. Além do mais, proibir o acesso direto no proxy de internet é bem mais simples :-).

Com a disponibilização no Gmail de uma interface integrada de comunicação via Google Talk, surge a demanda por uma forma de bloquear o acesso a este recurso especificamente, sem bloquear o Gmail em si.

Para isso, o acesso à seguinte URL específica deve ser bloqueado:

http://mail.google.com/mail/channel/bind*

Para configurar o Squid para esse fim, o sysadmin deve alterar o squid.conf, incluindo as seguintes regras:


acl gtalk url_regex -i "mail\.google\.com/mail/channel/bind"



http_access deny gtalk


UPDATE: para bloquear também os domínios pessoais com Gmail ativado, utilize "channel\/bind" apenas.
Acho uma pena que o Google Talk seja bloqueado, pois é um serviço muito bacana e bonitinho. Só estou mostrando como fazê-lo.

Espero que tenha sido útil.