O que é realmente o recurso "sem raízes" no El Capitan?

Acabei de aprender sobre o recurso "Sem raiz" no El Capitan e estou ouvindo coisas como "Não há usuário root", "Nada pode modificar /System" e "O mundo terminará porque não podemos obter raiz".

Qual é o recurso "Rootless" do El Capitan em nível técnico? O que realmente significa para a experiência do usuário e a experiência do desenvolvedor? Será que sudo -sainda funcionam, e, em caso afirmativo, como será a experiência de usar um shell como rootmudança?

Primeiro: o nome "sem raiz" é enganoso, pois ainda existe uma conta raiz e você ainda pode acessá-la (o nome oficial, "Proteção da integridade do sistema", é mais preciso). O que realmente faz é limitar o poder da conta root, para que, mesmo que você se torne root, não tenha controle total sobre o sistema. Essencialmente, a idéia é que é muito fácil para malware obter acesso root (por exemplo, apresentando uma caixa de diálogo de autenticação ao usuário, o que fará com que o usuário digite reflexivamente a senha de administrador). O SIP adiciona outra camada de proteção, na qual o malware não consegue penetrar, mesmo que seja enraizado. A parte ruim disso, é claro, é que ela também deve se aplicar às coisas que você está fazendo intencionalmente. Mas as restrições impostas à raiz não são tão ruins; eles não impedem a maioria "normal"

Aqui está o que restringe, mesmo a partir da raiz:

• Você não pode modificar nada em /System, /bin, /sbin, ou /usr(exceto /usr/local); ou qualquer um dos aplicativos e utilitários embutidos. Somente o instalador e a atualização de software podem modificar essas áreas e até mesmo fazem isso ao instalar pacotes assinados pela Apple. Mas como as personalizações normais do estilo OS X entram /Library(ou ~/Library, ou /Applications) e as personalizações no estilo unix (por exemplo, Homebrew) entram /usr/local(ou às vezes /etcou /opt), isso não deve ser um grande problema. Também evita gravações no nível do bloco no disco de inicialização, portanto você não pode ignorá-lo dessa maneira.

  A lista completa de diretórios restritos (e exceções como /usr/localalgumas outras) está em /System/Library/Sandbox/rootless.conf. Obviamente, esse arquivo está em uma área restrita.

  Quando você atualiza para o El Capitan, ele move todos os arquivos "não autorizados" de áreas restritas para /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• Você não pode se conectar aos processos do sistema (por exemplo, aqueles executando nesses locais do sistema) para coisas como depuração (ou alteração de quais bibliotecas dinâmicas eles carregam ou outras coisas). Novamente, não é grande coisa; os desenvolvedores ainda podem depurar seus próprios programas.

  Isso bloqueia algumas coisas importantes, como a injeção de código nos aplicativos internos da Apple (principalmente o Finder). Isso também significa que as dtraceferramentas baseadas em monitoramento do sistema (por exemplo opensnoop) não poderão monitorar e relatar muitos processos do sistema.

• Você não pode carregar extensões do kernel (kexts), a menos que elas estejam devidamente assinadas (por exemplo, pela Apple ou por um desenvolvedor aprovado pela Apple). Observe que isso substitui o sistema antigo para aplicar a assinatura kext (e as formas antigas de ignorá-la). Mas desde a v10.10.4, a Apple tinha uma maneira de ativar o suporte de ajuste para SSDs de terceiros , o motivo número 1 para usar kexts não assinados desapareceu.

• A partir do Sierra (10.12), algumas definições de configuração launchd não podem ser alteradas (por exemplo, alguns daemons de inicialização não podem ser descarregados).

• A partir do Mojave (10.14), o acesso às informações pessoais dos usuários (email, contatos, etc.) é restrito aos aplicativos que o usuário aprovou para acessar essas informações. Isso geralmente é considerado um recurso separado (chamado Proteção de informações pessoais ou TCC), mas é baseado no SIP e a desativação do SIP também o desativa. Consulte: "O que e como o macOS Mojave implementa para restringir o acesso dos aplicativos aos dados pessoais?"

Se você não deseja essas restrições - porque deseja modificar seu sistema além do que isso permite, ou porque está desenvolvendo e depurando algo como kexts que não são práticos sob essas restrições, você pode desativar o SIP. Atualmente, isso requer a reinicialização no modo de recuperação e a execução do comando csrutil disable(e você pode reativá-lo da mesma forma csrutil enable).

Você também pode desativar seletivamente partes do SIP. Por exemplo, csrutil enable --without kextdesabilitará a restrição de extensão do kernel do SIP, mas deixará suas outras proteções no lugar.

Mas pare e pense antes de desativar o SIP, mesmo que temporariamente ou parcialmente: você realmente precisa desativá-lo ou existe uma maneira melhor (compatível com SIP) de fazer o que você deseja? Você realmente precisa modificar algo em /System/Libraryou o que /binquer, ou poderia ir em um lugar melhor como /Libraryou /usr/local/binetc? O SIP pode "parecer" constrangedor se você não estiver acostumado a isso, e existem alguns motivos legítimos para desabilitá-lo, mas muito do que ele impõe realmente é apenas uma prática recomendada.

