linux magazine ed. 98 (janeiro 2013)

http://lnm.com.br/article/8033








http://creativecommons.org/licenses/by-nc-nd/3.0/br/

www.lnm.com.br/

3Linux Magazine #98 | Janeiro de 2013

ED

ITO

RIA

L

...macht mich nicht heiß. Este ditado alemão é a variante teutônica do brasileiríssimo “O que os olhos não veem o coração não sente”. Recen-temente, em uma conversa com Jon ‘maddog’ Hall, fi cou patente para o autor destes mal-digitados caracteres que a ignorância de certos fatos pode signifi car uma portentosa oportunidade perdida para os proponentes de várias causas e mesmo para o mercado para o qual tais fatos sejam relevan-tes. Em 2007 (mais especifi camente no dia 12 de janeiro), em um experi-mento idealizado por Gene Weingarten, colunista do jornal americano The Washington Post, o aclamado violinista estadunidense Joshua Bell tocou incógnito em uma estação de metrô da capital dos Estados Unidos, em condição equivalente a um artista de rua, o mesmo repertório para o qual foi cobrada uma média de 100 dólares por ingresso na noite anterior em uma sala de concertos na cidade de Boston – e que esgotaram-se com bastante antecedência. Das 1.097 pessoas que passaram por ele, Bell re-cebeu um total de US$ 32,17 durante os 45 minutos de sua performance, à exceção dos 20 dólares recebidos de um transeunte que o reconheceu. Além deste, apenas outras 7 pessoas pararam para ouvi-lo tocar, a maioria crianças. Todo o experimento foi gravado por uma câmera oculta e o artigo a respeito, que foi publicado em 2008 no The Washington Post, rendeu um prêmio Pulitzer a Weingarten ( Pearls Before Breakfast ).

Está acontecendo a mesmíssima coisa no mundo da tecnologia atualmen-te. E o artista incógnito tem um nome bem conhecido: Linux! O sistema operacional se tornou onipresente nas duas pontas que são os motores das tecnologias que movem o nosso mundo: Cloud Computing e dispositivos móveis e/ou embarcados. Android, Tizen, Bada, WebOS Firefox OS e uma miríade de outros sistemas operacionais para dispositivos móveis baseados no kernel Linux dominam o mercado desse tipo de equipamento, o mesmo va-lendo para leitores de livros eletrônicos, sistemas de entretenimento veicular, aparelhos GPS, consoles de jogos, set-top boxes, impressoras multifuncionais, câmeras digitais, projetores, roteadores Wi-Fi, eletrodomésticos (Smart TVs de praticamente todos os fabricantes, sistemas de automação residencial e até mesmo geladeiras), além de plataformas para prototipagem eletrônica de hardware (Arduino, Raspberry Pi). No entanto, quase ninguém sabe disso.

Na referida conversa com maddog, aventamos a possibilidade de re-tomar uma antiga campanha, solicitando a todos os fabricantes de dis-positivos que usem o Linux como base tecnológica a utilização de um selo com os dizeres “Linux Inside” em seus produtos. Essa abordagem traria inúmeras vantagens tanto para o consumidor desse tipo de solu-ção quanto para o mercado em torno da tecnologia. Sempre que encon-trasse a indicação do uso de Linux em um equipamento, o consumidor saberia que se trata de tecnologia robusta e avançada: um sinônimo de qualidade. E o mercado, que já vive um momento de escassez de mão de obra de profi ssionais Linux sem precedentes, ganharia um impulso para a formação de novos técnicos com esse tipo de especialidade, já que o Linux estaria na boca de todos (leigos e profi ssionais).

Que tal abrirmos os olhos, então, e, enquanto essa campanha não vem, espalharmos a “novidade”? ■

Rafael Peregrino da SilvaDiretor de Redação

Was ich nicht weißExpediente editorialDiretor Geral Rafael Peregrino da Silva

[email protected]

Editores Flávia Jobstraibizer

[email protected]

Laura Loenert Lopes

[email protected]

Editora de Arte Larissa Lima Zanini

[email protected]

ColaboradoresAlexandre Borges, Augusto Campos, Cezar

Taurion, Charly Kühnast, Chris Binnie, Christoph

Langner, Falko Benthin, Gilberto Magalhães, Jon

‘maddog’ Hall, Jörg Luther, Klaus Knopper, Kurt

Seifried, Thomas Drilling, Thomas Leichtenstern,

Thomas Zeller, Tim Schürmann, Zack Brown.

Tradução Laura Loenert Lopes, Sebastião Luiz da

Silva Guerra, Emerson Satomi

Revisão Ana Carolina Hunger.

Editores internacionais Uli Bantle, Andreas Bohle, Jens-Christoph Brendel,

Hans-Georg Eßer, Markus Feilner, Oliver Frommel,

Marcel Hilzinger, Mathias Huber, Anika Kehrer,

Kristian Kißling, Jan Kleinert, Daniel Kottmair,

Thomas Leichtenstern, Jörg Luther, Nils Magnus.

Anúncios: Rafael Peregrino da Silva (Brasil)

[email protected]

Tel.: +55 (0)11 3675-2600

Penny Wilby (Reino Unido e Irlanda)

[email protected]

Amy Phalen (América do Norte)

[email protected]

Hubert Wiest (Outros países)

[email protected]

Diretor de operações Claudio Bazzoli

[email protected]

Na Internet: www.linuxmagazine.com.br – Brasil

www.linux-magazin.de – Alemanha

www.linux-magazine.com – Portal Mundial

www.linuxmagazine.com.au – Austrália

www.linux-magazine.es – Espanha

www.linux-magazine.pl – Polônia

www.linux-magazine.co.uk – Reino Unido

www.linuxpromagazine.com – América do Norte

Apesar de todos os cuidados possíveis terem sido tomados

durante a produção desta revista, a editora não é responsável

por eventuais imprecisões nela contidas ou por consequências

que advenham de seu uso. A utilização de qualquer material da

revista ocorre por conta e risco do leitor.

Nenhum material pode ser reproduzido em qualquer meio, em

parte ou no todo, sem permissão expressa da editora. Assu-

me-se que qualquer correspondência recebida, tal como car-

tas, emails, faxes, fotografi as, artigos e desenhos, sejam for-

necidos para publicação ou licenciamento a terceiros de forma

mundial não-exclusiva pela Linux New Media do Brasil, a me-

nos que explicitamente indicado.

Linux é uma marca registrada de Linus Torvalds.

Linux Magazine é publicada mensalmente por:

Linux New Media do Brasil Editora Ltda.

Rua São Bento, 500

Conj. 802 – Sé

01010-001 – São Paulo – SP – Brasil

Tel.: +55 (0)11 3675-2600

Direitos Autorais e Marcas Registradas © 2004 - 2012:

Linux New Media do Brasil Editora Ltda.

Impressão e Acabamento: Prol Gráfi ca

Atendimento Assinante

www.linuxnewmedia.com.br/atendimento

São Paulo: +55 (0)11 3675-2600

Rio de Janeiro: +55 (0)21 3512 0888

Belo Horizonte: +55 (0)31 3516 1280

ISSN 1806-9428 Impresso no Brasil

4 www.linuxmagazine.com.br

CAPA

Sem confl itos 33

Acabaram-se os tempos traumatizantes onde sistemas distintos geravam problemas quando presentes em uma mesma rede.

Combinação perfeita 34

Com alguns poucos truques é possível fazer com que instalações Windows conversem com partições ext Linux.

Inicialização dupla 38

Fazer o Windows funcionar bem com uma instalação Linux preexistente é difícil. Mas, com alguns truques, é possível confi gurar o Windows 8 em dual-boot com Linux.

Amigos convidados 42

Como o Windows 8 funciona em uma máquina virtual? Testamos a última versão do Windows como um sistema hóspede no VMware Workstation e no VirtualBox para Linux.

Linux e Windows 8 na rede 46

A confi guração do Samba pode falhar quando ignoramos pequenas coisas. Neste artigo, mostraremos como confi gurar um sistema Linux para compartilhamento de arquivos em uma rede Windows 8 ponto a ponto.

ÍND

ICE





5

ANÁLISEClique para o futuro 72

O HTML5 oferece uma série de recursos que não necessitam de plugins Flash ou Java para funcionar. Com isso, surgem novas opções de acesso móvel a aplicativos na rede local.

SEGURANÇALicença para gerenciar 60

Se oferecermos a usuários supervisionados mais espaço para ajudarem a si mesmos, eles precisarão de privilégios adicionais. A ferramenta sudo e o serviço de autorização PolicyKit podem controlar quem faz o que no Linux.

REDESO melhor amigo do administrador 56

O excelente Netcat é muitas vezes referenciado como o “canivete suíço” de redes; dizer que ele é versátil é o maior eufemismo que podemos usar para conceituar esta ferramenta.

SERVIÇOSEditorial 03Emails 06Linux.local 78Preview 82

Linux Magazine #98 | Janeiro de 2013

| ÍNDICELinux Magazine 98

COLUNASKlaus Knopper 08

Charly Kühnast 10

Augusto Campos 11

Alexandre Borges 12

Kurt Seifried 14

Zack Brown 18

NOTÍCIASGeral 20

➧ Slax volta à vida depois de anos paralisado

➧ Linux não irá mais funcionar em máquinas i386

CORPORATENotícias 22

➧ Cinco novos membros fi liam-se à Linux Foundation

➧ Oracle do Brasil muda-se para um novo escritório em São Paulo

Entrevista com Djalma Andrade 23

Entrevista com Nuno Simões 26

Coluna: Jon “maddog” Hall 28

Coluna: Cezar Taurion 30

Coluna: Gilberto Magalhães 32

ANDROIDAdeus aos indesejados 54

Chamadas irritantes de telemarketing ou perseguidores anônimos atormentam a sua vida com ligações fora de hora? Aplicativos criados especifi camente para bloquear chamadas e mensagens

de texto livram a sua vida desses problemas rapidamente. .

TUTORIALGerenciamento distribuído 66

Conheça o Git, sistema distribuído de controle de versão que garante a integridade e consistência de dados com segurança e esforço mínimo.














11Linux Magazine #XX | Mês de 200X

CO

LU

NA

Coluna do Augusto

Novo membro da Internet SocietyUma refl exão acerca da adesão da

Fundação Mozilla à Internet Society.

Neste início de ano gostaria de provocar a refl e-xão de todos a partir de uma notícia que quase passou despercebida no fi nal de 2012: a adesão

da Fundação Mozilla à Internet Society , na condição de membro na categoria Prata.

A Internet Society (ISOC), fundada em 1992, é uma organização internacional (com sedes em Washington e Genebra) sem fi ns lucrativos e relativamente discreta – é até possível que você jamais tenha ouvido falar nela.

Mas esta organização tem atuação fundamental no funcionamento da Internet, oferecendo liderança nos processos de defi nição de padrões e políticas relaciona-dos à rede, sempre associados à sua missão de assegurar o uso, evolução e desenvolvimento abertos da Internet para o benefício de todas as pessoas do mundo.

Um dos produtos mais visíveis da ISOC, lançados por meio do IETF (organização técnica ligada a ela) são as RFCs, documentos que propõem e defi nem pa-drões e protocolos como o HTTP e os diversos serviços de e-mail, autenticação e tudo o mais que trafega entre nossos desktops e servidores.

