Vírus em Linux

Categoria: Linux Publicado: Domingo, 01 Março 2015 Escrito por Helio Loureiro

Vírus em LinuxTem sido bastante difícil pra mim manter meu site atualizado, e não estou conseguindo manter meu ritmo de ao menos 1 post por semana.  Sinal de trabalho duro em outras coisas.

Estava pra comentar sobre esse assunto espinhoso, dos vírus pra Linux, faz um certo tempo.  Ao menos desde o início do ano.  Mas... enfim consegui um momento livre pra eu poder fazer isso.

A pergunta que surge de tempos em tempos é clara: EXISTEM VÍRUS PRA LINUX?

As respostas variam.  Defensores de Windows dizem que com toda certeza existem.  Mostram receitas esotéricas sobre como isso é possível e sempre voltam com a famosa frase "nenhum sistema é infalível", ou algo parecido com isso.

Os defensores de Linux, eu me incluo nesse grupo, dizem que é impossível.  Linux não é Windows.  Não foi feito sobre a mesma plataforma furada da Microsoft, que é cheia de buracos, e até provavelmente com alguns toques da NSA pra ajudar.  Se o usuário do Linux tem algum problema, o motivo é que não sabe atualizar sua distro.

Mas isso não explica a quantidade de problemas que têm aparecido sobre malwares em plataformas Linux, inclusive Android.

 

O problema é o windows.  Não que o windows tenha criado uma geração de vírus, mas o windows cunhou fortemente o conceito errado de que tudo é vírus.  Todo problema, malware, tudo é vírus.  E também foi graças ao windows que o conceito "se não funcionar, reinstala, se está lento, reinstala, e se quer mudar o wm, reinstala" se fortaleceu.  Isso se faz bem claro nos usuários que, pra trocar o Unity no Ubuntu, reinstalam o sistema inteiro.  Em geral com alguma refisefuqui.

Vírus é um pedaço de código que altera binários ou arquivos, e que se executa cada vez que esse programa é chamado ou aberto, no caso de arquivos.

Claramente isso não é possível no Linux por um simples motivo: quem executa o programa é o usuário e quem é o "dono" do binário é em geral o root.

Mas os problemas existem.  E muitos.  Existem os usuários que teimam em trabalhar como root no sistema, pra "facilitar as coisas".  Em geral os mesmos que reinstalam os sistema inteiro pra apenas trocar o wm (window manager).  Existem também os "programas de terceiros", como o plugin flashplayer, que não recebem as devidas atualizações de segurança.  Felizmente esses "programas de terceiros" não causam danos ao sistema como um todo, mas infelizmente podem fazer estrago o suficiente com o usuário, como permitir que suas credenciais de banco sejam roubadas.  Basta ver os recentes problemas do Java da Oracle.  Recentes?  Melhor dizer "contínuos".

E dá pra viver sem esses "aplicativos de terceiros"?  Até dá, mas não é muito fácil.  Alternativas existem, como pepperflashplugin ao invés do flash da Adobe, não usar acrobat reader ou seu plugin, mas os modos nativos do Firefox e do Chrome/Chromium pra renderizar pdf, etc.  O problema não são os "aplicativos de terceiros", mas se esses terceiros tratam os usuários de Linux com respeito, atualizando a cada falha encontrada.  Um bom exemplo dessa prática é o "steam", de jogos.

O problema então é o usuário, sempre?

Não.  Novamente o problema vem do windows.  Ou melhor, da idéia de vírus que veio com o uso do windows.  Quando discutimos o conceito de vírus, sempre nos vem a imagem de um desktop.  Daí os argumentos de problemas de segurança no Linux são apenas falta de atualização.  Isso não é verdade.

O outro lado do problema apareceu bem recentemente durante os ataques de DDoS do grupo LizzardSquad contra as redes de jogos PSN e Xbox Live.

Lizard Squad used hacked routers to take down Xbox Live and PlayStation Network

Foram usados roteadores caseiros, desses que usamos pra ter acesso wi-fi as nossas redes dentro de casa.  O artigo não diz, mas acredito que câmeras IPs também foram usadas.  

