O Kurumin, do ponto de vista de um desenvolvedor Debian

Outro dia publiquei no site uma nota sobre uma sucessão de ataques ao Kurumin postados por parte de alguns desenvolvedores do Debian CDD.

Infelizmente este tipo de coisa tem se tornado mais e mais freqüente. Outro dia o Gustavo Noronha (Kov) postou em seu site um texto de nome bem sugestivo:

http://couve.no-ip.org/~kov/kurumerdas.html

Mais recentemente publicou um segundo texto:

http://couve.no-ip.org/kurumin-ceu-inferno.txt

Os dois foram recheados por uma série de mensagens nas listas, como por exemplo esta:

Valeu ai galera! já resolvi meu problema!
é que eu preciso ajudar meu colega que trabalha numa repartição
pública ai, ai keria ir direto na distro que ele tava usando…
mais vou de kurumin mesmo…… flw galera!

Por favor, não faça isso! Kurumin não foi feito pra ser usado em
desktop, caras. Isso vai dar merda qualquer hora.

Um detalhe interessante é que não recebi nenhuma cópia nem aviso dos textos ou das mensagens por parte de quem postou, sempre sou avisado por outra pessoa que assina a lista e me manda um forward.

Pelo teor de algumas mensagens e do conteúdo do primeiro link, parece que estamos falando de um troll qualquer, mas o Gustavo é um desenvolvedor Debian, responsável por vários projetos e bastante reconhecido.

A solução segundo ele seria convencer a massa de usuários migrar do Kurumin para o Debian-CDD ou para o Debian principal. Esta seria uma solução boa tanto para eles (que teriam bem mais usuários) quanto para mim, que com uma massa menor de usuários teria um trabalho de manutenção e suporte bem menor. A questão é que esta mudança talvez não fosse interessante para a parte mais importante: o próprio usuário.

Você deve estar pensando: Mas vocês dois não deveriam estar do mesmo lado? Bem, em teoria sim, afinal uns 95% dos pacotes usados no Kurumin são pacotes do Debian Testing sem modificações. A principal forma de atualizar o Kurumin é usando o apt-get, novamente instalando pacotes do Debian Testing. Os scripts e painéis desenvolvidos para o Kurumin são abertos e podem ser usados em outras distribuições (como são usados no Kalango, Big Linux e tantos outros), os livros e artigos do site estão disponíveis para quem quiser ler e assim por diante. Mas, na prática as coisas não funcionam bem assim.

Do ponto de vista de muita gente, quando você está usando o Kurumin ou o Ubuntu, ou o Knoppix você é um usuário destas distribuições e não um usuário do Debian. Isso causa um sentimento do tipo “eu estou dando duro aqui e este cara chega, pega todo o meu trabalho, muda algumas coisas e distribui com outro nome”. Esta é uma visão imatura das coisas, principalmente se considerarmos que a Microsoft tem mais de 90% dos desktops.

A questão fundamental do open-source, que permitiu que o Linux chegasse ao nível atual é que não é preciso reinventar a roda. Você pode pegar um programa, um pacote ou até uma distribuição inteira, fazer as modificações que quiser e redistribuir com outro nome. Quem decide se a sua versão vai ser um sucesso ou vai cair em esquecimento são os usuários. É bem parecido com a lei de seleção natural que impera no mundo real.

Note que pela GPL isto não é uma opção: ao modificar um programa você é obrigado a mudar seu nome, pois o desenvolvedor original deixa de ser responsável pela versão modificada por você. Sua versão deve ser distribuída com o seu nome, de modo que se você fizer besteira é o seu nome que estará em jogo. O desenvolvedor original recebe os créditos pelo trabalho original, mas o responsável pelos problemas da sua versão passa a ser você.

Infelizmente uma grande parte da “comunidade” é composta de pessoas imaturas, que veste a camisa de uma determinada solução ou distribuição e passa a criticar todas as outras. Quase todo mundo que acompanha algum fórum de Linux importante já teve a desagradável oportunidade de acompanhar uma série de flames do tipo “minha distribuição é melhor que a sua”.

Não criticam apenas o Kurumin. Regularmente vejo comentários contra o Ubuntu, Lycoris, Linspire, Libranet (e o resto da lista dos quase 50% das distribuições baseadas no Debian). É como o caso do torcedor fanático do Palmeiras que critica todos os outros times,