A Mozilla agora faz parte dessa estrutura. Não é pro-priamente uma novidade, pois ela já vinha participando ativamente de grupos de trabalho do IETF há anos. Mas com o passar dos anos, as atividades da Mozilla foram se aproximando cada vez mais das camadas básicas de soft-ware (afi nal, agora ela faz até sistema operacional), e se aproximando de um número cada vez maior de grupos.

Uma coisa leva a outra, e no fi nal de 2012 a Mozilla acabou se inscrevendo como membro do ISOC, na categoria Prata, o que corresponde a uma contribuição anual de US$12.500 para a organização – que a Mozilla destaca estar em sintonia com sua própria missão de promover a abertura, inovação e oportunidade na web.

Não é pouca coisa: na mesma categoria estão empresas como Google, as operadoras de telefonia Verizon e AT&T e a fabricante de equipamentos de conectividade Huawei.

As mudanças pelas quais a Mozilla – cujos recursos fi nanceiros provêm majoritariamente de um acordo com o Google –, passou recentemente foram muitas: aderiu ao codec proprietário H.264, passou a oferecer integração aos serviços do Facebook no Firefox, anunciou seu pró-prio sistema operacional para celulares e outros projetos.

Agora, na virada do ano, ver a Fundação Mozilla in-fl uenciando de forma direta o desenvolvimento dos padrões para os quais iniciou desenvolvendo aplicativos-clientemostra uma direção importante na qual a Mozilla avançou desde 2003, e um exemplo de relevância das organizações de código aberto. ■

Augusto César Campos é administrador de TI e, desde 1996, mantém o

site BR-linux.org, que cobre a cena do Software Livre no Brasil e no mundo.

Agora, na virada do ano, ver a Fundação Mozilla infl uenciando de forma

direta o desenvolvimentodos padrões para os quais

iniciou desenvolvendoaplicativos-cliente mostra

uma direção importante na qual a Mozilla avançou

desde 2003, e um exemplo de relevância das organizações

de código aberto.

12

CO

LU

NA

www.linuxmagazine.com.br

Coluna do Alexandre Borges

NMAP –sexta parte Conheça as ferramentas específi cas para

escaneamento de rede, do Nmap.

Quando iniciei esta série de colunas a respeito do NMAP, meu objetivo foi lançar alguma luz sobre o excelente uso desta ferramenta (que

todo mundo conhece e já precisou utilizar em algum momento) e tentar mudar o conceito de que “usar o NMAP é trivial” pois, sinceramente, acredito que não seja. É por isso que vou reapre-sentar outras alternativas de escaneamento de redes este mês.

Muitos analistas sempre comentam a respeito dos tipos XMas, FIN and NULL de escaneamento e o quanto eles podem ajudar na terefa de desco-brir eventualmente portas abertas em sistemas que não apresentaram respostas convicentes quando testados com opções conhecidas do NMAP. É ver-dade e isto tem um bom fundo de razão. Existem diversos firewalls com regras voltadas para pacotes SYN, ACK, RST, e regras com outros parâmetros TCP são esquecidas, o que tem o potencial de re-velar informações interessantes. E como são estes modos de escaneamento?

XMas (opção -sX): é um escaneamento onde o NMAP envia pacotes combinando os parâmetros FIN, PUSH e URG. Muitos fi rewalls ignoram esta possibilidade. Exemplo:

# nmap -sX 192.168.1.1

FIN (opção -sF ): o NMAP envia pacotes apenas com o parâmetro FIN setado em 1. Exemplo:

# nmap -sF 192.168.1.1

Null (opção -sN ): são enviados pacotes sem qualquer parâmetro setado em 1. Exemplo:

# nmap -sN 192.168.1.1

Em todos estes casos, quando nenhuma res-posta é recebida, a porta ou está aberta ou foi fil-trada (a resposta foi bloqueada pela presença de um firewall).

Existem dois problemas cruciais nestes modos de escaneamento: o primeiro é que alguns siste-mas operacionais como Windows e equipamen-tos da CISCO simplesmente ignoram a RFC 793 (que, entre outras coisas, diz que, para qualquer pacote que não contenha SYN, ACK ou RST não deve ser retornada qualquer resposta caso a porta esteja aberta ou que deve ser retornado um pacote com o parâmetro RST caso a porta esteja fechada). Em outras palavras, este tipo de escaneamento pode ser eficaz contra máquinas UNIX onde não importa qual a combinação de URG, PSH e FIN façamos uso, entretanto é inútil contra máquinascom Windows.

O segundo problema advém facilmente da ex-plicação do primeiro obstáculo já que, mesmo em sistemas que seguem a RFC 793, se não há resposta por parte dos mesmos no caso de porta aberta, como podemos interpretar isto? Se o NMAP não recebe resposta, o motivo pode ser porque o fi rewall a blo-queou ou ainda porque a porta está de fato aberta. Isso sem dúvida torna este modo de escaneamento ambíguo e seu valor apenas é evidente quando com-parado com outros escaneamentos no mesmo alvo para que possamos confi rmar se uma porta está de fato aberta ou fechada.

Indo além, uma opção interessante e usual é a opção -sA , que realiza um escaneamento usando pacotes com o parâmetro ACK setado. A ideia não é avaliar se a porta está ou não aberta (onde a res-posta para escaneamentos destes tipo sempre retorna

13Linux Magazine #XX | Mês de 200X

um pacote com o parâmetro RST), e sim, se existe ou não um firewall do tipo stateful bloqueando as portas de interesse (retornando filtered ou unfilte-red ). Este é um ponto que vale a pena ressaltar: o ACK é muito útil quando utilizado em conjunto com outros tipos de escaneamento de modo que ele mesmo pode confirmar a resposta obtida pois, às vezes, ficamos na dúvida quanto a resposta (por-ta aberta ou filtrada). Um comando de exemplopode ser:

# nmap -sA -T3 192.168.1.1

De maneira similar, todavia com resposta dife-rente do ACK, existe o TCP Windows Scan, que é implementado pela opção -sW explorando diferenças de implementações da pilha TCP e, com isso, sendo capaz de distinguir entre portas abertas e fechadas. Já encontrei situações onde este método combinado com outros pode ser usado para confi rmar o estado de uma porta. Um exemplo é:

# nmap -sW -T2 192.168.1.1

É incrível, mas estes não são os únicos escaneamen-tos “esotéricos”. É factível utilizar a opção --scanflags para realizar outros conjuntos de regras que, eventu-almente, podem contornar um fi rewall. Exemplo:

# nmap --scanflags SYNFIN 192.168.1.1Starting Nmap 6.01 ( http://nmap.org ) at 2012-12-10 18:36 BRST

Nmap scan report for 192.168.1.1Host is up (0.026s latency).Not shown: 998 closed portsPORT STATE SERVICE80/tcp open http113/tcp filtered identMAC Address: 98:FC:11:C8:73:86 (Cisco-Linksys) Nmap done: 1 IP address (1 host up) scanned in 14.89 seconds

Por favor, repare que não incluí estes parâmetros ape-nas por acaso, pois muitos fi rewalls (dependendo) de suas confi gurações têm por hábito bloquear pacotes que possuem apenas parâmetros SYN setados, entretanto, não tomam qualquer ação com relação à combinações como a apresentada. Existem outras combinações de parâmetros que podem resultar em sucesso: SYN+URG, SYN+RST e SYN+URG+FIN+PSH.

No mês que vem volto com a última parte deste mini tutorial a respeito de Nmap. Até mais. ■

Alexandre Borges (linkedin: br.linkedin.com/in/aleborges) é instrutor e especia-

lista sênior em sistemas operacionais Unix, Linux, Banco de Dados, Virtualiza-

ção, Cluster, Storage, Servidores, Backup, Desempenho e Segurança, além

de possuir profundo envolvimento com assuntos relacionados ao kernel Linux.

www.impacta.com.br

Windows 8

Sem confl itos Acabaram-se os tempos traumatizantes onde sistemas distintos

geravam problemas quando presentes em uma mesma rede.

por Flávia Jobstraibizer

Atualmente não existem mais grandes problemas relacionados à convivência entre sistemas Win-dows e Linux em uma mesma rede. É possível

operar entre os distintos sistemas de arquivos dos dois sistemas, operar aplicativos em uma camada de compa-tibilidade e até mesmo compartilhar dos mesmos usuá-rios, através de ferramentas como OpenLDAP e Active Directory. Tudo isso sem confl itos e sem percalços.

Nesta edição da Linux Magazine , vamos abordar a incrível ferramenta Samba, utilizada mundialmente para realizar a compatibilidade entre Windows e Linux através do protocolo SMB. O Samba é uma ferramen-ta imprescindível nos ambientes mistos com os quais comumente nos deparamos no dia a dia.

Tão imprescindível quanto o Samba, fazer com que o Windows acesse e trabalhe harmoniosamente com partições Linux é um desafi o que pode ser resolvido através de algumas incríveis ferramentas que apresen-taremos nessa edição.

Com o lançamento da nova versão do Windows e tantas especulações que envolvem o UEFI, surgiram muitas dúvidas sobre o bom funcionamento do sistema operacional da Microsoft em conjunto com o Windows. Saiba tudo o que envolve a instalação e uso de sistemas dual-boot com as novas versões das distribuições.

E em uma edição recheada de informações sobre o Windows 8, não poderia faltar um artigo sobre o fun-cionamento deste em máquinas virtuais! Saiba como funciona o Windows 8 em VMs Virtualbox no Linux!

Também imperdível é a entrevista que realizamos com Djalma Andrade, da Microsoft e que aborda não só o tema de interoperabilidade, mas também as acade-mias da interoperabilidade entre sistemas open source e Windows criadas pela Microsoft e que auxiliam na capacitação de profi ssionais ligados à sistemas mistos.

Enfi m, uma edição imperdível, para começar 2013 com o pé direito!

Boa leitura! ■

Matérias de capaCombinação perfeita 34

Inicialização dupla 38

Amigos convidados 42

Linux e Windows 8 na rede 46

CA

PA






SEÇÃO | Matéria

Bloqueio de chamadas e SMS

Adeus aos indesejados

Chamadas irritantes de telemarketing ou perseguidores anônimos

atormentam a sua vida com ligações fora de hora? Aplicativos

criados especifi camente para bloquear chamadas e mensagens

de texto livram a sua vida desses problemas rapidamente.

por Christoph Langner e Flávia Jobstraibizer

Comumente somos importu-nados por ligações (ou men-sagens de texto) de pessoas

com as quais não desejamos mais falar. Estas podem ser: vendedores insistentes, ex-namorados e até mes-mo propagandas de partidos políticos – e que podem ser consideradas spam quando enviadas através de não soli-citadas mensagens de texto. Conheça neste artigo algumas das ferramentas mais poderosas para bloquear estes intrusos efetivamente e esqueça-se deles por completo!