Esse tipo de problema não é novidade.  Foi discutido durante um dos YSTS, acho que o de 2013 que participei.  fabricantes, em geral na China, criam seus produtos pra rodar Linux, mas não dão nenhuma manutenção.  São sistemas customizados a ponto de ser impossível de rodar uma alternativa como dd-wrt/open-wrt. Esses sistemas rodam kernels Linux muito, mas muito velhos.  Daí que as explorações de vulnerabilidades, não vírus, ficam fáceis.  Nesse ponto temos de dar o braço a torcer pros usuários de windows.  Defender Linux nessas condições é quase como apontar o dedo pras máquinas windows comprometidas que rodam a versão XP.  O agravante é que o usuário se torna refém do fabricante, pois diferente dos computadores, esses sistemas embutidos não permitem que qualquer um atualize como quer, quando quiser, com a distro que mais gostar.

Então da próxima vez que ler sobre "vírus pra Linux", antes de cair na gargalhada, pense nesses roteadores e câmeras IPs.  Pense se esses sistemas rodando um Linux 2.4.20 não pode ter sua segurança facilmente comprometida.  Depois lembre que Windows, até hoje, pode ser comprometido acessando uma página web.  Foi corrigido?  Espere algumas semanas que sempre aparece de novo.

Ah... o windows...

Swapless Linux

Categoria: Linux Publicado: Sexta, 09 Janeiro 2015 Escrito por Helio Loureiro

Começando 2015, todos se lembram de como foi 2014.  Então resolvi escrever com um artigo sobre memória :)

Durante umas das discussões no grupo SOSLinux, alguém postou que já não usava Linux com swap fazia um tempo.  Nos meus velhos conceitos Unix adquiridos no século passado isso era algo inconcebível.  Uma heresia.  Um motivo pra receber um belo dum RTFM.

Esse é o problema de ter "aquela mesma velha opinião formada sobre tudo", como dizia Raul Seixas.  As coisas mudam.  Os sistemas evoluem.  Aquela recomendação de sempre se ter swap, e com fórmulas mágicas sobre seu tamanho, são coisas do passado, de uma era em que Linux era pra servidores e desktops.  Agora Linux está em todo lugar.  Na minha TV, no meu telefone, no meu tablet, e vai saber mais onde.  Talvez já esteja até no meu café e eu ainda não saiba.

Mas o fato é que naquela época a idéia era que as máquinas seriam cada vez maiores, mais potentes, mais gigantes, mais mais, muito mais.  Na verdade até são.  Mas aconteceu um fato interessante: o cloud.  Esse conceito permitiu uma forma de computação mais distribuída, com vários pequenos computadores ao invés de somente um maior.  E esse conceito foi se espalhando.  Se pensarmos hoje em dia nos celulares, eles são uma extensão computacional de algo que roda num datacenter.  Temos uma parte do aplicativo rodando localmente, e outra parte na nuvem.

Nesse novo paradigma, não é preciso tanto swap quanto antes.  Meu laptop tem 8 GB de RAM (tinha 12 GB com um pente extra de 4 GB que comprei no Dealextreme, mas o danado teima em dar problema de acesso e travar), mais que suficiente pra muita coisa.

Então resolvi experimentar.

Desabilitei o swap (swapoff /dev/mapper/vg-swap) e comentar a linha que o habilitava durante o boot no /etc/fstab.  E funcionou.  Mas bastou abrir chrome, firefox, thunderbird e eclipse pra coisa ficar feia (claro que a culpa é do java).

root@elx3030vlm-78:vm# head -16 /proc/meminfo 
MemTotal:        7926776 kB
MemFree:          218640 kB
MemAvailable:     889676 kB
Buffers:           57568 kB
Cached:           750036 kB
SwapCached:            0 kB
Active:          6672176 kB
Inactive:         404504 kB
Active(anon):    6282356 kB
Inactive(anon):    55548 kB
Active(file):     389820 kB
Inactive(file):   348956 kB
Unevictable:       65852 kB
Mlocked:           65852 kB
SwapTotal:             0 kB
SwapFree:              0 kB

Quando chega próximo do limite de memória, eu simplesmente tenho de aguardar o kernel decidir matar alguma coisa pra eu conseguir mandar um comando.  Até fiz um vídeo pra mostrar a situação.

{youtube}ga8lG2xE7wc{/youtube}

Nessas ocasiões a carga do sistema vai às alturas, provavelmente por troca de contexto de processos no kernel, tentando achar memória onde não tem.