Ou seja, o mantra de muita gente é: use software livre, desde que seja o meu. Estas pessoas não contribuem com outros projetos, apenas fazem o possível para destruí-los.

Este primeiro texto tem um caráter apenas ofensivo, é uma gozação a partir de um usuário com problemas para atualizar um pacote.

Respeito bastante o trabalho do Kov muito o trabalho que ele desenvolve, mas criticar um sistema com base apenas em um problema específico é um comportamento Troll.

Estes dois pacotes que ele citou são herdados do Knoppix, versões modificadas dos pacotes correspondentes do Debian com modificações úteis quando o sistema está rodando do CD. É possível substituí-los pelos pacotes originais do Debian simplesmente forçando a instalação, um simples “dpkg -i –force-all pacote”.

Se a intenção dele fosse construtiva, ele poderia mandar um mail, postar no fórum, publicar um comentário no site explicando como resolver o problema, etc. Mas neste caso o lado troll foi mais forte.

Veja este tópico por exemplo, é dedicado justamente a postar problemas e soluções ao usar o apt-get upgrade, para sincronizar o Kurumin com o Debian Testing. Muitos problemas já foram resolvidos graças a discussões geradas a partir dele. É um exemplo de local onde o erro indicado pelo kov poderia ser solucionado de forma construtiva:

http://www.kuruminlinux.com.br/fdev/viewtopic.php?t=43

Ao contrário do primeiro, este artigo aborda questões técnicas. Muitos dos pontos levantados aqui são importantes, alguns deles já foram solucionados no Kurumin 4.1 e 4.2.

A questão do sudo por exemplo:

“Em palestras e eventos de software livre sempre se fala da segurança
maior proporcionada pelo sistema operacional GNU/Linux. Falamos de
como os vírus se alastram nos sistemas Windows e usamos a nossa
separação de privilégios por meio de permissões de arquivos como
argumento para garantir que um usuário mal intencionado não pode
causar danos ao sistema (e, portanto, não pode um vírus fazer o mesmo
se contaminar esse usuário).

O Kurumin acabou por demolir essa segurança na tentativa de facilitar
o acesso do usuário a funções e ferramentas às quais normalmente só o
usuário todo-poderoso do sistema, o root, tem acesso. Isso foi feito
permitindo que o usuário ‘knoppix’ possa executar qualquer comando
usando a ferramenta sudo sem ter de dar senha. Isso equivale a usar o
sistema como root, já que basta adicionar ‘sudo’ ao início de qualquer
comando para que ele seja executado como root.”

Aqui postei o texto da forma como foi postado na página, com os caracteres acentuados trocados e tudo.

O sudo permite executar comandos como root, fornecendo ou não uma senha de configuração. O sudo vem habilitado por padrão não apenas no Kurumin, mas também no Knoppix e na maioria das distribuições baseadas nele.

O Ubuntu, que também é uma distribuição derivada do Debian, voltada para o usuário doméstico também mantém o sudo ativado por padrão, numa configuração similar à do Knoppix e do Kurumin, com a ressalva de perdir uma confirmação da senha (do usuário em uso, não do root).

Discuti esta questão do sudo num artigo anterior, disponível aqui:

https://www.hardware.com.br/artigos/seguranca-kurumin/

“Uma instalação padrão do Kurumin no HD dá poder de administrador para um usuário comum (o usuário padrão Knoppix) *é* sim uma questão de insegurança, não meramente “pode ser mudado depois”.”

O ponto da segurança local não é bem assim. Nenhum sistema operacional atual oferece um sistema de segurança local eficiente, isso simplesmente não existe.

Vou dar três exemplos:

Para virar root em qualquer distribuição Linux: Dê boot com o CD do Kurumin (ou outro live-CD), vire root, monte a partição onde o outro sistema está instalado (ex: mount /dev/hda1 /mnt/hda1)

Use o chroot para “entrar” dentro da partição da outra distribuição: chroot /mnt/hda1 (ou o que seja). A partir daí você terá um terminal root da outra distribuição. Digite “passwd” e defina uma nova senha de root.

Pronto, agora você tem a senha de root do Slackware ou Red Hat ultra seguro do micro do seu vizinho. Se a maquina não tiver CD-ROM, não faz mal, o disquete do tonsrbd também serve.