Root Call Blocker Pro A maioria das perturbações sofri-das através de mensagens de texto ou ligações indesejadas deveriam ser esclarecidas diretamente com uma simples conversa ou até mes-mo uma denúncia, mas você tam-bém pode lutar contra isso com pura tecnologia. Na Play Store há inúmeros aplicativos bloqueadores de chamadas e SMSs que evitam esse tipo de aborrecimento. Mui-tos destes aplicativos, no entanto, são uma catástrofe: tecnicamente mal implementados e com inter-faces de difícil uso, bem diferente de um aplicativo excelente, o Root Call Blocker (versão Pro), que nos causou uma boa impressão.

O aplicativo destaca-se em nossa seleção por possuir uma superfície bem implementada e foco na tarefa principal. O aplicativo realizou seu trabalho perfeitamente e não é cheio de recursos inúteis, entretanto requer acesso root , já que, para livrar o usuário de chamadas indesejadas ele acessa as entranhas do sistema. A versão gratuita do aplicativo é apenas demonstrativa e só pode gerenciar uma entrada na lista negra que na versão Pro (vendida

por R$14,00 na loja do Google) pode ser individualmente modelada pelo u-suário, permitindo a entrada manual de contatos individuais ( fi gura 1 ) ou a partir do seu catálogo de endereços. Seu recurso principal é bloquear to-dos os números que comecem com 0800 ou 0300 ( fi gura 2 ), por exem-plo. Ele também permite bloquear automaticamente todas as chamadas telefônicas, exceto as de seus contatos armazenados na agenda. O aplicativo

Figura 2 Bloqueio por todas as

chamadas oriundas de 0800 .

Figura 1 Inclusão manual de usuários

indesejados.

AN

DR

OID

55

| ANDROIDBloqueio de chamadas e SMS


pode encaminhar chamadas direto para a caixa postal ou ignorá-la com-pletamente, de modo que a pessoa que está ligando ouve o sinal de cha-mada, mas nada acontece no telefone que está recebendo a chamada – um recurso único deste aplicativo. Desta forma, o insistente ligador (ou a sua sogra) não irá sequer desconfi ar de que está sendo bloqueado por você. Perfi s diferentes, agenda de horários para bloqueios e respostas por SMS geradas automaticamente completam os recursos deste aplicativo.

Recursos do Android Nem sempre você precisa de um aplicativo externo: o Android possui nativamente o recurso de encami-nhamento de chamadas diretamente para a caixa postal. A opção pode ser encontrada em sua agenda de conta-tos e confi gurada separadamente para cada contato cujas chamadas devem ser encaminhadas diretamente para a caixa postal. Caso algum desses contatos bloqueados tentem entrar em contato, o telefone não emitirá nenhum som. O usuário não será sequer informado sobre a chamada recebida a menos que o contato dei-xe um recado em sua caixa postal. O fi ltro é limitado apenas à chamadas, os SMS ainda poderão chegar até sua caixa de entrada. A localização deste recurso pode variar. Na versões an-teriores ao Android Jelly Bean, pode ser encontrada em Confi gurações (ou Confi g ), Confi gurações de chamada , Lista de números permitidos . No Jelly Bean a opção fi ca em Confi gurações , Modo de bloqueio , Contatos permitidos .

NQ Call Blocker A versão básica gratuita e suportada por anúncios do NQ Call Blocker cumpre o que promete. Chamadas ou SMS de contatos que foram colocados por você na lista negra, são bloqueadas pelo aplicativo de forma confi ável ( fi gura 3 ). Caso queira, o aplicativo ainda informa sobre as chamadas e

mensagens recebidas – desta forma, mensagens de texto bloqueadas ain-da podem ser lidas posteriormente.

GData Mobile Security 2 Se você instalou o GData Securi-ty Mobile 2 apenas para bloquear chamadas indesejadas e SMS, está naturalmente usando uma bazuca para matar uma mosca. O bloquea-dor de chamadas e SMS funcionou de forma confi ável em nossos testes. As chamadas bloqueadas podem ser vistas posteriormente em uma lista, mas os SMS desaparecem no limbo, sem que haja a menor possibilidade de você poder retornar o chamado. E pela bagatela de quase R$46,00, o aplicativo é um tanto quanto sal-gado para fazer o mesmo que outros aplicativos mais baratos (ou até gra-tuitos) fazem ( fi gura 4 ).

BlackList O BlackList perdeu pontos já na primeira vez em que foi executa-do. Na tela de boas-vindas, uma

imagem de propaganda para um completamente inútil Ram Booster de outro desenvolvedor foi exibida de forma insistente (propagandas não são encontradas na versão Pro, que custa cerca de R$7,00). É ne-cessário gastar algum tempo para acostumar-se com a interface um tanto confusa e coalhada de anún-cios que aparecem do nada. Toda-via, ele cumpriu a sua missão em nosso teste. Interessante é o recurso de enviar automaticamente uma mensagem de texto SMS com os dados da ligação bloqueada.

Existe uma infi nidade de aplicati-vos destinados exclusivamente à blo-queio de chamadas e mensagens. Se nenhum destes atendeu à sua neces-sidade e você encontrou aplicativos melhores (ou perfeitos), não deixe de nos contar sua experiência! ■

Figura 4 O Mobile Secutiry é

relativamente caro por

fazer o mesmo que seus

concorrentes gratuitos.

Figura 3 O aplicativo fornece um

relatório das chamadas e

SMSs bloqueados.

Gostou do artigo?Queremos ouvir sua opinião. Fale conosco em [email protected]

Este artigo no nosso site: http://lnm.com.br/article/8112

sso sr/artic

sua om

ne.com

e:811

igo?nião.


SEGURANÇA | Sudo e PolicyKit

Sudo e PolicyKit

Licença para gerenciar Se oferecermos a usuários supervisionados

mais espaço para ajudarem a si mesmos, eles

precisarão de privilégios adicionais. A ferramenta

sudo e o serviço de autorização PolicyKit

podem controlar quem faz o que no Linux.

por Tim Schürmann

Para os administradores, seria um alívio se os usuários regulares fossem capazes de lidar com

tarefas menores de gerenciamento, tais como atualização de software. O único problema é que o apt-get requer privilégios administrativos e o leitor possivelmente não iria desejar concedê-los a um usuário leigo. Fe-lizmente, os administradores podem contar com o sudo ou com o serviço de autorização PolicyKit para permitir ações específi cas de forma orientada.

Sudo As ferramentas sudo executam co-mandos com uma conta de usuário diferente. Para o apt-get upgrade , este seria um usuário todo-poderoso. Quais

usuários possuem permissão para usar o sudo e com quais programas está defi nido no arquivo de confi guração /etc/sudoers . Por exemplo, para per-mitir que o usuário klaus atualize seu próprio computador chamado marvin , devemos adicionar a seguinte linha ao arquivo /etc/sudoers :

klaus marvin=(ALL) NOPASSWD: /usr/bin/apt-get upgrade

A linha começa com o nome do u-suário e é seguida pelo host onde klaus tem permissão para executar o coman-do. Neste caso, ele deve trabalhar em seu próprio computador, marvin . Se klaus visualizar a mensagem de erro klaus is not allowed to run sudo on... ao executar o apt-get upgrade , isto

provavelmente tem algo a ver com a resolução de nomes. O administrador deve verifi car se os hostnames especi-fi cados batem com a saída do coman-do hostname e fazer uma verifi cação cruzada com o conteúdo do arquivo /etc/hosts . Especifi car ALL ao invés do hostname, signifi ca que klaus pode executar o apt-get upgrade em qualquer máquina. Como uma alternativa para o hostname, podemos também especi-fi car o endereço IP. Para um intervalo de endereço, basta defi nir a subrede:

klaus 192.168.2.0/255.255.255.0= (ALL)NOPASSWD:/usr/bin/ apt-get upgrade

Neste caso, o usuário klaus só pode executar o comando se trabalhar em uma máquina com um endereço IP no intervalo de 192.168.2.1 a 192.168.2.254 . O sudo executa um comando em uma conta de usuário diferente. Os detalhes dos parênteses especifi cam quais con-tas klaus pode escolher. Especifi car tim signifi caria que klaus só poderia iniciar o programa como usuário tim. ALL permite que klaus escolha qualquer conta de usuário, incluindo o usuário root necessário para o apt-get :

sudo -u root apt-get upgrade

A opção -u para o usuário deseja-do é opcional no caso do root. Antes do sudo executar o comando apt-get upgrade , klaus normalmente precisa

Figura 1 No Linux Mint, a chamada para visudo só protege o arquivo sudoers

contra um acesso mais detalhado e, então, chama o nano.

SE

GU

RA

NÇ

A

61

| SEGURANÇASudo e PolicyKit


digitar sua senha. Isto não é necessário se colocarmos NOPASSWD: na frente do nome do programa no arquivo de con-fi guração. O comando a ser executado vem no fi nal da linha. Se quisermos deixar klaus executar vários programas ou comandos, basta acrescentarmos uma lista separada por vírgulas:

klaus marvin=(ALL)NOPASSWD:/usr/ bin/apt-get update,/usr/bin/ apt-get upgrade

Neste caso, klaus pode atualizar o banco de dados de pacotes e instalar atualizações, mas não pode instalar novos programas. O ALL universal pode ser também usado para outros parâmetros. A linha a seguir torna klaus equivalente ao usuário root :

klaus ALL=(ALL) ALL

Como uma alternativa para usuá-rios individuais, o arquivo sudoers tam-bém pode conceder acesso a todos os membros de um grupo, como admin:

%admin ALL=(ALL) ALL

O sinal de porcentagem declara ao sudo que este é um grupo e não um usuário individual, que é como o Ubuntu concede acesso aos recursos do sistema a todos os administrado-res. A listagem 1 mostra o arquivo de confi guração sudoers para o Ubuntu; deixamos de fora os comentários para facilitar a leitura: root, os usuários do grupo admin e sudo podem fazer tudo, e os demais usuários não podem fazer nada. O segundo ALL entre parênteses indica o nome do grupo com per-missão de acesso; assim, klaus pode executar o comando como qualquer usuário de qualquer grupo.

Cada linha que começa com Defaults altera uma confi guração padrão no sudo. Na listagem 1 , env_reset redefi ne as variáveis de ambiente, e secure_path defi ne a variável PATH (ou seja, os dire-tórios onde o Linux pode encontrar os programas a serem executados). Ambas as medidas são projetadas para tornar ataques mais difíceis. Normalmente,

o sudo guarda a senha introduzida. A linha a seguir também é útil:

Defaults timestamp_timeout=15

Ela declara que o sudo deve esque-cer a senha para todos os usuários após 15 segundos. Se a defi nirmos para 0 , os usuários precisarão digitar suas senhas cada vez que executarem o sudo. Para os outros padrões, veja a página man ( man 5 sudoers ).

Dentro de /etc/sudoers , um ponto de exclamação nega uma defi nição. Isto permite que o administrador pre-vina klaus de executar um programa específi co. Para fazer isso, basta adicio-nar um ponto de exclamação na frente do nome do programa. No exemplo a seguir, klaus não tem permissão para reinicializar o computador:

klaus marvin=(ALL) !/sbin/reboot

Todas as chamadas sudo fracassa-das geralmente acabam no arquivo syslog, enquanto o Ubuntu usa o arquivo /var/log/auth.log . Desta

forma, podemos descobrir qual u-suário sofreu interferência.