Quando isso acontece, uma mudança do ambiente gráfico pro console e um reinicio do mesmo resolve.  Mas é chato.

Esses são os load averages que consegui enquanto gerava o vídeo acima:

 12:51:51 up 21:12,  6 users,  load average: 36.61, 59.21, 75.31
 13:01:24 up 21:21,  6 users,  load average: 57.21, 51.78, 61.71
 13:29:59 up 21:50,  6 users,  load average: 110.99, 122.08, 107.70

Então melhor com swap?  Não é tanto assim.  O sistema evoluiu, mas o problema de gerenciamento de memória é coisa do Linux.  Com swap esse tipo de problema também acontece, só demora mais.  Eu já tinha visto isso justamente com criação de vídeo no kdenlive.  Tinha um bug no melt, possivelmente um memory leak, que ia consumindo toda a memória.  Travava?  Não, mas tinha de aguardar o kernel matar o melt pra conseguir voltar.  Isso levava de 4 a 6 horas.  Usando somente RAM acontece o mesmo, mas é mais rápido, por volta de 20 ou 30 minutos.

Eu tentei achar alguma referência de tunning pra ajudar.

Memory Management Approach for Swapless Embedded Systems

When Linux Runs Out of Memory

http://linux-mm.org/LinuxMMDocumentation

O problema é que a maioria das informações são antigas.  No kernel que estou usando, 3.17.7, não tem esses parâmetros.  Mas eu tentei melhorar a responsividades alterando algumas coisas:

vm.laptop-mode = 1
vm.memory_failure_early_kill = 1
vm.memory_failure_recovery = 1

O resultado foi bastante satisfatório e agora o sistema tem estado mais responsivo durante alta carga que exige alocação de memória.  E com mensagens interessantes vindas do kernel.

Out of memory: Kill process 24223 (chromium-browse) score 332 or sacrifice child
Killed process 24223 (chromium-browse) total-vm:1360048kB, anon-rss:242548kB, file-rss:15632kB

Gosto de um sistema que exige sacrifícios.

Removendo um arquivo -C

Categoria: Linux Publicado: Sexta, 21 Novembro 2014 Escrito por Helio Loureiro

Isso mesmo.  Olhando meus diretórios pra começar um backup, percebi que criei um arquivo com nome "-C".  Provavelmente resultando de alguma comando errado.

O que fazer nesse caso?  Em geral comandos como "rm" e "mv" não funcionam pois interpretam o "-C" como uma opção do comando, não como arquivo.

Existem várias formas de resolver isso, inclusive algumas mais fáceis via interface gráfica usando nautilus/dolphin ou algo do gênero.  Mas vou mostrar a "forma UNIX" de resolver isso.

Primeiramente, onde está o danado do arquivo?

helio@linux:home$ ls
backup -C helio fisl lost+found support

No caso estava no meu diretório "/home".  E o que era o arquivo?

helio@linux$ home# ls -l
total 646124
drwxr-xr-x 2 root root 4096 Nov 21 09:41 backup
-rw-r--r-- 1 root root 661555200 Oct 9 12:05 -C
drwxr-xr-x 367 helio linux 36864 Nov 21 09:43 helio
drwxr-xr-x 6 fisl fisl 4096 Mar 5 2014 fisl
drwx------ 2 root root 16384 Nov 16 2013 lost+found
drwxr-xr-x 5 support admin 4096 May 17 2013 support

Agora vem o truque.  Cada arquivo criado no seu filesystem tem junto um número de i-node, que é onde ele foi efetivamente gravado no disco.  É possível usar a opção "-i" do comando "ls" pra verificar cada número de i-node de cada arquivo do diretório, seja um arquivo, seja um diretório, ou seja qualquer outra coisa (em Unix, tudo é arquivo).

root@linux:home# ls -i
15335425 backup 4741 -C 16252929 helio 14942209 fisl 11 lost+found 15466497 support

Verificado qual o número do i-node, 4741, agora é usar o comando "find" com opção de "-inum" pra mexer nesse arquivo, junto com um "-exec".  Na opção "-exec", o arquivo encontrado é substituído pelo "{}", que é como se fosse uma variável com o que foi encontrado pelo parâmetros anteriores, no caso o "-inum".  

Então basta usar isso pra renomear o arquivo pra qualquer outro nome.

