Como desabilito o SIP (System Integrity Protection) AKA “sem raiz” nos macOs [OS X]

157

A Apple lançou o System Integrity Protection , também conhecido como "sem raiz", com o OS X 10.11, El Capitan. Entendo que este é um passo para a proteção geral contra malware, mas como desenvolvedor, preciso de acesso de gravação a alguns dos arquivos que ele bloqueia.

Como desabilito essa proteção?

macos sip

— bdnchr
fonte

2

Mesmo que você possa corrigir todos os aspectos do SIP, há muitas entradas para isso - lembre-se de que, comprometendo o sistema, você está criando coisas que podem não ser executadas na máquina do cliente, onde o SIP está ativado, e os usuários não aceitam desativá-lo.

— Motti Shneor

5

@Motti Shneor - No entanto, em alguns casos, isso precisa ser desativado apenas para ter acesso de gravação para instalar alguns SDKs para fins de desenvolvimento. Isso não exigiria que o cliente fizesse o mesmo.

— usar o seguinte

Eu vim do background unix, tentando entender a lógica do rootless: é porque o computador provavelmente é uma máquina de usuário único, tudo será instalado no diretório inicial do usuário, para que não seja necessário mexer no diretório do sistema como / usr / share / vim /.

— Kemin Zhou

148

A documentação da Apple abrange a desativação do SIP, sobre a proteção da integridade do sistema no seu Mac e a configuração da proteção da integridade do sistema .

Um artigo no lifehacker.com lista estas etapas:

Reinicie o seu Mac no modo de recuperação reiniciando o computador e mantendo pressionada Command+ Raté o logotipo da Apple aparecer na tela.

Clique em Utilitários> Terminal.

Na janela Terminal, digite csrutil disablee pressione Enter.

Reinicie o seu Mac.

Você pode verificar se um arquivo ou pasta está restrito emitindo este lscomando usando o capital O (e não zero 0) para modificar o sinalizador de listagem longa:

ls -lO /System /usr

Procure o texto restrito para indicar onde o SIP é imposto.

Por padrão (= SIP ativado), as seguintes pastas são restritas (consulte a página de suporte da Apple ):

/System
/usr
/bin
/sbin
Apps that are pre-installed with OS X

... e as seguintes pastas são gratuitas:

/Applications
/Library
/usr/local

— Mike Scott
fonte

1

Eu vejo de execução ls -lO /usr/localnão está marcado como restrito. Eu também chownd /usr/local/recursivamente. Mas continuo vendo a raiz se apropriar /usr/local/bine o /usr/local/shareque afeta o homebrew. Este também é o trabalho do SIP?

— SaxDaddy

1

@SaxDaddy Desde que /usr/localnão seja restrito, você pode corrigir quaisquer permissões "abaixo" deste diretório facilmente. Na verdade, o Homebrew recomenda executar sudo chown -R $(whoami) /usr/local(enquanto estiver conectado como um usuário administrador) para corrigir problemas de permissão.

— nohillside

4

@SaxDaddy Você está usando o Sophos Anti-Virus, por acaso? Há um problema conhecido no Sophos em que ele altera as permissões nesses diretórios. De acordo com um tópico nos fóruns da comunidade , ele deve ser resolvido em uma atualização que deve ser lançada em breve.

— ND

1

@NDGeek: +1: Brilhante, obrigado! Você ligou corretamente. E vejo que o SAV 9.4.1 (lançado em 18 de novembro de 15) resolveu o problema. Eu tenho essa versão instalada e confirmei que /usr/localagora as permissões estão definidas corretamente.

— SaxDaddy

1

@andro A bandeira -O que ainda funcionam em 10.11.6. Se não funcionar para você, esse é um problema separado e você deve fazer uma nova pergunta.

— Mike Scott

105

É possível desativar o SIP, inicializando no Recovery HD e executando o seguinte comando:

csrutil disable

Também é possível ativar as proteções SIP e desativar seletivamente aspectos dela, adicionando um ou mais sinalizadores ao csrutil enablecomando. Todos exigem a inicialização do Recovery para configurá-los:

Habilite o SIP e permita a instalação de extensões de kernel não assinadas

csrutil enable --without kext

Ativar SIP e desativar proteções do sistema de arquivos

csrutil enable --without fs

Habilitar SIP e desabilitar restrições de depuração

csrutil enable --without debug