Dança perigosa O sudo é perigoso em vários aspectos. Por exemplo, apenas um pequeno erro de digitação ou uma exclamação fora de lugar podem bloquear completa-mente o sistema. Note que isso pode acontecer com regras que podemos esperar que não possuam tal efeito.

Portanto, os administradores só de-vem editar o arquivo /etc/sudoers com a ferramenta visudo criada expressamente para este fi m. Entre outras coisas, este editor verifi ca a sintaxe do arquivo de confi guração. Contrariamente ao que o vi no nome implica, o editor subja-cente em algumas distribuições hoje é o nano ( fi guras 1 e 2 ). No Ubuntu, a ferramenta deixar passar erros de digi-tação óbvios em nosso laboratório, por isso não devemos confi ar demais nela.

Em muitas distribuições Linux, é prática padrão alterar as regras escri-tas em um arquivo de confi guração

Figura 2 O OpenSUSE usa o famoso vi, que suporta syntax highlighting –

ainda que seja um pouco exagerada.



separado e armazená-las no diretório /etc/sudoers.d . A linha :

#includedir /etc/sudoers.d

em /etc/sudoers garante que o sudo leia automaticamente e avalie todos os arquivos de texto no diretório /etc/sudoers.d . O # do início da linha não introduz um comentário; é parte do comando. Com a terceirização, um administrador pode simplesmente excluir os arquivos de confi guração adicionais para retornar o antigo es-tado, no caso de um erro.

No entanto, a cautela também é aconselhada com estas regras adicio-nais. Se klaus no exemplo a seguir também for membro do grupo admin , ele pode executar qualquer ferramenta do sistema – não apenas /sbin/reboot : klaus marvin=(ALL) NOPASSWD:/sbin/reboot

%admin ALL=(ALL) ALL

Em um ambiente de produção, as dependências para quais regras estão sujeitas nem sempre são tão evidentes.

Como mitigar o risco Para acessar as ferramentas do sistema, o sudo utiliza o bit setuid . O coman-do, portanto, sempre executa com privilégios de root . Apenas o próprio sudo impede um usuário comum de executar comandos de forma arbitrá-

ria no sistema. Para descobrir quais direitos são concedidos ao sudo, po-demos simplesmente digitar sudo -l .

Executar o comando sem uma senha, especifi cando NOPASSWD , é conveniente para os usuários. No entanto, a prática também é arriscada, pois um usuário poderia executar comandos sem pensar que comprometeriam o sistema, e um malware poderia iniciar ferramentas de sistema em segundo plano, sem que o administrador percebesse.

Finalmente, devemos sempre es-pecifi car o caminho completo para os programas; caso contrário, o sudo deixaria de executar o apt-get original, mas executaria um programa malicioso com o mesmo nome que tenha sido injetado no caminho de pesquisa.

Serviço deautorização PolicyKit O PolicyKit habilmente trilha seu caminho em torno de problemas de permissão e riscos de segurança [1] com uma abordagem completamen-te diferente: se o usuário klaus deseja instalar um pacote, o gerenciador de pacotes primeiro pergunta ao PolicyKit se esta é uma ação permitida.

O PolicyKit pode então imediata-mente oferecer o sinal verde para que klaus siga em frente ou então solicita

uma senha. Em contraste com o sudo, o PolicyKit regula recursos (de sistema) individuais. Assim, o administrador pode permitir que klaus atualize pacotes e permita a instalação de novos pacotes.

O PolicyKit passou por uma mu-dança de conceito durante seu de-senvolvimento. A versão atual é nor-malmente referida como PolicyKit-1 , ou, abreviadamente, polkit. De forma um tanto confusa, não chegou a se tornar versão 1; a versão mais recente quando do fechamento desta edição era a 0.107. Apesar do zero na frente do ponto, o sistema PolicyKit é estável em distribuições como Ubuntu, Fedora e openSUSE – e tem sido assim há anos.

A essência do PolicyKit é o servi-ço polkitd . Como ele só precisa res-ponder a solicitações de ferramentas

Quadro 1: Programa de ação Policykit Ferramentas do sistema primei-

ro precisam registrar as ações su-

portadas com PolicyKit, para que

cada programa armazene um ar-

quivo XML no subdiretório /usr/share/polkit-1/actions para esta

fi nalidade. Por exemplo, os servi-

ços oferecidos pelo Network Ma-

nager estão localizados no arquivo org.freedesktop.NetworkManager.policy. Uma ação ligeiramente re-

duzida é mostrada na listagem 3.

O id= na linha 1 é seguido pela men-

sagem D-Bus enviada pelo programa;

o <description> na linha 2 fornece

uma breve descrição da ação, e <men-sagem> é a mensagem que o usuário

visualiza na tela de senha. Para cada

ação, o desenvolvedor do programa

pode defi nir permissões padrão den-

tro do elemento <defaults> (linhas 4 a 7). No exemplo acima, apenas os

administradores são autorizados a

modifi car a confi guração da rede. Os

detalhes e valores possíveis aqui cor-

respondem aos dos arquivos .pkla.

Nunca devemos modifi car os arqui-

vos .policy diretamente: por um

lado, isso poderia causar uma vul-

nerabilidade; de outro, a distribui-

ção poderia sobrescrever suas al-

terações durante a atualização do

sistema. É melhor, portanto, usar

seu próprio arquivo .pkla. Figura 3 Um agente de autenticação no Ubuntu. Ao expandir a janela de detalhes,

a tela mostra a ação para a qual o programa solicita autorização.

Tabela 1 Diretórios para regras PolicyKit .

Diretório: Objetivo:

10-vendor.d / Regulamentação de fornecedor

20-org.d Regras por parte da organização que faz a distribuição

30-org.d Regras por parte do site que faz a distribuição

50-local.d Regras próprias ou locais

90-mandatory.d Regras por parte da organização que faz a distribuição

63



do sistema, é executado em uma conta restrita. Portanto, ninguém pode usá-lo para roubar o sistema. O polkitd fornece seus recursos através do sistema de comunicação D-Bus .Como alternativa, os programas podem usar também a biblioteca libpol-kit-gobject-1 , que encapsula as chamadas D-Bus correspondentes.

Um componente LocalAuthority ve-rifi ca se a ação solicitada pelo PolicyKit é permitida. Como o nome indica, sua decisão leva em conta as contas de usuá-rios e grupos que existem localmente no computador. Se uma entrada de senha é necessária, o PolicyKit chama um agente de autenticação. Este agente consiste basicamente de uma máscara

de entrada ( fi gura 3 ). Cada ambiente de trabalho pode fornecer seu próprio agente de autenticação.

Regulador Para conceder ao usuário o acesso a um recurso do sistema, o admi-nistrador precisa criar uma regra correspondente. Todas as regrasPolicyKit estão reunidas no diretório /etc/polkit-1/local-authority . Aqui também encontraremos cinco subdi-retórios nos quais as regras são distri-buídas, dependendo de suas origens.

A tabela 1 mostra quem precisa dispor de quais regras e em quais di-retórios. Os administradores podem se concentrar no diretório 50 local.d . O LocalAuthority lê todos os arqui-vos armazenados lá com um sufi xo .pkla em ordem alfabética crescente.

Classifi cação ordenada Para permanecermos no caminho quando escrevemos as regras, devemos sempre começar o nome do arquivo com um número em ordem crescente. Os arquivos de regras são arquivos de texto simples, e podemos agrupar vá-rias regras em um arquivo. Note que os arquivos .pkla precisam de nomes únicos. O PolicyKit se refere às regras de acesso como entradas de autoriza-ção. A listagem 2 mostra uma regra que permite que o usuário klaus altere as

confi gurações globais de rede no Ne-twork Manager . Um comentário nos colchetes introduz a regra. Identity= mostra quais usuários ou grupos de usuários são afetados pela regra. Na linha 2 , encontra-se alguém com uma conta de usuário local ( unix-user: ) e o nome de usuário klaus . Vários usuários ou grupos são separados no arquivo por ponto-e-vírgula. A linha :

Identity=unix-user:klaus; unix-group:networkers

permitiria que o grupo inteiro de usuá-rios, e não apenas klaus , modifi casse as confi gurações de rede. A linha Action= na listagem 2 é acompanhada pelo nome da ação permitida. O comando pkaction revela quais ações são conheci-das pelo PolicyKit. Cuidado; a saída da lista por este comando pode ser longa, dependendo da distribuição ( fi gura 4 ).

Normalmente, o nome da ação diz o que ela faz. Se quiser saber exata-mente o que acontece, execute pkac-tion com o nome da ação ( fi gura 5 ): pkaction --verbose--action-id org.freedesktop.NetworkManager. settings.modify.system

Faz sentido redirecionar a lista completa e detalhada em um arqui-vo, por exemplo:

pkaction --verbose > actions.txt

As ações disponíveis dependem da distribuição e os programas instala-dos ( quadro 1 ). Várias ações podem ser combinadas em uma única regra com o curinga “*” . A linha :

Identity=org.freedesktop. NetworkManager.*

Quadro 2: Como executar O PolicyKit inclui a ferramenta de

linha de comando pkexec, que ini-

cializa um programa em outra con-

ta de usuário e, portanto, substitui

o sudo – pelo menos, esta é a ideia

básica. O comando:

pkexec --user klaus apt-get update por exemplo, executaria o comando

apt-get update como usuário klaus.

Infelizmente, apenas administrado-

res podem executar o pkexec, por

razões de segurança. Além disso, o

pkexec inicializa o comando apt-getupdate no contexto de autorização

do usuário klaus. No entanto, por

padrão, este usuário não possui

permissão para executar o apt-get update, e não podemos conceder-lhe

estes direitos pois o apt-get sim-

plesmente ignora o PolicyKit e só se-

gue as permissões-padrão do Unix.

As ações conhecidas no PolicyKit,

org.debian.apt.update-cache,

referem-se ao aptdaemon [2].

Em outras palavras, se quiser-

mos permitir que klaus execute o

apt-get, precisamos utilizar o sudo

com as regras correspondentes ou

adicionar klaus ao grupo de admi-

nistrador, e só então klaus poderia

iniciar o apt-get como usuário root.

Obviamente, muito pouco se ga-

nha com isso; mas, pelo menos, o

pkexec encaixota o programa em

um ambiente mínimo e endurecido,

impedindo ataques contra a variá-

vel de ambiente LD_LIBRARY_PATH.

Listagem 1: Arquivo Ubuntu 12.04 /etc/ sudoers 01 # Redefine environmental variables:

02 Defaults env_reset03 Defaults secure_path="/usr/ local/sbin:/usr/local/bin:/ usr/sbin:/usr/bin:/sbin:/bin"

04 05 # Permit access:06 root ALL=(ALL:ALL) ALL07 %admin ALL=(ALL) ALL08 %sudo ALL=(ALL:ALL) ALL0910 # Add more rules here:11 #includedir /etc/sudoers.d

Listagem 2: Regras para o LocalAuthority 01 Klaus is allowed to modify network

02 Identity=unix-user:klaus03 Action=org.freedesktop. NetworkManager.settings. modify.system

04 ResultInactive=no05 ResultActive=auth_self



deixaria klaus executar todos os recur-sos oferecidos pelo Network Manager.