root@linux:home# find . -maxdepth 1 -inum 4741 -exec mv {} arquivo_alien \;

Verificando...

root@linux:home# ls
backup helio fisl lost+found support arquivo_alien

Agora descobrindo o que é esse arquivo.

root@linux:home# file arquivo_alien
arquivo_alien: POSIX tar archive (GNU)
root@linux:home# mv arquivo_alien arquivo_alien.tar
root@linux:home# tar tvf arquivo_alien.tar
drwxr-xr-x root/root 0 2014-10-09 12:05 home/
drwxr-xr-x fisl/fisl 0 2014-03-05 10:16 home/fisl/
drwxr-xr-x fisl/fisl 0 2014-03-05 10:16 home/fisl/.purple/
-rw-r--r-- fisl/fisl 173 2014-03-05 10:16 home/fisl/.purple/blist.xml
drwxr-xr-x fisl/fisl 0 2013-07-04 22:21 home/fisl/.purple/certificates/

Realmente um arquivo do tipo tar.  Provavelmente de algum backup que tentei fazer e passei a opção de forma errado.  Sem stress e problema resolvido.

root@linux:home# rm arquivo_alien.tar

unrpm

Categoria: Linux Publicado: Terça, 19 Agosto 2014 Escrito por Helio Loureiro

unRPM

Apesar de adorar Debian e Ubuntu, o trabalho me exige mexer com pacotes RPM.  Ao contrário do format DEB, os pacotes RPM são mais simples de gerar.  Basta ter um arquivo SPEC, que informa os dados dos pacote como dependência e scripts para instalação, que é possível gerar usando rpmbuild.  Mesmo num Debian/Ubuntu.

Mas cai no caso de uma aplicação de opensaf já compilada.  E precisava gerar um pacote só com versão diferente, pra testar uma campanha de upgrade.  A solução seria desmontar o pacote RPM e montar novamente.  Um "unrpm" por assim dizer.  Eu tentei usar um pacote "rpmrebuild", mas o mesmo é feito pra sistemas já com uso de RPM, e precisa que o pacote esteja instalado pra conseguir reconstuir o mesmo.  Com certeza não o meu caso.

A parte do conteúdo não é difícil de fazer pois o pacote RPM é na verdade um arquivo de CPIO.  Usando como exemplo o pacote aalib-libs do fedora 20, com comandos rpm é possível ver as informações do pacote e seu conteúdo:

helio@debian:~$ rpm -qip aalib-libs-1.4.0-0.23.rc5.fc20.x86_64.rpm
warning: aalib-libs-1.4.0-0.23.rc5.fc20.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY
Name : aalib-libs
Version : 1.4.0
Release : 0.23.rc5.fc20
Architecture: x86_64
Install Date: (not installed)
Group : System/Libraries
Size : 159154
License : LGPLv2+
Signature : RSA/SHA256, Fri 16 Aug 2013 05:21:44 PM CEST, Key ID 2eb161fa246110c1
Source RPM : aalib-1.4.0-0.23.rc5.fc20.src.rpm
Build Date : Sat 03 Aug 2013 02:17:12 AM CEST
Build Host : buildvm-07.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : http://aa-project.sourceforge.net/aalib/
Summary : Library files for aalib
Description :
This package contains library files for aalib.
helio@debian:~$ rpm -qlp aalib-libs-1.4.0-0.23.rc5.fc20.x86_64.rpm
warning: aalib-libs-1.4.0-0.23.rc5.fc20.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY
/usr/lib64/libaa.so.1
/usr/lib64/libaa.so.1.0.4
/usr/share/doc/aalib-libs
/usr/share/doc/aalib-libs/COPYING
/usr/share/doc/aalib-libs/ChangeLog
/usr/share/doc/aalib-libs/NEWS
/usr/share/doc/aalib-libs/README

Com o comando rpm2cpio seguido de cpio, é possível verificar que o conteúdo é o mesmo, sem perdas.

