Melhorando a segurança do X usando o mit-magic-cookie e o xauth.
Por Ben Gross & Baba BuehlerInformações baseadas no X Window System Administrator's Guide, de Linda Mui e Eric Pearce, da O'Reilly & Associates, o FAQ do comp.windows.x, e as notas sobre segurança do X de Mark VanHeyningen, da Indiana University ( http://cs.indiana.edu/X/security/intro.html).
Este documento é parte do Beckman Institute Systes Services Virtual Library
A autorização X baseada no xhost que a maioria das
pessoas usam é funcional para workstations que são usadas apenas por
um usuário. Para sistemas multi-usuários e ambientes de laboratório,
entretanto, o xhost possui alguns problemas sérios.
Além de permitir que alguém bagunce o seu display X com figuras do
Ren e Stimpy, o xhost permite que qualquer um que possa
fazer o logon (ou invada) no seu sistema execute programas em seu
display. Os ataques podem incluir:
A maioria destes pode ser feito sem aviso e sem deixar traços.
Apesar disto, o xhost ainda é a única segurança X que
a maioria das pessoas usam. Os benefícios do xhost são
diretos: é facil executar programas X em sistemas remotos e apresentar
os mesmos localmente. Escreva:
% xhost +powdered.toast.com
e faça o logon em powdered.toast.com, e você pode
rodar qualquer programa X em powdered.toast.com e mostrar
o mesmo localmente. Isto, entretanto, também permita que
qualquer um que esteja logado em
powdered.toast.com usar (ou abusar) o display local de
sua workstation.
O xauth pode evitar isto. A execução de programas X
remotos é um pouco mais complexa, mas é o que chega mais perto de
garantir que você é a única pessoa que pode executar programas em seu
display X local.
Deve se notar que o mit-magic-cookie só funciona com o X11R4 e o X11R5.
O xauth funciona criando um arquivo chamado
.Xauthority em seu diretório $HOME. Este arquivo contém
os nomes de displays seguidos por um número hexadecimal (o magic
cookie). O servidor X lê o magic cookie deste arquivo e
então exige que qualquer programa X que você roda forneaça este mesmo
magic cookie.
Os programas do seu cliente X também lêem o arquivo
.Xauthority para obter o magic cookie. O cliente envia o
magic cookie para o servidor, que então verifica se este combina com
o que está em sua memória. Se eles forem idênticos, o cliente tem
permissão para abrir uma janela no servidor X.
Se você está rodando programas X na mesma máquina em que o servidor
X está, então a segurança é trivial, por que ambos programas
possuem acesso ao arquivo .Xauthority. As permissões do
arquivo .Xauthority devem ser 600,
teoricamente evitando que qualquer outra pessoa em seu sistema consiga
ler os magic cookies.
Se você percisa executar programas X em um host remoto, você
primeiro deve propagar o magic cookie do seu display local para o host
remoto. O xauth e o X fornecem os meios de fazer
isto.
O primeiro passo é criar um arquivo .Xauthority com um
magic cookie para seu host. Isto é feito mais facilmente no seu
arquivo .login ou .kshrc. Este código também
pode ser incluído em um arquivo .xserverrc.
O programa xauth cria e administra o arquivo
.Xauthority. Certifique-se que o diretório
/usr/bin/X11 (ou outro diretório em que os binários do X
se encontram no seu computador) está em seu path. É melhor configurar
o path X nos seus arquivos de inicialização, ou em
.profile, .kshrc ou .cshrc, uma
vez que estes arquivos são lidos pelos comandos rsh. Você
irá usar o rsh para executar programas X em hosts
remotos. Segue um código de exemplo usando o perl e o
sh ou ksh para o .profile de
seu Korn Shell ou Born Shell:
Uma das melhores formas que encontramos para gerar um número aleatório não-reproduzível com saída em hexadecimal é usar comandos comuns do sistema e o gerador de somas criptográficas MD5. O MD5 pode ser baixado de ftp.cert.org.
Um exemplo para o csh usando estatísticas do sistema e
o MD5.
set randomkey=`(ps -ael; nfsstat -m; nfsstat -f; netstat -s; netstat -m; date) | md5sum`
xauth add `hostname`/unix:0 . $randomkey
xauth add `hostname`:0 . $randomkey
Um equivalente para o sh ou ksh
seria:
randomkey=$( (ps -ael; nfsstat -m; nfsstat -r; netstat -s; netstat -m; date) | md5sum)
xauth add $(hostname)/unix:0 . $randomkey
xauth add $(hostname):0 . $randomkey
Nota: estas opções de linha de comando devem
funcionar com as variantes BSD e System V. Um exemplo csh
usando perl.
set randomkey=`perl -e 'for (1..4) { \
srand( time + $$ + $seed); \
printf("%4.5", ($seed = int(rand(65536)))); } \
print "\n";'`
xauth add 'hostname'/unix:0 . $randomkey
xauth add 'hostname':0 . $randomkeyUma nota importante: o magic cookie precisa ser uma string de dígitos hexadecimais e deve ter um comprimento par. O MD5 faz isto automaticamente.
Os benefícios aqui são:
O comando "xauth add" armazena o magic cookie em seu
arquivo .Xauthority, no seu diretório $HOME, e garante
que as permissões serão -rw-------, restringindo o acesso
ao arquivo.
Agora que temos um arquivo .Xauthority com seu magic
cookie, precisamos informar o servidor X a usar este para autenticar
programas X que querem usar seu display. Você pode fazer isto passando
o argumento -auth quando estiver iniciando o servidor
X.
Se você estiver usando o xinit no seu
.login, você pode alterar a linha para algo como:
xinit $HOME/.xinitrc -- -auth $HOME/.Xauthority
É importante usar o argumento "--" para o
xinit, este informa ao xinit para passar os
argumentos seguintes ao servidor X. Algo como
xinit $HOME/.xinitrc -- -auth $HOME/.Xauthority
Provavelmente irá funcionar, enquanto
xinit $HOMW/.xinitrc -auth $HOME/.Xauthority
não irá.
Se você usa um arquivo .xserverrc para iniciar seu
servidor X, acrescente a opção -auth:
exec /usr/bin/X11/X -auth $HOME/.Xauthority
Uma vez que o servidor X seja iniciado com o parâmetro
-auth, ele irá usar os magic cookies para verificar os
programas que querem usar o seu display X. Exceto se
aind houverem hosts autorizados pelo xhost.
O xhost substitui o xauth, por isto, se
você ainda tem algum host habilitado pelo xhost então o
esquema de magic cookie não ajudará em nada.
Verifique seu arquivo /etc/X0.hosts para ver se
existem hosts que serão automaticamente autorizados, ou coloque um
xhost -
em seu arquivo .login ou equivalente. Este
procedimento irá efetivamente desabilitar a autorização do
xhost, passando toda a autorização para o
xauth com os magic cookies.
O X Window System Administrator's Guide adverte contra a
remoção total ou a desabilitação do xhost por que isto
seria o equivalente a ter executado um xhost +, liberando
o acesso para todos os hosts. Usando o "xhost
-", você deixa o xhost habilitado, mas
esvazia a lista de hosts autorizados, de forma que toda a autorização
acontece através do xauth e os magic cookies.
Neste ponto, você deve estar seguro para operar o X em uma
workstation. Você deve poder executar qualquer cliente em seu host e
eles devem ler seu arquivo .Xauthority. Se seu diretório
$HOME é compartilhado entre vários hosts (por exemplo, via montagem
NFS), você pode rodar clientes de qualquer destes hots, por
que eles terão todo acesso ao arquivo .Xauthority em seu
diretório home compartilhado.
Para poder executar clientes em hosts remotos, você deve ter uma
forma de passar o magic cookie para aqueles clienets, de forma que
eles possam se autenticar com seu servidor X local. O
xauth fornece uma forma de criar um arquivo
.Xauthority em seu host remoto de forma que clientes
remotos possam ler o magic cookie.
Você deve primeiro certificar-se que você tem seu host local no
arquivo .rhosts ou /etc/hosts.equiv na
máquina remota, ou de outra forma o rsh não irá
funcionar. Certifique-se também de ter o path para o
xauth (normalmente /usr/bin/X11) configurado
no .cshrc no host remoto.
Agora você está pronto para propagar o magic cookie para o host
remoto. Por exemplo, se você está no host ren e quer
executar um cliente em stimpy, você primeiro deve
escrever:
ren% xauth extract - ren:0 | rsh stimpy xauth merge -
Este comando afz o pipe do magic cookie para o xauth
em stimpy o que irá criar um novo arquivo
.Xauthority com o magic cookie para o display
ren:0. Agora você pode executar
ren% rsh stimpy /usr/bin/X11/xterm -display ren:0
e o xterm no stimpy irá ler o novo
.Xauthority e encontrará o magic cookie que irá permitir
que seja apresentado no display de ren.
Os passos acima foram combinados em um sistema chamado
xrsh que está disponível como
/contrib/xrsh-5.4.shar em ftp.x.org. O xrsh
automaticamente faz o trabalho com o xauth para você, bem
como semper usa o csh, uma vez que o ksh não
lê nenhum arquivo de init para um rsh, deixando você sem
um path configurado. O rsh fornece um comando
xrlogin, bem como outras precauções de segurança. Nós
recomendamos fortemente a instalação do mesmo.
Usando o xrsh, e assumindo que o path para os binários
do X está configurado em .cshrc no host
stimpy, o código acima se torna:
ren% xrsh -auth xauth -pass ENV stimpy xterm
Certifique-se de incluir o -auth xauth por que o
padrão do xrsh é usar a autenticação xhost.
Você poe criar um alias xrsh que inclua -auth xauth
-pass ENV:
ren% alias xrsh 'xrsh -auth xauth -pass ENV \!*'
E então usar:
ren% xrsh stimpy xterm
Eset comando deve permitir você conseguir qualquer coisa que
anteriormente era feita com o xhost. Mais ainda, você
ainda pode usar o xhost se você achar que precisa, apesar
de isto comprometer instantaneamente qualquer segurança que você tenha
configurado com o xauth. Se você achar necessário usar o
xhost, recomendamos que execute um
xhost -
imediatamente após terminar o que quer que tenha exigido o
xhost, ou simplesmente fazndo logoff e login novamente, o
que irá gerar um novo magic cookie e reiniciar o X com a autorização
xauth reiniciada.
Por uma razão desconhecida aos autores, muitos sistemas vem com
toda a segurança de X Window desabilitada. O arquivo que controla as
permissões de proprietário e grupo dos dispositivos relacionados ao X
Window é a tabela de framebuffer (/etc/fbtab). Leia a
página man fbtab(5) para mais informações.
Do faq de comp.windows.x: "...isto permite que qualquer um que possa logar em usa workstation espiar sua sessão de windowing acessando o frame-buffer diretamente, ou, menos como um problema de vriacidade mas talvez mais perturbador, [acidentalmente] iniciar uma segunda sessão X em seu display console."
O formato de seu sistema pode variar. Temos estas linhas
descomentadas nos /etc/fbtab em nossos Suns:
/dev/console 0600 /dev/kbd:/dev/mouse
/dev/console 0600 /dev/fb
/dev/console 0600 /dev/cgsix0
/dev/console 0600 /dev/audio
/dev/console 0600 /dev/audioctl
O servidor X local armazena arquivos em
/tmp/.X11-unix. O arquivo X0 é um descritor de socket
usado pelo X para se conectar ao servidor local. Para certificar-se
que nenhum outro usuário possa excluir seu arquivo X0, configure o
sticky bit no diretório.
chmod 1777 /tmp
chmod 1777 /tmp/.X11-unix
Caso você não tenha permissões de teclado para seu
/dev/kbd, vocêpode querer utilizar a opção Secure
Keyboard de seu xterm. Esta opção pode ser acessada pressionando a
tecla Ctrl e pressionando o botão 1 do seu mose (pode variar de
sistema para sistema). Esta funcionalidade irá evitar que outros
usuários usem a solicitação de protocolo GrabKeyboard().
A tela deverá reverter suas cores, senão, certifique-se que ninguém
está olhando enquanto você escreve. Esta funcionalidade só pode ser
usada em uma janela por vez, por isto é usada principalmente para
digitar dados sensíveis, como sua senha, definitivamente para sua
senha de root.
A implementação destas medidas significa um longo trecho percorrido para garantir que sua workstation X está protegida de ataques através do servidor X. A segurança padrão do X é simplesmente inadequada para evitar ataques ou perda de dados.