Quem sou eu? O PolicyKit distingue entre pedidos que vêm de uma sessão ativa e aqueles que se originam de uma sessão inativa. O que fazer com as solicitações da sessão ativa é defi nido por ResultActive= . Na listagem 2 , klaus precisa, então, digi-tar sua própria senha ( auth_self ). No caso de uma sessão inativa, as regras seguem a aplicação do ResultInactive= .A linha 4 contém um no , que proíbe a alteração das confi gurações de rede no Network Manager. Além de auth_self e no , a tabela 2 resume alguns outros valores possíveis.

Como uma alternativa para ResultInactive e ResultActive , podemos especifi car ResultAny , que é o mesmo para as sessões ativas e inativas. Apenas uma destas três precisam fi gurar no arquivo .pkla ; as regras especifi cadas pela ação correspondente em seguida se aplicarão para qualquer coisa que esteja faltando ( quadro 2 ).

Se fôssemos salvar a listagem 2 como 51-org.freedesktop.NetworkMa-nager.pkla no diretório /etc/polkit-1/localauthority/50local.d , o PolicyKit automaticamente aplicaria as novas regras sem ter que reiniciar o serviço. Para mais exemplos de regras, confi ra o subdiretório var/lib/polkit-1/loca-lauthority/ , que só é acessível para

o usuário root. Este diretório arma-zena todas as regras que vieram com a distribuição. Para mais detalhes sobre a estrutura dos arquivos .pkla , veja a página man da ferramenta( man pklocalauthority ).

Onipotente Alguns recursos do sistema são tão pe-rigosos ou críticos que apenas um ad-ministrador de verdade está autorizado a executá-los; assim, o LocalAuthoritydistingue-se entre usuários regulares e administradores, que possuem o mesmo privilégio de root.

Os membros do grupo de elite de administradores são defi nidos pelos arquivos de confi guração em /etc/polkit-1/localauthority.conf.d . Mais uma vez, o LocalAuthority analisa to-dos os arquivos em ordem alfabética; confi gurações em arquivos posteriores sobscrescrevem os arquivos anterio-res. O administrador do sistema não deve alterar os arquivos existentes, mas adicionar um arquivo próprio, com um número maior, o que tam-bém signifi ca que a distribuição não substituiria o arquivo durante uma atualização de sistema. Por padrão, um arquivo de confi guração com-preende apenas duas linhas; por exemplo, no Ubuntu:

[Configuration]AdminIdentities=unix-group:sudo;unix-group:admin

O AdminIdentities= é seguido por todos os usuários e grupos que pos-suem os mesmos privilégios de root do ponto de vista do PolicyKit. Para adicionar klaus à este grupo de elite no Ubuntu, o usuário administrativo deve criar um novo arquivo chamado 99-Klaus.conf e adicionar:

[Configuration]AdminIdentities=unix-group: sudo;unix-group:admin; unix-user:klaus

Os dois grupos, sudo e admin , vêm de arquivos de confi guração existen-

Figura 4 O pkaction revela os nomes de todas as ações suportadas pelo

PolicyKit e dependem da distribuição utilizada.

65



tes, por isso é necessário adicioná-los; caso contrário, apenas klaus terá pri-vilégios de root.

Pouco suporte O PolicyKit oferece uma camada adicional de segurança no topo do sistema de autorização Unix exis-tente, mas não a substitui. Além disso, os programas do sistema en-volvidos devem suportar o PolicyKit ou solicitar o serviço. Atualmente, apenas algumas ferramentas de in-terface gráfi ca de usuário selecio-nadas fazem isso, como é o caso do Network Manager.

Todos os aplicativos de console, incluindo o apt-get , ignoram o Po-licyKit. Os problemas que essa con-fusão pode causar são apresentados no quadro 2 . No entanto, mesmo se um aplicativo suportar o PolicyKit, não precisará respeitar suas instru-ções; assim, um invasor poderá fa-cilmente contornar o PolicyKit com código malicioso.

Conclusão Tanto o sudo como o PolicyKit têm suas vantagens e desvantagens. Se quisermos permitir uma ação que o PolicyKit possua em seu repertó-rio, devemos criar um arquivo .pkla correspondente, o que signifi ca que estamos permitindo apenas os recur-sos necessários.

Os administradores não devem permitir que usuários regulares uti-

lizem o sudo, a menos que considere cuidadosamente as consequências, ou em caso de uma emergência: o risco é muito grande de que uma regra incorreta permita aos usuários fazer mais do que o administrador deseja, ou até mesmo o bloqueie do próprio sistema.

O Linux ainda carece de um sis-tema de permissões granulares. Para os casos em que os administradores desejam permitir o acesso a progra-mas de linha de comando, é uma boa ideia olhar para técnicas alternativas, tais como listas de controle de acesso ( Access Control Lists - ACLs) [2] . ■

Mais informações [1] PolicyKit: http://www.

freedesktop.org/wiki/Software/polkit

[2] Aptdaemon: https://launchpad.net/aptdaemon



sso sr/artic

sua om

ne.com

e:805

igo?nião.

Listagem 3: Arquivo Action (reduzido) 01 <action id="org.freedesktop.NetworkManager.settings. modify.system">

02 <description xml:lang="en">Modify network connections for all users</description>

03 <message xml:lang="en">System policies prevent you from modifying networksettings for all users</message>

04 <defaults>05 <allow_inactive>no</allow_inactive>06 <allow_active>auth_admin_keep</allow_active>07 </defaults>08 </action>

Figura 5 Aqui, o pkaction revela que a ação org.freedesktop.Network Manager.settings.modify.system permite que todos os

usuários modifi quem as defi nições de rede com o Network Manager.

Na última saída do comando estão as permissões padrão.

Valor: Signifi cado:

no O usuário não deve executar a ação

sob quaisquer circunstâncias.

yes O usuário pode executar a ação sem autenticação.

auth_self O usuário só pode executar a ação

depois de digitar sua senha.

auth_admin O usuário deve se autenticar como administrador

(e, portanto, saber a senha administrativa).

auth_self_keep

Como auth_self, mas o PolicyKit mantém a senha

digitada por alguns minutos. O usuário pode,

portanto, executar a ação várias vezes em sucessão,

mas só precisa digitar sua senha uma vez.

auth_admin_keep

Como o auth_admin, mas neste caso o PolicyKit

mantém a senha digitada por alguns minutos.

O usuário pode, portanto, executar a ação

várias vezes sucessivamente, mas só precisa se

autenticar como administrador uma única vez.

Tabela 2 Tipos de autorização do PolicyKit.


TUTORIAL | Controle de versão com Git

Controle de versão

Gerenciamento distribuído

Conheça o Git, sistema distribuído de controle de

versão que garante a integridade e consistência

de dados com segurança e esforço mínimo.

por Falko Benthin

Documentos e código-fonte que são utilizados, alterados e processados por vários

usuários estão muitas vezes loca-lizados em um servidor central de arquivos, enquanto os indivíduos trabalham com cópias locais. Pesqui-sar manualmente as diferenças entre documentos muitas vezes deixa dúvi-das quanto a existência de uma nova versão de um documento e, se assim for, quem o alterou pela última vez. Um sistema de controle de versão, como utilizado em muitos projetos de software, pode ajudar a arrumar a bagunça. Um dos candidatos mais fortes nesta área é o Git [1] .

O Git foi desenvolvido em 2005 por Linus Torvalds para gerenciar o código fonte do kernel Linux. Para fazer isso, precisou satisfazer uma série de requisitos:

➧ Tinha que ser rápido, oferecer suporte a várias ramifi cações parale-las, e ser capaz de trocar dados entre repositórios diferentes;

➧ Tinha que oferecer suporte a verifi cações de integridade de da-dos e evitar que objetos de dados armazenados no repositório fossem modifi cados retroativamente.

Comparado com outros sistemas de controle de versão, o Git é ca-racterizado pela sua suave curva de

aprendizado, redundância de dados através de repositórios locais, baixo consumo de memória, e serviços gra-tuitos, como o GitHub e o Gitorious.

Instalação O Git é um programa de linha de comando disponível para Linux, Mac OS X, Solaris e MS Windows. Não obstante, ele também contempla vá-rias interfaces gráfi cas, incluindo Gitk , Git-cola [2] , SmartGit [3] , giggle [4] , e Gitg [5] , bem como interfaces online como Gitweb , Cgit [6] , e Gitlab [7] .

O Git está nos repositórios da maioria das distribuições, por isso podemos instalá-lo facilmente usan-do as ferramentas de gerenciamento de pacotes adequadas. Se preferir a última versão, poderá instalar o sis-tema de controle de versões como root com três comandos: # ./configure# make all doc# make install install-doc install-html

TU

TO

RIA

L

Figura 1 Quando inicializamos, o Git não está interessado em saber se o

diretório está vazio ou já contém alguns arquivos.

67

| TUTORIALControle de versão com Git


após baixar o código fonte doGitHub [8] .

Como confi gurar O Git oferece amplas possibilidades para confi gurações globais, de usuá-rio e específi cas de um determinado projeto. Confi gurações globais do sistema são encontradas em /etc/gitconfig ; confi gurações do usuário estão no arquivo ~/.gitconfig no dire-tório home do usuário. Confi gurações que afetam apenas um único projeto são armazenadas em .git/config do repositório correspondente.

Neste artigo, cobriremos apenas as confi gurações mais importantes. Se o usuário, adicionalmente, quiser modifi car o esquema de cores, o editor para commitar e marcar mensagens, modelos de commit, confi gurações de diff e merge, ou recursos simi-lares; para tanto, deverá verifi car a man page do Git e a documentação do projeto [9] .

Um dos passos mais importantes é apresentar-se ao Git, fornecendo nome e endereço de email: # git config --global user.name "<firstname> <lastname>"

# git config --global user.email <my>@<email>.<ext>

O Git usa essas duas informações mais tarde para atribuir snapshots (“commits”) a um usuário. A opção --global signifi ca que as confi gurações se aplicam a todos os repositórios de um usuário Git por padrão. Se quiser-mos utilizar um nome ou endereço de email diferentes para um projeto específi co, precisaremos executar o git config no respectivo repositório, mas sem a opção -- global .

Quando os usuários executam um commit, o Git normalmente chama o editor padrão do sistema e recorre ao Vi , se nenhum padrão for defi nido. Pelo fato de o Vi muitas ve-zes ser o padrão – e muitos usuários não gostarem da ideia de usá-lo – o Git permite que o usuário selecione seu editor preferido. Basta digitar :

# git config --global core.editor <preferred_editor>

e substitua com o nome do seu edi-tor preferido.

Git em ação O Git é muito fácil de usar no trabalho diário. Para iniciar um projeto com o sistema de controle de versão, quer este seja o código fonte ou um documento de escritório, precisamos inicializar o Git no diretório apropriado com:

git init

O Git cria, então, um diretório oculto, ./git , que posteriormente é utilizado para monitorar o projeto e seu desenvolvimento ( fi gura 1 ). Quan-do inicializarmos um diretório, ele não precisa conter todos os arquivos.

Para visualizar o status de um repositório, execute o comando git status . Este comando lista os arquivos que o Git ainda não mo-nitorou, os arquivos que foram al-terados desde o último commit, e os arquivos que foram alterados na área de preparação. A fi gura 2 mos-