Habilite o SIP e desabilite as restrições do DTrace

csrutil enable --without dtrace

Habilite o SIP e desabilite as restrições de gravação na NVRAM

csrutil enable --without nvram

Também tenho um post disponível com mais informações sobre o SIP:

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

— Rich Trouton
fonte

5

Que riqueza de conhecimento bem-vinda. Eu poderia ter de dobrar para baixo nesta :-) recompensa

— bmike

Eu recebo um erro:csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.

— IgorGanapolsky

5

@IgorGanapolsky Leia a resposta. ' desabilite o SIP inicializando no Recovery HD ' .

— Tijolo

13

Se o objetivo é realmente desabilitar o System Integrity Protection, a inicialização na partição do Recovery HD, conforme recomendado anteriormente nas outras respostas aqui, via Command+ rna inicialização, não é a maneira mais rápida de fazer isso.

Você pode combinar a inicialização no modo de usuário único com a inicialização do HD de recuperação em uma combinação de teclas de inicialização não documentada:

https://support.apple.com/pt-BR/HT204904 abrange recuperação normal
mantenha pressionado Command+ r+ spara inicializar no modo de recuperação de usuário único.

Isso leva você apenas ao ambiente mínimo necessário para isso diretamente .

— LangLangC
fonte

7

Seria mais seguro modificá- /etc/pathslo, como /usr/local/binantes usr/bin. Dessa forma, você pode realizar seu trabalho de desenvolvimento /usr/local/binsem precisar desativar o SIP.

As instalações limpas do sistema operacional ordenam /etc/pathsdessa maneira desde o El Capitan, mas se você estivesse atualizando o sistema operacional do Yosemite ou anterior, teria que modificar a ordem do caminho manualmente.

— user260467
fonte

@iconoclast Antes do El Capitan, uma convenção comum era instalar programas no usr/bin. Como o SIP impede isso agora, os programas devem ser instalados usr/local/bin, o que não é restrito pelo SIP. Ao colocar em usr/local/binprimeiro lugar, os usuários podem executar programas sem precisar digitar o caminho absoluto para o programa. Isso faz sentido? Você está confuso sobre outra coisa?

— user260467

Sempre entendi que é uma prática muito ruim colocar algo /usr/bin... mas acho que o que eu deveria ter perguntado é "como isso responde à pergunta da OP?" Eu estava originalmente supondo que ele fez , de alguma forma, e que eu não estava fazendo a conexão. Mas agora tenho muita dúvida de que ele tenha alguma conexão.

— Iconoclast

@iconoclast Eu acho que seria irresponsável não mencionar para um desenvolvedor que eles realmente não deveriam desativar o SIP apenas para desenvolver um aplicativo.

— user260467

6

Se tudo o que você precisa é acessar / usr / local, consulte esta página: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md

A idéia é desativar temporariamente o SIP usando csrutil disable, adicionar /usr/local, usar chflags para definir esse diretório como não restrito

 sudo mkdir /usr/local && sudo chflags norestricted /usr/local && sudo chown -R $(whoami):admin /usr/local

e, em seguida, reative o SIP usando csrutil enable.

Se /usr/localjá existe no momento da sua atualização, mesmo os itens acima não são necessários. Você pode simplesmente executar

sudo chown -R $(whoami):admin /usr/local

— m_cuffa
fonte

Eu continuo recebendo um erro:Read-only file system

— IgorGanapolsky 5/16

Este link está morto: erro 404.

— Iconoclast

2

Se você não conseguir entrar no Recovery Partition para executar csrutil disable(para desativar o SIP ), tente definir argumentos de inicialização com o nvramcomando, por exemplo

sudo nvram boot-args="rootless=0"

No entanto, se você tiver o seguinte erro:

nvram: Erro ao definir variável - 'boot-args': (iokit / common) não permitido

então não vai funcionar. Você ainda precisa inicializar o modo de recuperação / segurança.

Vejo:

— kenorb
fonte

nvram: Error setting variable - 'boot-args': (iokit/common) not permitted

— mghicks 25/01

1

@ mghicks Nesse caso, não vai funcionar. Eu atualizei a resposta.

— kenorb 25/01

0

Não tenho reputação suficiente para adicionar isso como um comentário ao link do github Homebrew 404 acima. A Wayback Machine ainda possui:

http://web.archive.org/web/20160117204214/https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md

— Setaa
fonte