No Windows NT/2000/XP, basta apagar o arquivo de senhas (não lembro de cor o arquivo, mas basta procurar no google), isso vai deixar todas as senhas em branco, incluindo a do administrador.

Se a máquina não tiver CD nem disquete, não tem problema, use uma Memory-Key ou CD-ROM USB para dar boot. Se tiver senha no setup, não tem problema de novo, dê um curto nos dois polos da bateria e ela some.

Ou seja, a partir do momento que você tem acesso físico à maquina, bastam alguns truques simples. Segurança local é igual chifre, é uma coisa que colocam na sua cabeça.

A única forma eficiente é usar algum sistema de arquivos com encriptação. Ainda não é 100% seguro, mas pelo menos vai dar mais trabalho. Infelizmente eles também possuem desvantagens, como perda de desempenho e uma certa dificuldade para fazer a configuração inicial.

O uso do sudo no Kurumin sacrifica uma falsa segurança em troca de uma maior facilidade de uso. Isso também diminui o numero de usuários rodando o sistema como root, o que abre problemas de segurança mais sérios. Se você tentar se logar como root na tela de login do Kurumin, vai receber uma mensagem “logins de root não são permitidos”, até que altere manualmente a opção no arquivo /etc/kde3/kdm/kdmrc

A minha idéia é que o usuário leigo passa instalar programas e usar os privilégios de root quando necessário, mas sem abrir programas como root todo o tempo. Sem isso, o que costuma acontecer é o usuário simplesmente ficar usando o root o tempo todo, isso é muito comum entre novos usuários do Slackware, Conectiva, etc. Acho que dos dois maus, o uso do sudo é o menor.

No Slackware por exemplo você pode simplesmente pressionar Enter três vezes durante a instalação para deixar a senha de root em branco (!), depois usar esta conta de root (ele não lhe dá a opção de adicionar um usuário não privilegiado durante a instalação e um usuário iniciante não vai saber como fazer isso depois), permitindo que qualquer engraçadinho se conecte na sua máquina como root via Internet através do servidor SSH que fica habilitado por default ao habilitar a categoria “N” durante a instalação.

Também não existe no Slackware nenhum script de configuração de firewall fácil de usar, tudo precisa ser feito manualmente, novamente uma coisa que um iniciante não sabe fazer. No final além de continuar logado como root, ele deixa o firewall desabilitado.

Apesar disso o Slackware é considerado uma das distribuições mais seguras, simplesmente por que presume-se que o usuário saiba o que está fazendo. Este é justamente o problema, o Kurumin é desenvolvido tendo em mente justamente os usuários iniciantes, que muitas vezes não sabem o que estão fazendo, que são freqüentemente ignorados por outras distribuições. A idéia é oferecer configurações default relativamente seguras, mas sem comprometer a facilidade de uso. Em alguns pontos é preciso impor algumas coisas, como obrigar o usuário a definir senhas durante a instalação, não deixar nenhum servidor habilitado por default e não permitir que o root seja usado para fazer login no KDE.

Depois que o usuário adquirir mais conhecimento, ele tem a chance de decidir se quer continuar usando o sudo ou não. O sudo pode ser desativado caso desejado, o que pode ser feito facilmente editando o arquivo /etc/sudoers ou clicando na opção do menu. Você pode criar outros usuários, etc. como em qualquer outra distribuição.

Quando falo sobre “segurança local” falo sobre a segurança contra danos causados por alguém que possua acesso físico ao micro, ou seja, tenha liberdade para usar o seu micro quando você não estiver. Não existe como impedir que alguém que está sentado na frente do seu micro faça alguma coisa errada, é perda de tempo, afinal se ele quiser mesmo causar algum dano, nada mais prático do que simplesmente enfiar o pé na CPU. Vai dar um prejuízo muito maior que qualquer comando de terminal e não requer nenhum tipo de conhecimento prévio.

Servidores geralmente não possuem teclado nem monitor e ficam trancados em salas isoladas. Eles são acessíveis apenas via rede, um perímetro mais fácil de proteger. O administrador acessa o servidor via SSH e faz tudo que precisa remotamente, através de um canal encriptado. O servidor só é manipulado físicamente quando é preciso fazer uma reinstalação do sistema ou em caso de falha de hardware.

