Distribuição amigável agora deixa usuários instalarem pacotes sem precisar de acesso root
Agora usuários conectados diretamente ao console podem instalar pacotes de software assinados, de repositórios idem, sem precisar de acesso de superusuário.
Segundo a cobertura da imprensa, a mudança do Fedora 12 inicialmente não foi documentada (agora isto mudou, e a documentação confirmando a mudança veio a público), e sua divulgação causou consternação entre usuários da distribuição.
A mudança na política de acesso no Fedora 12 foi realizada na intenção de tornar o sistema mais fácil para usuários desktop. (via h-online.com)
Saiba mais (h-online.com).
• Publicado por Augusto Campos em
2009-11-20
@brlinuxblog
Feed RSS
parece piada
Esta questão do superusuário sempre foi meio controversa, ou melhor, bagunçada mesmo. Enquanto o Fedora agora permite que usuário não-root instale programas, hás distros (como a Puppy) em que o usuário é sempre root, o que, na prática, acaba sendo a mesma coisa em termos de segurança.
Há distros que não permitem logins com root, enquanto outras permitem (Freespire, p. ex.), Já a SliTaz exige a senha root para algumas tarefas (como instalação de pacotes), mas o campo dela já vem preenchido (é “root” mesmo…) e o usuário só precisa clicar em OK.
Eu acho que coisas assim, sem nenhuma padronização, acabam por dar impressão de amadorismo e coisa feita nas coxas.
Já está resolvido:
https://bugzilla.redhat.com/show_bug.cgi?id=534047
Na minha opnião, há um lado bom e um lado ruim nisto.
O bom, já foi dito. Facilita para os usuários de desktop.
O lado ruim é que para servidores, a distribuição já não serve. Pois permique que se um invasor que consiga entrar no servidor instale pacotes que possam lhe ajudar a roubar informações ou usar este servidor para atacar outros servidores.
Facilitar o uso do Linux para usuários desktop caseiros é sempre uma boa idéia, contanto que não comprometa a segurança, e isso cai no que eu escrevi no inicio de meu comemtário. Mas os usuários desktop coorporativos poderem instalar pacotes, já faz com que o fedora começe a não mais ser considerado uma boa opção para uso coorporativo. Ora, na instituição que trabalho, não é permitido ao usuário instalar programas e muito menos que estes sejam tocadores de DVD e jogos.
Bom, mas nesta questão acima, o que pode ser notado é que os desenvolvedores do Fedora, estão focando a distribuição em um determinado tipo de usuário e com certeza eles sabem disso.
Isso faz com que o Fedora não seja mais uma das opções de distros para se usar como servidor, deixando a função para o CentOS, para aqueles que querem uma distribuição gratuita e que siga a ramificação da RedHat.
Mas… ainda continua a questão acima. E o usuário final? E se ele for invadido?
Triste decisão dos desenvolverodes do Fedora….
Bom, é só ler um pouco a documentação que veremos que só é possível instalar sem ser solicitada a senha de root se os pacotes forem assinados e de repositórios confiáveis, se o usuário estiver usando a máquina localmente (usando teclado e mouse físicos, nada remoto) e se estiver instalando a partir da interface gráfica (nada de fazer isso no modo texto). A mudança não altera o yum, não permite qualquer instalação remota de pacotes e não permite remoção. Isso seria apenas para facilitar para o usuário eventualmente que clica no “Adicionar/Remover Programas” ou que apenas quer atualizar o seu sistema com os pacotes oficiais do Fedora.
De todo modo, apesar de entender eu não concordo com essa decisão e acho que foi uma atitude infeliz, pois alguns compartilham computadores com várias pessoas da família ou usam computadores em laboratórios públicos, ou seja, isso seria uma brecha para outras pessoas bagunçarem o sistema. Como o Filipe Rosset disse acima, o problema já foi resolvido e já existe um pacote disponível que resolve o problema. Ainda bem, pois eu não atualizaria meu Fedora 10 para o 12 caso continuasse desse modo.
Apesar de parecer uma falha de segurança à princípio, não parece ser tão ruim assim, se considerar que o sistema está limitando o acesso apenas para a instalação de pacotes, e não para o resto.
Além disso, ele apenas irá liberar as permissões para pacotes assinados (de repositórios idem), o que de certa forma facilita manter um pouco mais de segurança.
O fato é que a segurança nesse caso vai depender mais da implementação do que da idéia em si.
Não vejo problema com a funcionalidade em si, pois ela apenas aceita a instalação de pacotes assinados.
O problema está em 2 detalhes:
- Falta de documentação inicial sobre a funcionalidade;
- Uma funcionalidade dessas não devia vir ativada por padrão.
Pois é, um ataque pode ser feito assim:
O “usuário” instala um compilador no servidor, baixa o código fonte da praga (um minúsculo arquivo texto da vida), compila, carrega a praga na memória, remove o binário e o source.
No disco não vai constar nada, mas a praga esta lá. Instalar pacotes sem ser superusuário deveria ser uma opção que por padrão deveria estar desabilitada (e ai habilita quem quer e entende os riscos).
Na minha humilde opinião não há facilidade nenhuma nisto.
as pessoas que devem mudar um pouco seus conceitos, pois o que custa digitar uma senha quando tem que instalar um programa?
isso não é nada de ruim não… imagina, para o usuário se conectar no seu email ele também não precisa de digitar uma senha? então porque ele acha dificil digitar uma senha no pc?
Não vale a pena comprometer a segurança em favor de uma suposta comodidade para usuários que, a princípio, deveriam entender sobre os riscos que correm todos os dias.
Isso me cheira “aquele-sistema-do-qual-não-falamos” e todos sabem o que acontece. Não, não adianta defender e dizer que é diferente pq não é.
Creio que essa funcionalidade seria interessante se o pacote fosse instalado na HOME do usuário, com linkagens e caminhos configurados pela aplicação de forma automática.
Mas instalar na raíz do sistema é sacanagem.
Estou começando a achar que o Slackware realmente parece ser a única distro linux.
Deixa o ubuntu para os amadores, fedora nem é difícil para começar. E quem está nesse nível de amadorismo só usa um programa, que já vem instalado por padrão, o firefox.
Nossa, quanto alarde … Como se isso já não fosse possível anteriormente…
Eu nunca instalo software à partir do source como root, sempre compilo e instalo no home do meu usuário. A diferença é que agora eu posso usar o yum, o que na verdade é bom… Se não quiser misturar as coisas só passar um ‘/’ alternativo, da até pra configurar o yum/rpm pra usar um banco de dados alternativo.
Pra quem for muito paranoico da pra limitar tudo isso usando SELinux, ou simplesmente , proibindo um grupo de usuários comuns de executar o yum/rpm, gcc, e colocando parametro noexec em todas as partições onde o usuário tem permissão de escrita.
Enfim, se o usuário tem acesso físico a máquina, não adianta chorar, vai dar muito trabalho pro sysadmin barrar instalação de qualquer software malicioso ou não. Principalmente se o usuário for mais competente que o sysadmin.
O único problema que vejo nisso é que não avisaram antes, pegaram a negada de calças na mão.
Outro motivo pelo qual não vejo problema nessa implementação é que o uso do fedora como servidor em produção sempre vai exigir um sysadmin competente ou insano , logo ou o sistema vai estar bem guardado ou não vai fazer a mínima diferença :P
Para os sensatos o CentOS é quase sempre uma solução redhat-like mais robusta.
Eu gosto da idéia. Ainda não usei o Fedora 12, agora tenho motivos pra isso. Porém, acredito que deveria existir – se não existe, ainda não usei – um nível de proteção para remoção de pacotes. Usuário instalou, ele mesmo pode remover. O root, obviamente, faz tudo. Um usuário não-root não poderia remover pacotes de outro usuário ou de sistema. Assim ficaria bem interessante.
@Fernando
Então sou sensato em tudo, uso CentOS até no meu desktop :-)
@Luciano
O @Fernando tocou num ponto muito interessante. Já tentei usar o Fedora pra servidores, e ele atende bem. O problema é o suporte. Fedora não serve para esse fim, a não ser que você seja ultra-competente ou insano, conforme o Fernando mesmo disse!
E minha empresa também não gostaria de ficar atualizando versão de servidores a cada 6 meses…
A notícia chegou ao br-linux.org em formato “bem suave”, e repercurtiu “bem mal” nos demais sites… enfim :-D
Bom, antes de tudo, é Falha de Comunicação: fizeram o release e não avisaram o mundo sobre isso… um usuário (ou ex ehehehe) percebeu e reportou. Tremenda falha de comunicação.
Sobretudo trata-se de Falha de Segurança, completamente distante do que prega o Unix. Mas não condeno os caras do Fedora, eles estão com boa vontade de melhorar pros usuários… esse tipo de idéia mostra que a redhat confia muito no SELinux e sua capacidade de perceber código malicioso tentado rodar.
Será que devemos confiar também?!?! ;-)
Primeiramente, a funcionalidade só está disponível através do PackageKit. NENHUM servidor deveria ter um “packagekit” instalado!!
NÃO é inseguro pelos argumentos dos leitores acima! Por exemplo,
@builder:
Cadê o ataque meu filho!! Você quer dizer que ter um compilador instalado no sistema é uma falha de segurança!?
Se fosse assim, todos os sistemas que possuem um compilador instalado seriam inseguros. Felizmente isso não é verdade.
E porque um ataque não pode ser feito em shell script?? Qual é a grande vantagem de ter um compilador? Eu poderia compilar no meu laptop e copiar o binário pro meu “home”!!!
@Livio Ribeiro,
A segurança não foi comprometida. Na maioria dos sistemas você acabou de eliminar a necessidade de dar acesso root ao usuário comum. No Ubuntu, por exemplo, o primeiro usuário pode fazer qualquer coisa através do SUDO. O SUDO sim é uma grande brecha de segurança. Para ser seguro, o SUDO tem que ser corretamente configurado exatamente de acordo com a política de segurança do sistema. Por exemplo, não se deve precisar de sudo para:
* Montar um pendrive;
* Configurar a rede wireless em um Desktop;
* Instalar pacotes assinados em um Desktop ou no computador de uma organização que não se importe com isso.
@Habeas Corpse,
Tá bom… aí você condiciona o usuário a ficar digitando senha pra qualquer coisinha boba que for fazer. (já sei, vai dizer que instalar pacotes assinados não é coisinha boba…)
O “sudo” em ambiente gráfico, por exemplo, muito me incomoda. Não entendo as exatas consequências de digitar minha senha quando a “janelinha” aparecer com essa solicitação. Não sei exatamente quem estou autorizando para fazer o quê. Ao decidir se vou ou não digitar minha senha, EU estarei decidindo na hora qual é a política de segurança adotada. Não vejo vantagem nisso. É muito melhor que a política seja bem definida e conhecida por todos.
O “sudo” é um remendo que precisa ser eliminado.
É errado exigir uma senha quando não há necessidade. Se o gerente do seu banco lhe pedisse sua senha mediante a pergunta “qual é a tarifa para saques”, isso seria uma séria falha de segurança, além de uma grande burrice. Mas o que custa digitar sua senha pra poder fazer uma pergunta ao gerente do banco, não é mesmo…
A impressão que eu tenho é que faltou uma discussão maior sobre o assunto. (provavelmente teve uma discussão e eu só não fiquei sabendo)
Pontos importantes a serem considerados são:
* No momento da instalação deve-se perguntar se o usuário quer ou não essa funcionalidade?
* É verdade que nenhum pacote pode ser instalado/configurado sem acesso root para dar acesso root a um usuário comum?
* Como já colocou o Lucas Timm, como fica a desinstalação dos pacotes?
* E as alterações nas configurações? Deve depender de “quem instalou” e “quem está modificando”?
* E as atualizações?
Claro que o assunto é delicado. Se o sistema permitir alteração na configuração ou desinstalação de pacotes “dos outros”/”do root”, então isso será uma falha de segurança.
A distro é feita de modo a ser segura independentemente do que se tenha instalado. Claro que com menos coisas instaladas menores as chances de ataques e tal.
Em geral, na universidade, ou no trabalho, seria muito bom poder instalar o pacote que eu quisesse sem ter que pedir pra ninguém… (pedir pra quem, mesmo?)
André Caldas.
A maior vantagem que o Linux sempre teve em relação a Windows sempre foi a maior segurança.
E essa segurança vem exatamente da separação entre área de usuário e área de administração, coisa que a MS começou a adotar desde o win2000 pra desktop.
Se tirarem isso, vamos estar dando um passo atrás na confiabilidade do Linux, que já é difícil de manter nos usuários comuns, imagina se ciomeçarem a ter problemas de segurança com Linux agora.
Como ja disseram, a completa falta de padronização é talvez o ponto mais fraco do linux.
Remover ou restringir acesso a compiladores era, sim, uma instrução clássica da segurança de servidores Unix na época da minha formação.
Acredito que hoje ainda faça tanto sentido quanto antigamente, em todas as situações em que se deseje restringir os executáveis a que um dado usuário pode ter acesso – shells restritos e similares. Mas não parece ser o caso da maioria dos desktops em PCs.
Não ser o root e ter seu usuário no grupo SUDOERS é a mesma coisa que ser o root… Deu na mesma,
A maioria das distros é assim, na prática acho que não existe Linux seguro, e sim usuários que fazem o Linux seguro.
@Andre Caldas:
Interessante sua opnião. Realmente, pensando bem, só o sudo que é porcaria. E o pior é que para desativar no ubuntu você tem que mudar TODOS os comando que usem gksu para usar o su em vez do sudo e adicionar uma senha para root com sudo passwd. Mas isso ainda não resolve o problema.
Esse é o primeiro passo para virus e trojans tomarem de conta do mundo Linux…
@Augusto,
Eu não falei que não era uma instrução clássica de segurança. O Manual de Segurança do Debian (não lembro se o nome é esse), por exemplo, sugere que compiladores não sejam instalados se não são necessários. O autor no entanto reconhece que essa é uma recomendação que não traz grandes benefícios. Eu falei que o post do sujeito diz que ter um compilador instalado é inseguro. Isso não é verdade.
O que eu estou dizendo é que é uma instrução que não é útil e precisa ser repensada. Eu, por exemplo, acredito que em um servidor, deve-se saber exatamente o que está instalado. Isso é muito mais importante (e mais forte) do que não ter compiladores instalados. Uma GUI em um servidor é pra amadores. Em um servidor, cada usuário deve ter um papel e uma política de segurança bem definidos. Toda a instalação do servidor deve ser feita através de scripts testados e possíveis de serem repetidos de maneira idêntica quantas vezes for necessário.
Um servidor que tenha QUALQUER TIPO DE APLICATIVO desnecessário instalado está mal configurado.
Veja bem, não estou defendendo o “default” silencioso do Fedora. De fato, a única crítica dos comentários acima que faz sentido é a questão do default. Os sistemas Unix são por default hostis. Ou seja, não se assume que um usuário confia no outro.
Preocupações que identifiquei:
* O default é silencioso.
* A questão do ataque DOS da partição onde os aplicativos são instalados.
* A questão de se poder instalar o GDM no lugar do KDM, e tal.
* A segurança depende da correta implementação de uma política de segurança (por exemplo, não ativar serviços por default) pelo conjunto total dos demais pacotes (milhares).
* Não sei mais, por que só li a primeira metade dos comentários do bug. ;-)
Se as questões acima forem discutidas e resolvidas, eu acho que a OPÇÃO de não classificar todos como sudoers é muito bem-vinda.
André Caldas.
PS: Só um comentário sobre a minha frase:
Se eu bem conheço o Augusto (e eu não conheço =P), ele certamente vem com algum argumento do tipo: “nada é verdade sempre”, ou alguma variação. Eu já tô colocando isso aqui pra não precisar nem responder.
O Mandriva 2010 é amigável, mas está fora desta lista.
Pra instalar pacotes .rpm, só com a senha de root.
@Edivaldo , o primeiro passo já foi , faz tempo . Sou sysadmin de alguns servidores, e é super comum encontrar usuários rodando botnets.
A tática é simples, vc roda um script que ‘invade’ uma máquina por meio de senhas fracas de usuários inexperientes. Assim usuário infectado , tenta invadir outras máquinas e assim vai …
Não existe sistema seguro se o usuário usa o username como senha ! Quem tem server na rede sabe que máquinas e servers linux zumbies e redes linux de botnets são uma realidade a pelo menos 3 anos.
Pra evitar essas encrencas a receita é simples, política de segurança clara para os usuários, e verificações constantes de senhas simples e nos logs do SSH.
@VinIPSmaker,
Legal você estar disposto a analisar o problema e suas consequências. :-)
O sudo serve para flexibilizar o “set uid” bit. Com o sudo você pode escolher exatamente quais aplicativos podem ser rodados como root por quem e com quais argumentos. O problema é que em geral (achismo meu) o que se faz é dar um “sudoers” pra qualquer um. E isso acaba com a possibilidade de se definir uma política de segurança descente para o sistema.
Pelo que entendi do que li até agora, a politica de segurança deve ser descrita pelo pkla. Cada pacote (e não o do sudo) deve conter sua própria política de segurança. Por exemplo:
Permitir que um usuário comum “monte” pendrives sem nenhuma restrição é inseguro. Justamente por causa do “set uid” bit. O sistema de arquivos é quem diz se o dono do executável é root ou não, e se o executável pode alterar seu próprio uid efetivo para o uid do “dono”, ou seja, root. Portanto, se você permite que pendrives sejam montados sem restrição os usuários poderão executar comandos arbitrários como root!!
Quem deve definir a(s) política(s) de segurança do aplicativo “mount”? O administrador? Não! O próprio aplicativo. O administrador deve escolher a política que quer usar. (claro que a gente espera que o administrador conheça as implicações de cada política)
Se a política de segurança diz que um usuário X deve poder instalar aplicativos… pra que ficar pedindo senha!? De que modo a senha torna o sistema mais seguro!? A senha é uma consequência do hábito de se colocar todo mundo no “sudoers”!
Por que o sudoers precisa de senha? Simples, porque o sudoers pode fazer qualquer coisa e você precisa avisar o usuário se algum aplicativo estiver tentando fazer “qualquer coisa” em seu nome como sudoer. Se não pedisse senha, seria como se o usuário fosse o próprio root!!! Isso não acontece para o caso específico da instalação de aplicativos. Pra quê a senha se o usuário tem autorização para fazê-lo!?
O mesmo acontece com redes wireless, por exemplo. Se o usuário tem permissão para configurar o wireless, pra que ficar pedindo a senha toda hora!? Se o usuário pode montar pendrives sem “set uid”… pra que pedir senha!? (neste caso parece que já virou consenso que não precisa)
Quanto a mudar o sudoer para su… talvez (não sei bem) você possa utilizar o update-alternatives.
Sim… o problema é a falta de uma política de segurança bem-definida. :-)
Um abraço,
André Caldas.
André, em primeiro lugar quero destacar que o meu comentário concordou com o seu.
Em segundo, quero esclarecer que eu também não disse que voce disse que não era uma instrução clássica de segurança.
Ah… esse comentário do bug é muito interessante:
https://bugzilla.redhat.com/show_bug.cgi?id=534047#c140
André Caldas.
@Augusto,
Pô Augusto, foi malzão!!
Só agora entendi que você tava dizendo que:
* Na minha época de formação —> antigo e ultrapassado. =P
Eu pensei que era algo do tipo:
* Até onde eu saiba; ou
* Já é uma recomendação consolidada; etc…
Desculpe aí. (e desculpe pela piadinha do “antigo e ultrapassado” acima)
Temos mais um caso onde eu “ataco” você sem justificativa. Desculpe, novamente.
Um abraço,
André Caldas.
PS: Você deve me achar um bocado “mentalmente instável”. :-)
@Edivaldo,
[sarcasmo]
Muito produtivo esse seu comentário.
[/sarcasmo]
É um argumento do tipo “catástrofe”. Não tem nenhum embasamento. De fato, é muito mais seguro uma política de segurança que permite apenas pacotes assinados a uma política que pede a senha do cara pra fazer QUALQUER coisa, inclusive instalar vírus e trojans.
O primeiro passo pra vírus e trojans é o uso do sudo que é praticamente como estar constantemente como root.
É preciso fazer duas distinções:
1. O usuário comum pode ou não instalar aplicativos.
2. O usuário comum precisa de uma senha para fazê-lo.
São dois problemas distintos. A solução que se tem hoje, é dar sudo para quem quer instalar pacotes. O item 2 é basicamente consequência da solução com sudo.
A solução proposta, utilizando pkla, é muito mais interessante e segura se for bem discutida.
André Caldas.
André Caldas, se tivesse prestado mais atenção no que escrevi, teria percebido que o compilador seria utilizado como parte do processo que culminaria no ataque, já que muitos amadores acham que só o binário vindo prontinho causa o estrago.
A propósito, meu comentário foi baseado nas orientações de segurança (e estudo de casos) de pessoas que possuem: Certification for Information System Security Professional (CISSP), Certified Information Systems Auditor (CISA), Certified Information Security Manager (CISM) e Security+.
Casualmente uma destas pessoas é o John H. Terpstra (co-fundador do Samba Team).
Argumento de autoridade detectado. Não acho que tenha valor algum para uma discussão técnica.
E se você tivesse prestado a atenção, veria que não descreveu ataque nenhum!
O que você está tentando é mostrar de que forma a instalação por não roots torna o sistema inseguro. Seu argumento, pelo que entendi, é:
1. Não root pode instalar compilador;
2. Compilador pode compilar vírus;
3. Portanto é inseguro.
Se a sua conclusão 3 (implícita) estiver correta, então também está correta a afirmação de que todos sistema que tem um compilador instalado é inseguro. E isso não é verdade.
Também implicaria que TODO SISTEMA que permite que um usuário execute um binário que não é padrão do sistema é inseguro. Isso também não é verdade.
Sua conclusão, por mais que tenha sido baseada em grandes nomes, está totalmente incorreta.
Agora, se a sua conclusão não é de fato 3, então, o que é mesmo que você estava argumentando?
Se parar pra pensar, vai ver que o “ataque” que você descreveu, não é de fato um “ataque”! =P
André Caldas.
Em um primeiro momento, acho essa “feature” uma aberração que deveria ser extinta.
Mas vou continuar pensando sobre o assunto e suas implicações.
De cabeça quente, no calor do choque que levei quando li isso, não dá pra dizer nada útil.