Figura 2 Saída de status do Git mostrando candidatos para a área de

preparação.

Figura 3 O próximo commit diz respeito a muitos arquivos novos.



tra um projeto recém-inicializado, onde o Git ainda não está monito-rando quaisquer arquivos.

Podemos imaginar a área de prepa-ração como um lugar onde residem os arquivos que serão adicionados ao snapshot Git no próximo commit. É possível enviar os arquivos, diretórios ou todo o projeto selecionado para a área de teste digitando git add <file> ou git add . . O status muda, então, de untracked para new fi le ( fi gura 3 ).

Commits Quando um autor quer salvar seu trabalho atual em um snapshot, ele pode usar git commit para fazer isso, após mover todos os arquivos afeta-dos para a área de preparo. Além dos arquivos e mudanças, o Git registra os nomes e endereços de email do

autor / committer para cada commit, juntamente com a data de criação e commit.

Depois de digitar o comando, o Git abre um editor (previamente confi gurado), que permite que o usuário digite uma mensagem de confi rmação. O usuário pode aceitar a sugestão do Git, que lista todas as alterações desde o último commit – simplesmente removendo o sinal de cerquilha no início – ou pode digitar sua própria mensagem ( fi gura 4 ).

A mensagem de commit deve indicar o que foi modifi cado. Pelo fato de o Git apresentar uma visão concisa dos commits quando o re-gistro é consultado, a primeira linha deve sempre conter um resumo. Isto é especialmente verdadeiro se a mensagem de commit for lon-

ga. Particularmente quando várias pessoas estão colaborando, breves comentários ajudam a explicar por que algo mudou e se quaisquer pro-blemas ou erros ocorreram ou são esperados (quadro 1).

O primeiro commit é geralmente chamado de “commit inicial”; deve-mos nomear todos os outros commits de modo que os participantes do projeto possam ver imediatamente o que o commit fez. Mensagens como minor bugfi x (correção de pequenos bugs) não dizem nada de útil – uma mensagem mais signifi cativa deve ser Segmentation fault in fl ip fl op on.cpp fi xed (falha de segmentação no fl ip fl op on.cpp corrigida). Muitas ve-zes, especialmente em colaboração distribuída, onde todos os membros do projeto precisam receber o esta-do atual sem demora, os commits incluem apenas pequenas altera-ções. Se uma pequena mensagem de commit é sufi ciente, podemos adicioná-la diretamente quando chamarmos o Git como:

$ git commit -m "MPI_Type_create_ struct added for LineHistogram"

sem a necessidade de executar o editor.

Ramifi cações Se adicionarmos novos recursos em um aplicativo existente, há sempre um risco de que partes funcionais sejam afetadas. O Git assume as preocupações para o pior cenário possível, permitindo diferentes ra-mifi cações em um projeto. Uma ramifi cação pode ser comparada a um playground, onde podemos experimentar novos recursos sem colocar em risco as partes existentes de um aplicativo.

Para criar uma nova ramifi cação, podemos usar o comando

git branch <name>

Um número qualquer de ramifi -cações paralelas pode existir, e você pode alternar entre elas com:

Figura 4 O usuário pode editar mensagens de commit em um editor de sua

preferência.

Figura 5 O Git suporta muitas ramifi cações simultâneas; um asterisco indica a

área de trabalho atual.

69



git checkout <name>

O comando git branch sem es-pecifi car um nome mostra todas as ramifi cações existentes. O Git marca a á atual com um asterisco ( fi gura 5 ) – qualquer commit subsequente afeta somente esta ramifi cação.

Todas as alterações feitas em uma ramifi cação não infl uenciam as ou-tras de maneira alguma. Depois de completar a implementação de novos recursos e testar bastante, podemos mesclar a ramifi cação com a mas-ter usando:

git merge <name>

Ramifi cações desnecessárias são facilmente removidas com:

git branch -d <name>

Se quiser mudar o nome de uma ra-mifi cação, faça isso usando o comando

git branch -m <newname>

O que há de novo? O comando git diff permite visu-alizar e identifi car rapidamente as diferenças entre as ramifi cações, commits ou arquivos, como no exem-plo a seguir: git diff <Branch1>..<Branch2>git diff <CommitID>git diff <filename>

Este comando demonstra ser es-pecialmente útil quando estamos interessados apenas em corrigir erros de algumas alterações que são difíceis de encontrar com um olhar casual.

Histórico do projeto Um projeto cresce, commits se ali-nham, e um milestone é alcançado, por isso é hora de um changelog. Ao invés de arruinar seu cérebro tentando lembrar o que aconteceu desde a última etapa, você somente pergunta ao Git - supondo que tenha sempre acrescentado signifi cativas mensagens de commit.

Por exemplo, o comando :

git log

revela o que aconteceu a cada com-mit, quem foi o responsável por isso, e quando foi feita uma alteração no projeto. O log pode ser curto e incisivo ou muito detalhado, dependendo da requisição. Se digitarmos o coman-do sem parâmetros adicionais, o Git gera o hash exclusivo de um com-mit, o autor, a data, e a mensagem do commit. A opção --graph mostra ramos separadamente ( fi gura 6 ). O parâmetro --oneline limita a saída para o início do hash do commit e a mensagem de commit, e nunca usa mais que uma linha para isso.

Mitigando danos Considere este breve cenário: de-pois de vários dias de trabalho de desenvolvimento sob pressão aguda de tempo e privação de sono, de re-pente o desenvolvedor encontra-se rodeado de código “sujo” que não funciona como deveria. Tentar re-mover os commits manualmente é provavelmente impossível, portanto ou ele volta à estaca zero, ou pode fazer uso dos benefícios do contro-le de versão e operar um rollback (reverter) para a última revisão naqual trabalhava.

Se o desenvolvedor em questão tiver certeza absoluta de que as úl-timas horas foram, de fato, um caso perdido, poderá executar um rollback severo digitando:

git reset --hard <CommitID>

O CommitID refere-se ao va-lor hash de 40 dígitos do snapshot desejado. Os hashes tipicamen-te diferem na medida em que o Git necessita apenas dos primei-ros sete dígitos para identificar o commit claramente. O rollback severo redefine todos os arquivos no diretório de trabalho e na áreade preparação.

Se substituíssemos --hard por --soft , o Git iria zerar o commit es-pecifi cado para a versão “HEAD”, que serve então como o último com-mit. Neste caso, todas as alterações no diretório de trabalho e na área de teste são mantidas. O usuário terá que decidir por si mesmo se voltar para a última versão usando soft faz sentido em um labirinto de confu-são de código.

Outra opção de rollback é o git checkout , com o qual o usuário já está familiarizado ao alternar entre ramifi cações. Para fazer um rollba-ck, podemos renomear a ramifi ca-ção principal e recuperar o último snapshot utilizável com :

git checkout <CommitID> Figura 6 Log do Git mostrando o histórico do projeto.



em seguida, torne esta a nova versão principal com :

git checkout -b master

Este é um atalho para não ter que digitar os seguintes comandos:

git branch <name>git checkout <name>

( fi gura 7 ). A vantagem deste tipo de rollback é que inicialmente são man-tidas todas as alterações e quaisquer ideias não utilizáveis poderão ser ex-cluídas mais tarde. Usar git checkout não só ajuda a zerar completamente os commits, como também arquivos

separadamente. Tudo o que o usuário ainda precisa fazer é especifi car o nome do arquivo. Assim, usar o comando:

git checkout af4673fa6 main.cpp

restaura a revisão af4673fa6 do ar-quivo main.cpp .

Versões distribuídas O Git foi projetado desde o início como um sistema de controle de versão distribuído, o que signifi ca que várias partes interessadas podem trabalhar em um projeto ao mesmo tempo. Em contraste com um siste-ma de controle de versão centrali-

zado, que precisa de uma conexão com o repositório do servidor para obter logs e commits, repositórios Git são executados localmente e podem sincronizar com um servi-dor assim que uma conexão de rede estiver disponível.

Como o servidor só precisa dis-tribuir as alterações, é bom que ele seja executado em um repositório vazio. Este repositório contém ape-nas os arquivos do diretório do pro-jeto Git, .git , e ajuda os membros do projeto a sincronizar seus dados. Podemos criar um repositório vazio no servidor com:

$ git init --bare <repository>.git

As permissões de acesso que se aplicam aqui são os padrões do umask da conta de usuário utilizada para criar o repositório ( fi gura 8 ). No computador local, podemos clonar o repositório remoto usando:

$ git clone ssh://<server>/ <path>/<repository>.git

O Git suporta a sincronização de repositórios via protocolos Git, SSH, e HTTP(S). O Git não suporta a autenticação em si, ao invés disso conta com o SSH para identifi car os usuários que fazem upload de um commit. Aplicativos auxiliares como o Gitolite [10] ajudam a evitar que todos os envolvidos no projeto pre-cisem ter uma conta de usuário com direitos plenos para se autenticar.

Após a criação de um repositório vazio recém-clonado, é necessário populá-lo criando arquivos de pro-jeto no repositório local, em seguida commitá-los e sincronizá-los com o repositório remoto. O comando a seguir faz essa proeza:

$ git push <bare> <local>:<remote>

O item <bare> especifi ca o repo-sitório remoto, <local> que refere-se à ramifi cação local, e <remote> é a ramifi cação remota. Após o commit inicial, o próprio Git reconhece se

Figura 7 O comando checkout do Git não é apenas útil para alternar entre

ramifi cações, mas também para rollbacks.

Figura 8 Um repositório vazio contém apenas o diretório .git para um proje-

to, mas nenhum arquivo de trabalho.

Figura 9 Usando o push para sincronizar os repositórios Git local e remoto.

71



contrapartes remotas existem para ramifi cações locais; um simples git push é o sufi ciente ( fi gura 9 ).

A contraparte para git push é git pull ; este combina os comandos git fetch e git merge para sincronizar o repositório local com o remoto. Os comandos fetch e merge mui-tas vezes iniciam interações bem complexas com repositórios remo-tos, portanto vale a pena dar uma

olhada na documentação do Git para ambas as ferramentas.

Serviços públicos como o Gi-tHub [11] , Gitorious [12] ou o Google Code [13] são alternativas úteis para um servidor de projeto próprio. Não há custos para pro-jetos livremente acessíveis. Para os projetos que o usuário não de-seja compartilhar com o público em geral, o Gitorious e o GitHub

oferecem também hospedagem comercial de repositórios privados.

Simplesmente ignore Em projetos maiores de software, principalmente, os desenvolvedores tendem a usar diversas estruturas de diretório ou preferem confi gu-rações diferentes para os usuários. Se os desenvolvedores modifi cam arquivos que contêm caminhos ou confi gurações diversas vezes para corresponder com suas preferências e então submetem essas mudanças, outros colaboradores rapidamente fi carão frustrados.

Além disso, os arquivos de confi -guração muitas vezes contêm nomes de usuários e senhas que podemos não querer distribuir. Felizmente, o Git permite excluir arquivos de um commit. Para fazer isso, é só criar um arquivo .gitignore no respectivo diretório de trabalho e listar todos os arquivos do diretório que deseja que o Git ignore em um commit. É preciso digitar um nome de arquivo por linha.