Naturalmente, sob qualquer ponto de vista, é mais seguro usar o sistema com o sudo desativado. E mais seguro desativar o autologin, é mais seguro adicionar uma senha no setup, é mais seguro instalar o sistema numa partição encriptada (com a chave armazenada num pendrive e uma passprase de 32 caracteres) para que ninguém tenha acesso aos dados em caso de roubo, é mais seguro transferir arquivos via SSH que via FTP ou HTTP, é mais seguro acessar os e-mails via SSL, é mais seguro usar um monitor de LCD (a radiação dos CRT pode ser captada a distância, permitindo em teoria remontar a imagem da tela), é mais seguro usar o ICQ que o MSN, é mais seguro andar de carro que de moto e assim por diante.

O problema aqui é a questão da escolha individual. Você escolhe usar usar o autologin por que ninguém mais tem acesso físico ao seu micro, escolher não encriptar seu HD, pois é um procedimento trabalhoso e que diminui a performance, escolher usar um monitor CRT por que ele é mais barato, é obrigado a usar o FTP por que o servidor XYZ só é acessível desta forma e assim por diante.

Também tem gente que escolher usar o sistema o tempo todo logado como root, pois assim não tem problemas de permissão ao conectar usar o kppp ou ao usar a placa de som e tem gente que acha que usar o sudo é um risco aceitável em troca da praticidade.

A partir do momento em que alguém que se acha dono da verdade começa a querer fazer as escolhas pelos outros, passamos a ter um um regime totalitário qualquer, com problemas muito mais graves.

Voltando à questão do sudo, quando o Kurumin é instalado no HD é criado um ícone no desktop: “Modo seguro, desativar o sudo”. Ao clicar sobre ele é mostrada uma janela explicativa:

Este script desativa o sudo para o usuário kurumin, fazendo com que o sistema passe a operar em modo seguro.

O sudo permite executar comandos como root sem fornecer a senha. Este recurso é utilizado pelos ícones mágicos e outros scripts para facilitar o uso do sistema, mas por outro lado também diminui a segurança.

Ao desativar o sudo, os scripts que precisam dele passarão a pedir a senha de root ao serem executados.

Desativar o sudo consiste em remover a linha para o usuário atual do arquivo /etc/sudoers. Usarei o kdesu para executar esta operação, você precisará fornecer a senha de root.

A partir daí a escola é sua. Com o sudo desativado, ao executar qualquer script ou ícone mágico que precise dele, é aberta uma segunda tela pedindo a senha de root para ativar o sudo novamente e executar o script solicitado. O sistema continua funcionando da mesma forma, mas você passa a ter o inconveniente de ficar fornecendo a senha de root. O ideal é instalar todos os programas e configurar o sistema da forma desejada logo depois de instalar e só depois disso desativar o sudo.

Esta solução atualmente ainda não é ideal, pois quando você executa um ícone mágico com o sudo desativado, ele pede a senha de root para ativar o sudo novamente (depois disso você deve clicar no ícone no desktop novamente para desativar) e não para executar o script, mantendo o sudo desativado. Esta é uma solução temporária, o ideal é modificar todos os scripts para pedir a senha de root apenas uma vez ao serem executados mas isso ainda vai demorar algum tempo, pois são mais de 200 scripts para serem adaptados.

Como o tempo que posso dedicar ao desenvolvimento do Kurumin é limitado, muitas coisas importantes são deixadas para depois, para resolver outras mais urgentes, uma escala de prioridades. Ninguém é perfeito, mas vou tentando fazer as coisas da melhor forma possível dentro das limitações.

Continuando os argumentos do Kov:

“Ainda na questão da segurança, todos devem saber que um procedimento
básico na administração de sistemas é a atualização diária. Muitos
conhecem e concordam com esse princípio, mas ainda assim falta de
atualização e omissão do administrador continuam sendo grandes
causadores de invasões. O Kurumin impossibilita que esse procedimento
seja aplicado sem quebrar um segundo princípio importante que é o
princípio da menor surpresa. Ao trocar a versão de um software
qualquer sempre existe a possibilidade de que alguma configuração
padrão tenha sido modificada, ou que o arquivo de configuração mude,
ou simplesmente que algumas coisas que podiam ser assumidas com
tranquilidade não são mais verdadeiras.