Para ressaltar a importância de deixar o máximo de SIP ativado o máximo de tempo possível, considere os eventos de 23 de setembro de 2019. O Google lançou uma atualização no Chrome que tentava substituir o link simbólico de /varpara /private/var. Na maioria dos sistemas, o SIP bloqueou isso e não houve efeitos negativos. Em sistemas com o SIP desativado, tornou o macOS quebrado e não inicializável. O motivo mais comum para desativar o SIP foi carregar extensões de kernel não aprovadas (/ assinadas incorretamente) (especificamente drivers de vídeo); se eles apenas desativassem a restrição kext, não teriam sido afetados. Veja o tópico de suporte oficial do Google , uma pergunta e resposta do superusuário e um artigo da Ars Technica .

Referências e informações adicionais: apresentação da WWDC sobre "Segurança e seus aplicativos" , uma boa explicação de Eldad Eilam em quora.com , a revisão da Ars Technica de El Capitan e um artigo de suporte da Apple sobre SIP e um mergulho profundo por Rich Trouton ( que também postou uma resposta a esta pergunta ).

Para mim, isso significa que o DTrace não funciona mais.

O DTrace é semelhante ao ptrace / strace no Linux, pois permite que você veja o que um processo está dizendo ao kernel. Toda vez que um processo deseja abrir um arquivo, gravar um arquivo ou abrir uma porta, etc, ele precisa perguntar ao kernel. No Linux, esse processo de monitoramento ocorre fora do kernel na "área do usuário" e, portanto, as permissões são bastante refinadas. Um usuário pode monitorar seus próprios aplicativos (para corrigir erros, encontrar vazamentos de memória, etc.), mas precisaria ser root para monitorar o processo de outro usuário.

O DTrace no OSX, no entanto, funciona no nível do kernel, tornando-o muito mais eficiente e poderoso, no entanto, requer acesso root para adicionar suas sondas ao kernel e, assim, fazer qualquer coisa. Um usuário não pode rastrear seus próprios processos sem ser root, mas como root, eles podem não apenas observar seus próprios processos, mas de fato TODOS os processos no sistema simultaneamente. Por exemplo, você pode assistir a um arquivo (com o iosnoop) e ver qual processo o lê. Esse é um dos recursos mais úteis de todos os tempos para detectar malware. Como o kernel também lida com a E / S da rede, o mesmo acontece aqui. O Wireshark detecta atividades incomuns da rede, o DTrace informa o processo que envia os dados, mesmo que sejam tão incorporados ao sistema quanto o próprio kernel.

No entanto, a partir de El Capitan, a Apple impediu deliberadamente o DTrace de funcionar - pois foi especificamente direcionado e destacado como algo que o SIP restringe. Por que eles fariam isso? Bem, anteriormente a Apple modificou seu kernel e o DTrace para permitir que alguns processos deixassem de ser monitorados via DTrace (o que incomodou muitos pesquisadores de segurança na época, pois alguns processos estavam agora fora dos limites, mesmo como raiz - incluindo malware). A razão para isso foi proteger o DRM em aplicativos como o iTunes, já que teoricamente alguém poderia DTrace e capturar dados não DRM da memória dos processos.

No entanto, houve uma solução alternativa importante que permitiu que os pesquisadores continuassem realizando seu trabalho e que modificasse o kernel para ignorar esse sinalizador de exclusão, para que o DTrace ainda pudesse ser usado nesses processos. Isso foi realmente ótimo, porque os programas que tentavam evitar a detecção agora se acendiam com esse sinalizador no DTrace. Qualquer coisa que a Apple ou os bandidos quisessem esconder estava agora à vista ...

Mas agora não funciona, então como isso afeta você? Bem, isso afetará você, direta e indiretamente. Diretamente, isso limitará sua capacidade de monitorar seu sistema. Um grande número de ferramentas de administração e monitoramento de sistemas de baixo nível (nas quais ferramentas de nível superior se baseiam) não funcionará mais. O efeito indireto, no entanto, será muito maior - os profissionais de segurança contam com acesso profundo ao sistema para detectar os piores tipos de ameaças. Simplesmente não podemos mais fazer isso. É essencial ao analisar malware que ele não sabe que está sendo executado em um depurador ou honeypot. Desativar o SIP informa a todos os softwares, dos bandidos e da Apple, que esse sistema está sendo monitorado. Não mais assistindo os observadores. Se o SIP fosse sobre segurança, eles poderiam instruir os usuários sobre o root - em vez disso, eles o removeram. Em última análise, isso significa que a Apple substituiu a barreira de segurança 'seja tudo e termine tudo' da senha root, pelo mecanismo de proteção SIP 'seja tudo e termine tudo'. Ou, se você é bom em engenharia social, uma senha root com uma reinicialização ...

Há também isso:

O System Integrity Protection (SIP) é uma política de segurança geral com o objetivo de impedir que arquivos e processos do sistema sejam modificados por terceiros. Para conseguir isso, possui os seguintes conceitos:

• Proteção do sistema de arquivos
• Proteção de extensão do kernel
• Proteção de tempo de execução

Proteção do sistema de arquivos

O SIP impede que outras partes da Apple adicionem, excluam ou modifiquem diretórios e arquivos armazenados em determinados diretórios:

/bin
/sbin
/usr
/System

A Apple indicou que os seguintes diretórios estão disponíveis para os desenvolvedores acessarem:

/usr/local
/Applications
/Library
~/Library

Todos os diretórios, /usrexceto os, /usr/localsão protegidos pelo SIP.

É possível adicionar, remover ou alterar arquivos e diretórios protegidos por SIP por meio de um pacote instalador assinado pela autoridade de certificação da Apple. Isso permite que a Apple faça alterações nas partes do sistema operacional protegidas por SIP sem precisar alterar as proteções SIP existentes.

A autoridade de certificação em questão é reservada pela Apple para uso próprio; Os pacotes do instalador assinado pelo ID do desenvolvedor não podem alterar arquivos ou diretórios protegidos por SIP.

Para definir quais diretórios estão protegidos, a Apple atualmente definiu dois arquivos de configuração no sistema de arquivos. O principal é encontrado no local abaixo:

/System/Library/Sandbox/rootless.conf

onde rootless.conflista todos os aplicativos e o nível superior de diretórios que o SIP está protegendo.

Formulários

O SIP está protegendo os aplicativos principais que o OS X instala nos Aplicativos e Utilitários de Aplicativos. Isso significa que não será mais possível excluir os aplicativos que o OS X instala, mesmo da linha de comando ao usar privilégios de root.

Diretórios

O SIP também está protegendo vários diretórios e links simbólicos fora /Applicationse o nível superior desses diretórios também está listado rootless.conf.

Além das proteções, a Apple também definiu algumas exceções à proteção do SIP no arquivo rootless.conf, e essas exceções são marcadas com asteriscos. Essas isenções da proteção do SIP significam que é possível adicionar, remover ou alterar arquivos e diretórios nesses locais.

Entre essas exceções estão as seguintes:

• /System/Library/User Template - onde o OS X armazena os diretórios de modelo que ele usa ao criar pastas pessoais para novas contas.
• /usr/libexec/cups - onde o OS X armazena informações de configuração da impressora

A Apple considera esse arquivo como seu e que quaisquer alterações de terceiros serão substituídas pela Apple.

Para ver quais arquivos foram protegidos pelo SIP, use o lscomando com dash capital O no Terminal:

ls -O

Os arquivos protegidos por SIP serão rotulados como restritos .

Um pensamento importante a saber é que, mesmo que um link simbólico esteja protegido pelo SIP, isso não significa necessariamente que o diretório ao qual está vinculando esteja sendo protegido pelo SIP. No nível raiz de uma unidade de inicialização do OS X El Capitan, existem vários links simbólicos protegidos por SIP apontando para diretórios armazenados dentro do diretório no nível raiz nomeado private.

No entanto, quando o conteúdo do privatediretório é examinado, os diretórios para os quais esses links simbólicos apontam não são protegidos pelo SIP e eles e seu conteúdo podem ser movidos, editados ou alterados por processos usando privilégios de root.

Além da lista de exceções SIP que a Apple definiu rootless.conf, há uma segunda lista de exceções SIP. Esta lista inclui vários diretórios e nomes de aplicativos para produtos de terceiros. Semelhante rootless.conf, esta lista de exclusão é da Apple e as alterações de terceiros serão sobrescritas pela Apple.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Proteção de tempo de execução

As proteções do SIP não se limitam a proteger o sistema contra alterações no sistema de arquivos. Há também chamadas de sistema que agora estão restritas em sua funcionalidade.

• task_for_pid () / processing_set_tasks () falham com EPERM
• As portas especiais do Mach são redefinidas no exec (2)
• variáveis ​​de ambiente dyld são ignoradas
• Sondas DTrace indisponíveis

No entanto, o SIP não bloqueia a inspeção pelo desenvolvedor de seus próprios aplicativos enquanto eles estão sendo desenvolvidos. As ferramentas do Xcode continuarão permitindo que os aplicativos sejam inspecionados e depurados durante o processo de desenvolvimento.

Para obter mais detalhes sobre isso, recomendo dar uma olhada na documentação do desenvolvedor da Apple para SIP .

Proteção de extensão do kernel

O SIP bloqueia a instalação de extensões de kernel não assinadas. Para instalar uma extensão do kernel no OS X El Capitan com o SIP ativado, uma extensão do kernel deve:

1. Ser assinado com um ID de desenvolvedor para o certificado Signing Kexts
2. Instalar em / Biblioteca / Extensões

Se estiver instalando uma extensão de kernel não assinada, o SIP precisará ser desativado primeiro.

Para obter mais informações sobre o gerenciamento do SIP, consulte o link abaixo:

System Integrity Protection - Adicionando outra camada ao modelo de segurança da Apple