E você, praticidade ou segurança? Também fico com o segundo.

Falso dilema [inglês].

@Rafael Jamur,

O sudo, bem configurado, não é uma brecha de segurança. Da mesma forma este recurso em discussão.

Sim, é verdade. O sudo provavelmente não é a solução mais adequada para a implementação de uma política de segurança bem definida. (é possível, mas não é adequado)

É melhor usar pkla.

André Caldas.

Era uma abominação.

Sea moda pegasse, não quero nem ver q quantidade de botnets a partir de desktops Fedora que iam começar a surgir. Se para um usuário médio, com senha de root para utorizar instalação, a segurança não é 100%, imagine esses mesmos usuários médios baixando servidores FTP no trabalho, muitas vezes com usuario ftp senha http://ftp...

Login e senhas fracas, servidor FTP instalado, arquivos com bots subidos para a estação e um simples duplo clique em cima feito pela mesma anta que deixou o FTP instalado assim…

Mais um zumbi terá nascido no mundo. Fácil, rápido e extremamente doloroso.

Se é tão seguro assim (ou tanto faz), por que voltaram atrás: http://www.guiadohardware.net/noticias/2009-11/4B06B1DC.html

O Fedora é ou não é um laboratório? E você, praticidade ou segurança? Também fico com o segundo.

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?)

Bom para quem? Para o administrador da rede com certeza não. Concordo com aqueles que consideram essa “nova característica” do Fedora uma grande falha de segurança, mas pra o fim que se destina a distribuição, não vejo tanto problema assim, afinal, o Fedora é apenas um laboratório para a Red Hat (quer uma distro estável e confiável, use a versão enterprise).

Quanto a montar “servidores de produção” com o Fedora, alguém faz isso? Ou melhor, alguém faz isso em uma atividade séria? Se faz, me diga como consegue manter atualizado e seguro um sistema que a cada 6 meses tem uma nova versão, é mal documentado, instável e cuja vida útil de atualizações é tão curta? A própria Red Hat não recomenda, para isso há a versão Red Hat Enterprise Linux, ou o próprio CentOS. A propósito, duas excelentes distros.

Para o fim a que se destina o Fedora (laboratório), não vejo problemas em instalar pacotes sem a permissão de root, e acredito que esse foi o pensamento da Red Hat, mas para um uso, digamos, mais sério (desktops corporativos e servidores), acho essa característica inadmissível. Afinal de contas, que administrador de redes gostaria de ver seu usuários “instalar o pacote que eu quisesse sem ter que pedir pra ninguém.”?

Um sistema bem configurado não necessita de acesso via root se os serviços rodarem com as permissões corretas.

Em servidores, paranoia nunca é demais.

“Argumento de autoridade detectado. Não acho que tenha valor algum para uma discussão técnica.”

Desculpe, mas prefiro a opinião de especialistas do que achismo. O que postei não foi suposição, foram fatos que viraram estudo de caso (e ainda não caiu a ficha que o compilador é só a ponta do iceberg).

Quantos pacotes tem o Fedora (cinco, dez, mil, milhares), todos testados ??
A secretária precisa de um sniffer ??
Devo atacar diretamente o servidor ou uma estação que me disponibiliza trocentas ferramentas ??
Há um firewall interno ??
Há um firewall entre setores ??
A ameaça vem pela web ou pelo próprio colaborador mal intencionado ??
Quem instalou aquele pacote de ftp que tem uma falha de segurança ??

Para completar a lambança, é aguardar um repositório oficial comprometido (Hã… desculpe… esqueci… isto nunca aconteceu antes… não tem valor algum para uma discussão técnica).

“O remédio foi pior que a doença.”
“Escreveram um código bacalhau.”
“Não foi uma solução elegante.”
“Isto vai virar numa zona, terra de ninguém.”

Esta solução foi mais um tiro no pé (Olhem só, o paiol das armas esta liberado, sirvam-se a vontade e não se preocupem pois qualquer usuário aqui possui o CHA – Conhecimento, Habilidade e Atitude – Ops !! Alguém ai perdeu o pino da granada arrasa-quarteirão ???).

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.

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.

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.

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.

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).

Esse é o primeiro passo para virus e trojans tomarem de conta do mundo Linux…

[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é, em primeiro lugar quero destacar que o meu comentário concordou com o seu.

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”. :-)

André Caldas.

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.