Se você acompanha uma versão de desenvolvimento de uma distribuição
nunca está seguro quanto ao princípio da menor surpresa: versões mudam
o tempo todo e sempre existe a possibilidade de o desenvolvedor testar
configurações diferentes de uma mesma versão. Esse é o caso da chamada
‘testing’, no processo de desenvolvimento do Debian.”

Eu honestamente não entendi bem a crítica aqui. Acredito que ele está citando o fato do Kurumin usar o Debian Testing e não o Debian Stable que seria o mais recomendável do ponto de vista “da menor surpresa”. Eu também gostaria de usar o Debian Stable, a questão é que usar o Debian Woody hoje em dia, com o KDE 2 e o Gnome 1.4 não é uma opção viável. O Debian Sarge, (o atual Testing) que é a nova versão estável já está saindo do formo, e vai se tornar uma opção bem mais palatável.

De qualquer forma, com Sarge ou não, para atualizar o sistema a partir do Stable ao invés do Testing, basta editar o arquivo “/etc/apt/apt.conf“, mudando a primeira linha de “testing” para “stable”. De novo, a escolha é sua.

Para manter o sistema atualizado com relação ao Debian você usa o comando “apt-get upgrade“. Isso atualiza todo o sistema de uma vez e em condições normais não vai causar problemas. Recomendo usar uma versão atual do Kurumin, pois do 4.0 em diante estou testando o apt-get upgrade semanalmente e documentando os problemas encontrados aqui:

http://www.kuruminlinux.com.br/fdev/viewtopic.php?t=43

Os problemas encontrados são na maioria dos casos simples, como uma nova versão mudando a configuração da outra, ou o apt-get parando a atualização por reclamar que um pacote está tentando subscrever uma associação de arquivos do outro, que podem ser corrigidos forçando a instalação do pacote.

Essa falta de preocupação com manter a consistência da infra-estrutura
do Debian fica clara quando observamos a forma como o criador do
Kurumin ensina a fazer pacotes .deb. Qualquer desenvolvedor Debian tem
calafrios lendo as direções indicadas. Criar um .deb é extremamente
simples, mas o processo de empacotamento vai muito além de criar o
.deb final

O artigo a que ele se refere é este aqui: https://www.hardware.com.br/artigos/criando-deb/

Tem outro similar aqui: https://www.hardware.com.br/linux/dicas/100.htm

Estes artigos foram escritos para ajudar num problema comum no fórum do Kurumin, que eram pessoas que desenvolviam personalizações ou scripts e queriam postá-los para outras pessoas usarem. No debian.org existe uma documentação bem completa sobre o desenvolvimento de pacotes .deb, que recomendo ler. O problema é justamente que as pessoas “normais” não conseguem entender esta documentação e acabam desenvolvendo alguma coisa exdrúxula com um script de instalação que faz as coisas da forma mais errada possível, então dos dois males o menor.

Uma conclusão sobre as críticas do Kov é que elas foram escritas por uma pessoa com uma grande preocupação com o aspecto técnico, mas pouca preocupação com a usabilidade e pouca consideração com os problemas encontrados pela maioria das pessoas ao tentar usar uma distribuição Linux.

Do ponto de vista técnico é realmente mais interessante utilizar o Debian Stable num servidor, ou utilizar o Fedora num desktop. Ambos são desenvolvidos por equipes bastante competentes e com uma grande preocupação com a estabilidade, segurança e atualização do sistema.

A questão é que quando falamos em usuários mais leigos, estas questões deixam de ser as mais importantes.

Se fosse tão simples usar o Debian Stable ou o Debian-CDD em desktop, distribuições como o Knoppix, Ubuntu, Mephis, Kurumin, etc. não seriam tão populares.

Acredito que para o Kov, escrever estes artigos e postar nas listas seja mais importante que escrever um artigo mais amigável sobre o desenvolvimento de pacotes .deb ou indicar soluções para os problemas que levantou. Para mim também deveria ser mais importante melhorar o artigo ou corrigir mais scripts do que ficar escrevendo este artigo rebatendo as ofensas dele, mas em ambos os casos o orgulho falou mais alto e o resultado é que já temos dois artigos trolls e uma resposta a eles e nenhuma solução para os problemas… 😉

Já está na hora de acabar com esta atitude de jogador de futebol.