Eu instalei uma certa ROM que vem com o SELinux no modo "Permissivo". Esta é a única (boa) ROM que se encaixa corretamente no meu dispositivo e não há como alterar o estado do SELinux.

Agora não tenho muita certeza de quais são as consequências de tal decisão e ficaria feliz se alguém pudesse me explicar (eu pesquisei no Google e sei o que é teoricamente ... mas não na prática). Como a ROM tem sua raiz "desativada", o dispositivo está supostamente não enraizado, mas como isso se encaixa no SELinux, não tenho certeza.

TL; DR: Sinta-se livre para pular diretamente para a conclusão na parte inferior, se quiser :)!

O objetivo do SELinux é impedir a escalação de privilégios aplicando uma política obrigatória que restringe possíveis ações de usuários não privilegiados e privilegiados.

O termo "usuários" aqui também inclui qualquer processo em execução no dispositivo, independentemente de estar diretamente relacionado às ações físicas do usuário (o humano, você;)), pois todo processo está em execução usando uma conta de "usuário" do sistema.

Historicamente, as permissões em sistemas baseados em Unix são tratadas usando o que é chamado de sistema DAC (Discretionary Access Control). Neste modelo:

• Recursos como arquivos têm proprietários que podem definir direitos de acesso sobre os recursos que possuem: isso permite que eles decidam se um recurso específico deve ser privado (somente o proprietário pode acessá-lo) ou se deve ser compartilhado com outros usuários.
• Além disso, você tem o superusuário (chamado rootem sistemas baseados em Unix), que é o usuário administrativo e tem acesso a tudo no sistema. Essa conta pode ser usada interativamente por um ser humano (normalmente um administrador do sistema) para manter ou reparar o dispositivo, mas geralmente essa conta será usada principalmente por serviços de segundo plano ou de baixo nível que exigem esse nível de privilégio: drivers de dispositivo, serviços de configuração de rede, serviços necessidade de acessar arquivos de todos os usuários ou lidar com a comunicação interna entre usuários.

Isso é muito bom e já oferece uma boa segurança. No entanto, que tal circunstâncias como estas:

1. O que aconteceria se fosse encontrado um erro em um serviço rootque permitisse ao invasor induzir esse serviço a executar algum código arbitrário? Esse invasor obteria um acesso completo ao dispositivo. Para dar alguns exemplos concretos, esse bug pode ser acionado enviando informações de configuração de rede ( DHCP ) especialmente criadas ou um MMS para o telefone.
2. O que aconteceria se algum usuário não protegesse os recursos privados corretamente? Em seguida, esses recursos podem ser acessados ​​com códigos maliciosos (lidos, talvez até modificados ou excluídos) por outros usuários não privilegiados. Normalmente, é o que você tem quando um aplicativo mal-intencionado está sendo executado no seu telefone (não importa se você foi enganado a instalá-lo ou se veio aqui sozinho usando um bug em outro aplicativo não privilegiado, navegador ou cliente de email para exemplo) e esse aplicativo mal-intencionado tenta acessar diretamente os dados ou locais de armazenamento de outros aplicativos (pode fazê-lo para acessar dados normalmente inacessíveis ou instalar-se em vários locais para dificultar sua remoção).

Aí vem o SELinux.

O SELinux é um sistema de controle de acesso obrigatório (MAC). Enquanto no sistema DAC descrito anteriormente, os usuários eram responsáveis ​​por definir os direitos apropriados em seus próprios recursos, com um sistema MAC uma política de todo o sistema (fornecida com o sistema operacional) é aplicada a usuários privilegiados e não privilegiados.

Isso resolve os dois problemas mencionados acima das seguintes maneiras:

1. Como eu disse, essa política também se aplica a usuários privilegiados. Isso significa que, com uma política projetada adequadamente, um serviço projetado para lidar com a configuração de rede do dispositivo não poderá fazer mais nada: não terá acesso ao SMS, por exemplo, e um serviço que manipula o SMS não terá acesso à configuração de rede , e nenhum deles terá acesso aos dados do usuário, apesar de ambos estarem em execução usando a conta de superusuário.
2. O Android incluiu recentemente um recurso multiusuário, imposto pelo SELinux, impedindo que qualquer usuário acesse os dados de outros usuários. Além disso, a política do SELinux também é responsável por descrever o comportamento permitido dos aplicativos e, provavelmente, mesmo se alguns recursos não estiverem adequadamente protegidos usando o sistema DAC, o SELinux virá em socorro e ainda impedirá que o aplicativo mal-intencionado os acesse diretamente.

Os sistemas DAC e MAC não são mutuamente exclusivos; pelo contrário, o sistema MAC (SELinux) atua como uma segunda camada de defesa atrás do sistema DAC (as permissões tradicionais do tipo Unix). O trabalho do SELinux é bloquear qualquer atividade contrária à política que, dado apenas o sistema DAC, seria aceita de outra forma.

O mais complicado é que essa política pode ser muito complexa de escrever: ela deve realmente cobrir os componentes de todos os dispositivos para todos os usos possíveis em todas as situações. De fato, não importa se alguma ação pode ser legítima na sua situação: se não estiver na política, é proibida . Políticas mal projetadas podem, portanto, ter consequências aleatórias, como falhas no aplicativo, funcionalidade inutilizável e assim por diante.

É por isso que as primeiras versões do Android SELinux o incluíram no modo "Permissivo" por padrão. Nesse modo, o SELinux registrará violações de política, mas não tentará bloquear a atividade associada. Ao analisar os arquivos de log resultantes, torna-se possível corrigir e aprimorar a política até o ponto em que a única violação de política restante é de fato comportamentos maliciosos ou indesejados. Neste ponto, o SELinux pode ser transformado no modo "Execução": agora não apenas registrará, mas também bloqueará todas as ações ofensivas.

Conclusão

SELinux é uma técnica de mitigação. Ele não impede que os invasores entrem no telefone, mas garante que, uma vez lá, eles possam fazer o mínimo possível, idealmente nada útil, eliminando o interesse de atacar o telefone.

Quanto mais antiga a ROM, maior o número de bugs de segurança que abririam esse acesso. O SELinux seria uma maneira eficiente de manter um mínimo de segurança, apesar dessas vulnerabilidades conhecidas, mas para funcionar corretamente, o SELinux depende de uma política complexa.

Se sua ROM é fornecida com o SELinux no modo "Permissivo" por padrão, isso provavelmente significa que a política que ele contém não é confiável o suficiente para ser alterada com segurança para o modo "Execução".

Se você é técnico o suficiente e tem acesso ao registro telefônico ( dmesgpelo menos, mas geralmente eles também são copiados logcat: existem aplicativos que permitem ver o último, mas, dependendo da versão do Android, eles podem exigir acesso root), você pode verificar se você encontra entradas "avc": estas são mensagens informando que o SELinux acabou de detectar uma ação contrária à política.

Aqui está um exemplo de tal entrada retirada do site da CyanogenMod :

type=AVC msg=audit(1363289005.532:184): avc: denied { read } for pid=29199 comm="Trace" 
name="online" dev="sysfs" ino=30 scontext=staff_u:staff_r:googletalk_plugin_t 
tcontext=system_u:object_r:sysfs_t tclass=file

Se não houver, apenas alguns deles ou por algum motivo que você ache que eles não o impedirão de usar o telefone, tente mudar o SELinux para o modo "Execução". Nas ROMs CyanogenMod mais antigas, isso era fácil e possível simplesmente usando uma opção oculta na GUI (não é necessário fazer o root do telefone ou instalar qualquer aplicativo específico), não sei se outras ROMs ofereceram o mesmo recurso, mas desde que você usou o CyanogenMod Eu suponho que você possa ter sorte;).