Conclusão Como um sistema de controle de versão distribuído poderoso, o Git pode fazer muito mais do que ape-nas o básico mostrado neste artigo. Seus recursos avançados incluem a aplicação de tags e alteração de base, um daemon para acesso de leitura anônima em repositórios Git, fi ltros e hooks, e a capacidade de remover informações sensíveis ou bibliotecas retroativamente a partir de um repo-sitório. Além disso, várias interfaces gráfi cas e interfaces web oferecem uma abordagem mais conveniente para controlar o Git. ■

Mais informações [1] Git: http://git -scm.com/

[2] Git-cola: http://git -cola.github.com/

[3] SmartGit: http://www.syntevo.com/smartgit/index.html

[4] Giggle: https://live.gnome.org/giggle/

[5] Gitg: https://live.gnome.org/Gitg/

[6] Cgit: http://hjemli.net/git/cgit/

[7] Gitlab: http://gitlabhq.com/

[8] Git (no GitHub): https://github.com/git/git/

[9] Documentação do Git: http://git -scm.com/doc/

[10] Gitolite: https://github.com/sitaramc/gitolite/

[11] GitHub: https://github.com/

[12] Gitorious: http://gitorious.org/

[13] Google Code: http://code.google.com/



sso sr/artic

sua om

ne.com

e:804

igo?nião.

Quadro 1: Protocolo Para projetos de software em que vários desenvolvedores compartilham um

sistema de controle de versão, algumas práticas tem se revelado benéfi cas.

Por exemplo, devemos – se possível – também monitorar as alterações feitas

por outros desenvolvedores. Isso ajuda a descobrir rapidamente se o código

interage com outros componentes e poderá encontrar observações sobre os

erros existentes. Os repositórios devem sempre conter apenas um projeto,

mesmo que os desenvolvedores possam trabalhar juntos em vários projetos

ao mesmo tempo.

Preferencialmente, cada commit deve completar exatamente uma tarefa – por

exemplo, um novo recurso ou uma correção de bug. As mensagens de com-

mit devem ser autoritárias e explicar casos de uso complicados, especialmen-

te se este não é tratado por comentários no código. Se possível, um repositó-

rio deve conter apenas os arquivos que os desenvolvedores criaram. Arquivos

gerados automaticamente, ou livremente acessíveis através de bibliotecas e

ferramentas externas, não devem fazer parte do repositório; na verdade, eles

desnecessariamente incham o repositório.

O código publicado com um commit deve funcionar, então outros membros do

projeto podem continuar a trabalhar e não têm que começar a corrigir bugs que

surgiram. No entanto, um usuário nunca deve remover o código do projeto sem

consulta prévia, só por que não gosta ou não o compreende imediatamente.


ANÁLISE | Desktop remoto Guacamole

Desktop remoto Guacamole

Clique para o futuro O HTML5 oferece uma série de recursos que não necessitam

de plugins Flash ou Java para funcionar. Com isso, surgem

novas opções de acesso móvel a aplicativos na rede local.

por Thomas Zeller

Controlar aplicativos remotamen-te através do navegador não é novidade – isso já é possível

desde o Google Apps. Mas, e se quiser-mos nos servir de aplicativos próprios na rede local da empresa ou acessar a área de trabalho em casa através da Internet? Tecnologias de acesso remoto (como VNC e RDP ) ou soluções VDI (como o /VMware View ou Citrix Xen Desktop ) são escolhas óbvias.

Porém, esta abordagem geralmente envolve a instalação do cliente de soft-ware correspondente na máquina a par-tir da qual os usuários desejam acessar o aplicativo remoto. Se o usuário não confi a na criptografi a incorporada, ou se não existe nenhuma, em breve sen-tirá a necessidade de um cliente VPN que forneça criptografi a e autenticação.

Tudo isto é lamentável, por exem-plo, se estivermos trabalhando em um computador no saguão do hotel ou em uma lan house e não pudermos instalar nossos próprios aplicativos. Durante alguns anos, os VPNs SSL clientless têm preenchido esta lacuna, fornecendo acesso baseado em nave-gador para aplicativos remotos através de uma conexão HTTPS segura, sem a necessidade de instalar um cliente. No

entanto, estas soluções normalmente impõem requisitos específi cos para o navegador e plugins. Muitas vezes pre-cisamos de Java, Flash ou ActiveX – e talvez até mesmo uma versão específi ca.

Melhor com o HTML5 A alternativa é o Guacamole [1] , um aplicativo online em HTML5 que su-porta acesso gráfi co através de proto-colos desktop remoto ( remote desktop protocols ou RDPs) diretamente no navegador, sem a necessidade de plugins adicionais. O programa está licenciado sob a AGPLv3 e, na atual versão 0.6.2, suporta VNC e RDP – embora de forma limitada em alguns casos. Por exemplo, não é possível transmitir dados de audio ou conectar unidades de rede no RDP.

No lado servidor, o software Java é executado em um servidor Apache com um container servlet (Apache Tomcat) e atua como um proxy que traduz a saída gráfi ca do VNC e do RDP em XML e vice-versa ( fi gura 1 ). Os desktops acessí-veis via RDP ou VNC podem executar tanto no servidor de aplicativos como em um computador diferente na rede. O Guacamole promete desempenho quase nativo e oferece suporte a teclado

internacional e teclado na tela, onde é possível utilizar o mouse para simular a digitação no teclado.

O recurso do Guacamole baseia-seno elemento <canvas> do HTML5, que usa JavaScript para lidar com extensas operações gráfi cas, incluindo linhas não só de desenho, retângulos, arcos e curvas de Bezier, mas também renderização de gradientes de cores, transparências, texto e – o mais importante – gráfi cos escalonados nos formatos PNG, JPG e GIF. Estas são as condições ideais para a renderização de um desktop e apli-cativos no navegador. O pré-requisito, então, é apenas um navegador que ofereça suporte ao elemento canvas. A maioria dos navegadores atuais pode fazer isso hoje em dia (exceto o Internet Explorer 8 e 9), apesar do W3C supor que o HTML5 não será amplamente suportado até 2014 ( quadro 1 ).

Como instalaro Guacamole Felizmente, o site do Guacamole apre-senta pacotes pré-compilados para várias distribuições. A seção de downloads do site [1] oferece pacotes para o Debian 6.0 (Squeeze), Ubuntu 11.10/12.04 e

AN

ÁLIS

E

73

| ANÁLISEDesktop remoto Guacamole


Fedora 15/16/17. Alternativamente, po-demos compilar o Guacamole a partir do código fonte [3] .

Para um teste, vamos precisar do Guacamole 0.6.2 em um sistema Ubuntu recente (12.04.1 LTS). Para fazer isso, devemos primeiro satisfazer as dependências de suporte ao Java, VNC e RDP, usando:

sudo apt-get install tomcat6 libvncserver0 libfreerdp1

Em seguida, baixe os pacotespré-compilados para o Ubuntu 12.04

da página do projeto Guacamole no SourceForge e descompacte o con-teúdo do arquivo no diretório home. Siga para o novo diretório,

cd guacamole-0.6.2-ubuntu-12.04-i386

e instale os pacotes Guacamole. A se-guinte linha única fará isso: sudo dpkg -i guacd_*.deb guacamole_*.deb libguac3_*.deb libguac-client-vnc0_*.deb libguac-client-rdp0_*.deb

Se o usuário desejar somente su-porte a conexões VNC no navega-

dor, não precisará instalar o pacote libguac-client-rdp0_*.deb .

O servidor Tomcat exige agora links simbólicos: um para cada um dos arquivos guacamole.war e guacamole.properties . Além disso, precisará adicio-nar o usuário tomcat6 ao novo grupo guacamole-web , o que é feito automa-ticamente ao instalarmos o pacote:

sudo dpkg -i guacamole-tomcat_*.deb

Como alternativa, o procedimento manual é descrito no site do projeto Guacamole. Finalmente, reinicie o servidor Tomcat e selecione sim no prompt ( fi gura 2 ), ou digite

sudo /etc/init.d/tomcat6 restart

para reiniciar o servidor Tomcat via linha de comando.

Confi guração Para que o acesso via Guacamole ao desktop seja bem-sucedido, evidente-mente também é preciso compartilhar um desktop. Durante nosso teste, opta-mos por compartilhar a área de trabalho em um PC com Windows 7 usando o protocolo RDP. Isto funcionará tão bem quanto um terminal de servidor real do Windows ou um computador em que o ambiente de trabalho é compartilhado através de um servidor VNC.

Em seguida, precisaremos inserir o Guacamole nas credenciais de área de trabalho remota, assim o acesso através do navegador irá funcionar adequada-mente. Para isso, abra o arquivo /etc/guacamole/user-mapping.xml com o seu editor preferido ( fi gura 3 ), por exemplo:

sudo vi /etc/guacamole/ user-mapping.xml

Em seguida, adicione os dados ne-cessários na seção:  . Para fazer isso, primeiro remova os caracteres de comentário <--! e --> .

No exemplo, vamos confi gurar uma conexão para o usuário tom com uma senha teste em um sistema Windows com um endereço IP 192.168.1.11 ( lista-

Figura 1 O esquema mostra um diagrama funcional do Guacamole e sua

comunicação com os servidores RDP ou VNC.

Figura 2 Instalar os pacotes do site do Guacamole confi gura o servidor Tomcat.



gem 1 ). Se preferir usar o VNC, poderá substituir o RDP na seção protocolo por vnc . Em seguida, guarde a senha para o servidor VNC na seguinte seção: <param name="password"><MinhaSenhaVNC></pa-ram> . Salve o arquivo de confi guração e digite sudo /etc/init.d/guacd restart para reiniciar o serviço guacd .

Como conectar ao desktop Verifi que se a máquina inserida em user-mapping.xml é acessível com o protocolo correspondente; em segui-da, acesse o endereço http://endere-coIP:8080/guacamole no navegador. Após a autenticação bem sucedida com o nome de usuário e senha especifi ca-dos, o usuário deve ser capaz de efetuar login no desktop do sistema de destino, como mostrado no navegador ( fi gura 4 ). Poderá também fazer o login com as credenciais do Windows.

O Guacamole fornece uma área de transferência simples para a troca de texto entre a máquina remota e o sistema local, bem como um tecla-do na tela, se arrastarmos o cursor do mouse na direção da barra de endereço do navegador ( fi gura 5 ). Se necessário, poderá enviar um Ctrl+Alt+Del para a máquina remota ou encerrar a sessão com o Guacamole.

Pequenas incertezas A instalação padrão do Guacamole funciona, mas não é nada segura, pois o acesso à página de login não é crip-tografado. Assim, o usuário é urgente-mente aconselhado a instalar o Tomcat com suporte a SSL. Para um how-to (como fazer), confi ra a documenta-ção detalhada do Tomcat online [4] . Outra característica lamentável é que a senha para abrir a conexão com o servi-dor RDP e – se usarmos uma conexão VNC também a senha do VNC – fi ca armazenada em texto puro no arquivo de confi guração user-mapping.xml e pode ser lida por um usuário logado. Desta forma, é preferível mudar o dono e as

permissões do arquivo user-mapping.xml da seguinte forma:

sudo chown tomcat6.tomcat6 user-mapping.xml

sudo chmod 640 user-mapping.xml

Alternativamente, o Guacamole oferece também a possibilidade de criar senhas com hash apenas no ar-quivo de confi guração. A listagem 2 mostra a seção correspondente do

user-mapping.xml para o usuário tom e o hash MD5 da senha.

Podemos visualizar rapidamente o hash da senha na linha de comando com o utilitário md5sum :

echo -n <SENHA> | md5sum -t319f4d26e3c536b5dd871bb2c52e3178 -

Em seguida, adicione o valor hash ao invés da senha na confi guração. Naturalmente, o hash da senha deve

Figura 3 Os usuários que precisam de acesso HTTP para desktops gráfi cos são

adicionados ao arquivo de confi guração central user-mapping.xml .

Figura 4 Graças ao HTML5, os usuários não precisam mais de plugins para

acesso gráfi co a desktops no navegador.

75

| ANÁLISEDesktop remoto Guacamole


possuir mais de oito caracteres e deve ser escolhido para ser o mais seguro possível com caracteres não-padrão; senhas simples podem ser quebradas por crackers através de força bruta, com ferramentas como o mdcrack , dentro de alguns minutos.

Sophos UTM 9.0 Se o usuário estiver preocupado com a sobrecarga da criação de conexões seguras com o Guacamole, pode usar também um software comercial. Por exemplo, a versão atual do Firewall So-phos UTM 9.0 (anteriormente Astaro Security Gateway ) fornece um portal em HTML5 que podemos usar para acessar serviços na rede local sem a instalação de cliente ( quadro 2 ).

Além de RDP e VNC, o Sophos suporta conexões em servidores Telnet e SSH, bem como conexões HTTP e HTTPS. Dito isso, o acesso remo-to via HTML5 só desempenha um papel secundário no Sophos UTM. Novamente, não podemos usar RDP para mapear unidades nos clientes. Para acesso remoto à rede totalmente transparente, o Sophos UTM fornece servidores IPsec, SSL, PPTP, e L2TP VPN como alternativas. O portal HTML5 com transmissão somente KVM (teclado, vídeo e mouse) é mais adequado para eventuais sessões de gerenciamento remoto com presta-

dores de serviços externos para os quais não queremos designar pleno direito de acesso VPN.

Firewall eVPN gratuitos A Sophos oferece o UTM 9.0 como um aplicativo de hardware, aplicativo virtual ou aplicativo em software para instalação em seu próprio hardware. Aplicativos de software e virtuais es-tão disponíveis para download a par-tir do servidor FTP no site da Astaro [7] . A Sophos concede a usuários registrados uma “licença de uso do-méstico” gratuita para uso privado e não comercial que possui o recurso completo de edição comercial para até 50 endereços IP ( antivirus end-point para 10 usuários). Ela inclui os seguintes módulos:

➧ Segurança de rede: fi ltragem de pacotes, VPN, proteção contra invasão.

➧ Segurança web: fi ltragem de URL, controle de aplicativos, antivírus com HTTP, HTTPS, FTP e proxy.

➧ Segurança de email: anti-spam, antivírus com proxy SMTP+POP3.

➧ Segurança de servidor web: fi -rewall de aplicativos web contra ata-ques de scripts de cross-site, injeção de SQL, e assim por diante.

➧ Segurança sem fi o: controlador WLAN para pontos de acesso Sophos.

➧ Antivírus endpoint: antivírus e controle de dispositivos para clien-tes Windows.

Para obter uma licença, primeiro registre-se online [8] e, em seguida, faça login com suas credenciais. A licença gratuita estará disponível em View Li-cense/Home Use License .

Como criar um portal de usuário Pelo fato de as imagens pré-construídas para VMware entregarem um Sophos UTM 9.0 com um portal em HTML5 com o VMware Player, VMware Works-tation ou um servidor ESX, isso é feito facilmente. Se preferir executar a máqui-na virtual no VirtualBox, poderá baixar a imagem ISO ao invés do aplicativo virtual e vinculá-la como uma medida de inicialização para criar uma máqui-na virtual manualmente.

Após a instalação, ou a primeira execução da VM, um assistente de confi guração simples guia o usuário através da confi guração dos ajustes básicos, como atribuir a senha de administrador, confi gurar a conexão à Internet, habilitar a proteção de in-trusão, confi gurar proxies, e por aí vai. No fi nal deste processo, basta instalar a licença de uso doméstico, e estará pronto para continuar a confi guração do portal HTML5.

Figura 5 Além da área de transferência (de texto) própria,

o Guacamole oferece um teclado na tela, aonde

podemos digitar um texto e usar o mouse.

Figura 6 O novo Sophos UTM 9.0 também oferece um portal

HTML5 para o acesso aos recursos internos do

sistema no navegador.



O VPN HTML5 e portais de usuário são integrados para acesso a outros recursos. Por exemplo, podemos visualizar a qua-rentena de spam, baixar os clientes VPNpré-confi gurados e acessar o portal VPN HTML5. O primeiro passo permite, portanto, habilitar o portal do usuário em Management/User Portal e restringi--lo a redes e usuários individualmente, conforme aplicável.

É claro, queremos que os usuários possam acessar o portal do usuário pela Internet. Por este motivo, digite AnyIPv4 em Allowed networks (redes permitidas) e selecione a opção Allow all users (permitir todos os usuários). Em seguida, em Defi nitions & Users/Users & Groups (defi nições e usuários/usuários e grupos), adicione os usuá-rios que acessarão o portal. Em segui-da, habilite HTML5 VPN portal em Remote Access/HTML5 VPN portal/Enable (acesso remoto/HTML5 VPN portal/habilitar) e crie as conexões para os serviços internos. Para fazer isso, clique em New HTML5 VPN Portal

connection (nova conexão com portal VPN HTML5), digite um nome para a conexão e selecione o protocolo – por exemplo, Remote Desktop ( fi gura 6 ).

Opcionalmente, podemos inserir as credenciais; os usuários podem fa-zer login no terminal de servidor di-retamente via portal VPN HTML5. Esta abordagem é prática – quem iria querer confi ar em um usuário exter-no com uma conta de administrador? Mais abaixo, podemos atribuir a nova conexão para todos os usuários e redes ou defi nir restrições. A conexão agora está pronta para ser usada. Usuários legítimos podem fazer login no portal

do usuário, que eles acessam através do URL https: <endereco IP externo> . Após a autenticação bem sucedida, os usuá-rios devem apenas clicar em HTML5--VPN-Portal e, em seguida, clicar no botão Connect (conectar) próximo às conexões pré-confi guradas.

Finalmente, devemos também mencionar que, como um sistema backend, o Sophos UTM 9.0 suporta uma ampla gama de soluções de au-tenticação, incluindo LDAP, Active Directory, Single Sign-On, Novell eDirectory e RADIUS. Pelo fato de a maioria dos fornecedores de solução de dois fatores de autenticação (por exemplo, o Vasco Digipass [9] ) usarem a interface universal RADIUS, o acesso ao portal do usuário pode facilmente ser protegido com tokens. ■

Quadro 1: Navegadores compatíveis com o HTML5 Para determinar se o seu navega-

dor suporta recursos HTML5 e, em

caso afi rmativo, quais, o site de teste

HTML5 [2] é altamente recomendá-

vel. Ele analisa o suporte a recursos in-

dividuais no navegador na velocidade

da luz e atribui uma pontuação para

cada elemento. O resultado é uma

avaliação confi ável da compatibilida-

de do navegador com o HTML5. A

partir da atual safra de navegadores,

o Chrome 21 facilmente mantém a li-

derança com 437 pontos, e o Internet

Explorer 9 está em último lugar, com

apenas 138 pontos. Em plataformas

móveis (Android, iOS, Windows Pho-

ne, entre outros) o Opera 12 está há

apenas dois pontos atrás do Chrome

(em dispositivos Android 4) em todas

as plataformas.

Quadro 2: Mais desktops remotos em HTML5 Para completar o assunto, mencio-

naremos apenas dois projetos mais

interessantes neste momento; am-

bos fornecem desktops remotos

através da tecnologia HTML5:

➧ ThinVNC [5] é um servidor VNC

comercial (infelizmente, apenas para

Windows) com criptografi a SSL e

autenticação NTLM integradas.

➧ noVNC [6] é um cliente VNC

HTML5 licenciado sob LGPLv3 que

requer um servidor VNC com suporte

a WebSockets do lado do servidor.

Mais informações [1] Guacamole: http://

guac -dev.org/

[2] Suite de teste HTML5: http://www.html5test.com/

[3] Código fonte do Guacamole:

http://sourceforge.net/projects/guacamole/files/current/source/

[4] Tomcat SSL how-to:

http://tomcat.apache.org/tomcat -6.0-doc/ssl-howto.html

[5] ThinVNC: http://www.cybelesoft.com/thinvnc/

[6] noVNC: http://kanaka.github.com/noVNC/

[7] Astaro UTM: ftp://ftp.astaro.com/UTM/v9/

[8] Astaro login: https://my.astaro.com/

[9] Digipass: http://www.vasco.com/products/products.aspx

Gostou do artigo?Queremos ouvir sua opinião.

Fale conosco em

[email protected]

Este artigo no nosso site:


o site

ticle

ne.com.b

55

o?opinião.

Listagem 1: Mapeamento de Usuário 01 <authorize username="tom" password="test">

02 <protocol>rdp</protocol>03 <param name="hostname"> 192.168.1.11</param>

04 <param name="port">3389 </param>

05 <param name="password"> </param>

06 </authorize>

Listagem 2: Senhacom MD5 01 <authorize02 username="tom"03 password="b2016af253087887 ccb510d7543ed514"

04 encoding="md5">05 <protocol>vnc</protocol>06 <param name="hostname"> localhost</param>

07 <param name="port">5900 </param>

08 <param name="password"> 123456</param>

09 </authorize>

www.e-smart.com.br/magneto


Linux Magazine #99

PR

EVIE

W

Admin Magazine #09

System RescueQualquer sistema, quando executado durante um longo tempo está sujeito à panes inesperadas. Falhas de disco rígido, sistema de arquivos corrompido, ou simplesmente perda de arquivos podem ser alguns dos problemas que podem surgir. Na próxima edição da Linux Magazine , especialistas em recuperação de dados vão mostrar como utilizar a diversifi cada coleção de ferramentas para recuperação do sistema de forma que seja possível ressuscitar seu Linux e com a ascensão do recurso de inicialização em modo Live, a tarefa fi cou ainda mais fácil. Edição imperdível! ■

OpenStackCapaz de gerenciar os componentes de múltiplas instâncias virtualizadas, o OpenStack é um dos queridinhos dos profi ssionais de infraestrutura e virtualização da atualidade. É li-vre, não possui restrições quanto à quantidade de instâncias e é uma plataforma robusta, extremamente útil nestes tempos onde o adven-to da computação em nuvem já é uma realidade. Na próxima edi-ção da Admin Magazine você vai conhecer tudo o que essa incrível ferramenta pode fazer por você! Não perca!

locaweb.com.br/revendaplesk

linux magazine ed. 98 (janeiro 2013)

Documents