helio@debian:~$ cat aalib-libs-1.4.0-0.23.rc5.fc20.x86_64.rpm | rpm2cpio - | cpio -itv
lrwxrwxrwx 1 root root 14 Aug 3 2013 ./usr/lib64/libaa.so.1 -> libaa.so.1.0.4
-rwxr-xr-x 1 root root 125872 Aug 3 2013 ./usr/lib64/libaa.so.1.0.4
drwxr-xr-x 2 root root 0 Aug 3 2013 ./usr/share/doc/aalib-libs
-rw-r--r-- 1 root root 25265 Apr 26 2001 ./usr/share/doc/aalib-libs/COPYING
-rw-r--r-- 1 root root 3649 Apr 26 2001 ./usr/share/doc/aalib-libs/ChangeLog
-rw-r--r-- 1 root root 764 Apr 26 2001 ./usr/share/doc/aalib-libs/NEWS
-rw-r--r-- 1 root root 3604 Apr 26 2001 ./usr/share/doc/aalib-libs/README
314 blocks

Para extrair o conteúdo, bastaria usar as opções "-idv" do cpio.

Mas ainda falta os scripts de instalação que fazem a parte de pré-instalação, pós-instalação, pré-remoção e pós-remoção.  Como escolhi um pacote de biblioteca, esses não precisam de algo assim.  Pegando um pacote de servidor, no caso o bind - servidor de dns, é possível ver esses scripts que compões o SPEC.  Basta usar o comando "rpm --scripts -qp <pacote>".

helio@debian:~$ rpm --scripts -qp bind-9.9.4-8.fc20.x86_64.rpm
warning: bind-9.9.4-8.fc20.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY
preinstall scriptlet (using /bin/sh):
if [ "$1" -eq 1 ]; then
/usr/sbin/groupadd -g 25 -f -r named >/dev/null 2>&1 || :;
/usr/sbin/useradd -u 25 -r -N -M -g named -s /sbin/nologin -d /var/named -c Named named >/dev/null 2>&1 || :;
fi;
:;
postinstall scriptlet (using /bin/sh):
/sbin/ldconfig

if [ $1 -eq 1 ] ; then
# Initial installation
/usr/bin/systemctl preset named.service >/dev/null 2>&1 || :
fi
if [ "$1" -eq 1 ]; then
# Initial installation
[ -x /sbin/restorecon ] && /sbin/restorecon /etc/rndc.* /etc/named.* >/dev/null 2>&1 ;
# rndc.key has to have correct perms and ownership, CVE-2007-6283
[ -e /etc/rndc.key ] && chown root:named /etc/rndc.key
[ -e /etc/rndc.key ] && chmod 0640 /etc/rndc.key
fi
:;
preuninstall scriptlet (using /bin/sh):
# Package removal, not upgrade

if [ $1 -eq 0 ] ; then
# Package removal, not upgrade
/usr/bin/systemctl --no-reload disable named.service > /dev/null 2>&1 || :
/usr/bin/systemctl stop named.service > /dev/null 2>&1 || :
fi
postuninstall scriptlet (using /bin/sh):
/sbin/ldconfig
# Package upgrade, not uninstall

/usr/bin/systemctl daemon-reload >/dev/null 2>&1 || :
if [ $1 -ge 1 ] ; then
# Package upgrade, not uninstall
/usr/bin/systemctl try-restart named.service >/dev/null 2>&1 || :
fi

Com essas informações é possível construir um pacote RPM binário.  Claro que no caso isso não é necessário pois bastaria pegar o pacote SRC e fazer o build novamente.  No meu caso, eu não sabia onde estavam os fontes e essa forma foi muito mais rápida, ainda mais que eu só precisava modificar a informação de versão pra testar upgrade.

GNU e Linux: sem um não existiria o outro. Tem certeza?

Categoria: Linux Publicado: Segunda, 18 Agosto 2014 Escrito por Helio Loureiro

Linux BSD

É comum encontrar em fóruns algumas discussões acaloradas sobre o uso do termo "GNU/Linux" ao invés de "Linux", e que o mesmo não seria o que é, pois é somente um kernel, sem o GNU.

Concordo em número, gênero e grau sobre a importância do GNU na história do software livre, e mesmo na do Linux.  Sem a influência de liberdade, Linus nunca teria pensado em ter um sistema completamente aberto.  Mas será mesmo que ele precisava das ferramentas da GNU, ou de outro modo não conseguiria sair do zero?

BSD para quem ama Unix

Em uma entrevista de 1993, Linus Torvalds comenta que não teria nem tentando criar o Linux se o 386BSD existisse.

The choice of GNU generation

Pra quem não lembra, Linux foi criado em 1991, enquanto que o FreeBSD apareceu somente em 1993.  Onde estava o BSD esse tempo todo?

Em 1991, Berkeley estava sofrendo um processo judicial por parte da AT&T, a dona do código fonte do UNIX, que tinha compartilhado com Berkeley durante sua origem, nos anos 70.  O UNIX BSD sempre fora distribuído gratuitamente, e com códigos fontes abertos e livres, sob a licença BSD.  Enquanto a AT&T tinha o UNIX como um projeto de laboratório, uma brincadeira dos engenheiros, isso não importava muito.  Mas no final da década de 80 o UNIX já era muito difundido e usado tanto nas universidades quanto fora delas.  Quando a AT&T chegou ao fim de seu contrato de monopólio das telecomunicações, ela simplesmente resolveu comercializar seu UNIX.  E como lidar com o seu concorrente livre, o BSD?  Não teria problema se continuasse dentro das universidades, mas existia uma empresa que vendia um UNIX derivado do BSD, o BSDi.  Então entra um processo judicial no meio do caminho.

BSD estava na sua versão 4, que incluia o stack recém criado de redes, o TCP/IP.  O processo terminou em 1992, quando foi feito um acordo em que o código BSD seria re-escrito sem a parte que pertencia à AT&T.  Surgia a especificação 4.4BSD-lite.  Nessa época, a revista Dr.Dobbs iniciou uma série de artigos que vinham com o código pra ter o BSD rodando em computadores com o processador i368.  Era o surgimento do 386BSD.

Mas o 386BSD tinha o problema de ter dono, Lynne Jolitz e William Jolitz.  Apesar do código estar totalmente publicado e permitir qualquer um compilar seu próprio UNIX BSD, era preciso passar quase 2 dias aplicando patches de voluntários pra ter o sistema atualizado e funcional.  Nesse ambiente sugiram os sistemas FreeBSD e NetBSD, como uma forma mais colaborativa de participação e manutenação do código.

E o GNU?

Nesse meio tempo entre 1990 e 1993, pode-se dizer que os UNIX BSDs praticamente pararam seu desenvolvimento.  Eles existiam dentro de máquinas PDP, os mini computadores da época, mas não nos computadores pessoais, que era o que Linus usava em casa pra programar.  Os BSDs precisavam do GNU?  Precisavam mas não do GNU como um todo.  Eles usavam o compilador GCC, que foi um dos marcos mais importantes do software livre.  O restante, dos comandos básicos ao kernel, já tinham em BSD.  Linux é um kernel enquanto que FreeBSD é um sistema operacional completo.  E descendente direto do UNIX.

Se Linus tivesse começado um pouco depois, em 92, ele poderia ter construído o Linux em cima de uma base BSD.  E continuaria um software livre.    Vantagens?  Acho que talvez mudasse o licenciamento pra BSD, mas provavelmente seria muito semelhante com o que temos hoje.

Mudar pra BSD ainda é possível?

Possível, é.  Valeria o esforço?  Eu diria que não.  Linux funciona muito bem com a parte GNU.  Se um dia surgisse algum problema de licenciamento, o que é impossível com softwares da GNU, ele poderia eventualmente ter um esforço pra mudar.  

Benefícios de desempenho?  Acho que também não.  Apesar dos BSDs terem um stack de rede com desempenho superior ao do Linux, isso não é imutável e frequentemente acontece de um passar o desempenho do outro.  Recentemente o Facebook anunciou uma iniciativa de melhorar o stack de rede do Linux pra igualar ao do FreeBSD.  Eu espero que supere, pra assim o grupo do BSD ter um objetivo pra melhorar mais :-)

E os BSDs não estão na frente em tudo.  O próprio "grep" da GNU é muito mais rápido e eficiente que seu semelhante BSD, pra listar apenas alguns.

Então, antes de dizer que Linux não seria nada sem o GNU, lembre dos BSD.  Atualmente nem o compilador é mais o GCC, sendo um sistema operacional totalmente funcional sem precisar necessariamente do GNU.  E 100% software livre.

Atualização: Tue Aug 19 18:30:18 CEST 2014

Eu esqueci completamente de comentar (obrigado pelo lembrete Bruno Máximo) mas o Android é um kernel Linux sem GNU, totalmente feito em cima de BSD.  E sim, o desempenho é muito bom.