Por que não dá para confiar nas configurações de Privacy & Security do macOS

 (eclecticlight.co)
1 pontos por GN⁺ 19 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Foi confirmado um problema em que as configurações de Privacy & Security do macOS não refletem o estado real das permissões de acesso
  • Mesmo com o acesso à pasta Documents bloqueado, ocorreu um fenômeno em que o app Insent ainda consegue ler os arquivos
  • Quando o usuário seleciona a pasta diretamente, o sistema TCC considera isso um acesso intencional e remove as restrições
  • Na tela de configurações aparece como bloqueado, mas na prática as restrições de sandbox são removidas e o acesso continua permitido
  • Para bloquear completamente a permissão de acesso, são necessários um comando no Terminal e uma reinicialização, o que pode levar ao risco de perda de controle por parte do usuário

Problema de confiabilidade nas configurações de Privacy & Security do macOS

  • Foi confirmado um caso em que as configurações de Privacy & Security do macOS não refletem com precisão o estado real das permissões de acesso
    • Usando um app simples chamado Insent, ocorreu um fenômeno em que o acesso à pasta Documents era possível na prática mesmo quando aparecia como bloqueado nas configurações
    • Esse problema também pode ser reproduzido da mesma forma no macOS 13.5 e versões posteriores

  • Como o app Insent funciona

    • O botão Open by consent abre e exibe um arquivo de texto arbitrário dentro da pasta Documents com o consentimento do usuário
    • O botão Open from folder permite que o usuário selecione a pasta diretamente e então abre e exibe os arquivos dentro dela
    • No segundo caso, a intenção (intent) do usuário é considerada como permissão de acesso, e o sistema TCC (Transparency, Consent, and Control) autoriza o acesso sem consentimento adicional

  • Procedimento do experimento e resultados

    • Após permitir o acesso a Documents, foi confirmado que o Insent lia os arquivos normalmente
    • Em seguida, ao desativar nas configurações de Privacy & Security o acesso do Insent a Documents, o acesso passou a ser bloqueado
    • No entanto, ao selecionar Documents com Open from folder, o acesso voltou a ser possível, e depois disso Open by consent também passou a funcionar sem restrições
    • Na tela de configurações o acesso continua sendo exibido como bloqueado, mas na prática o Insent continua conseguindo acessar a pasta Documents
    • Para bloquear completamente o acesso, é necessário executar o comando tccutil reset All co.eclecticlight.Insent e reiniciar o Mac

  • Análise do funcionamento interno

    • O Insent é um app notarized comum, sem sandbox nem permissões especiais
    • Com o System Integrity Protection (SIP) ativado, algumas operações são tratadas dentro do sandbox
    • O sandboxd intercepta solicitações de acesso a arquivos e envia ao TCC um pedido de autorização; quando o usuário consente, o acesso é permitido
    • Após o acesso ser desativado, o TCC passa a negar o acesso, mas quando o usuário seleciona a pasta pelo painel Open/Save, o sandboxd deixa de interceptar a solicitação
    • Com isso, o TCC deixa de controlar esse acesso e a pasta passa a poder ser acessada com as restrições de sandbox removidas

  • Causa do problema

    • Quando ocorre um acesso baseado na intenção do usuário, as restrições de sandbox para essa pasta são removidas
    • Essa mudança não é refletida na UI das configurações de Privacy & Security, então parece que está bloqueado, mas na prática o acesso continua permitido
    • Outras pastas protegidas (por exemplo, Desktop e Downloads) funcionam normalmente, e o problema ocorre de forma independente por pasta

  • Conclusão

    • Não é possível confiar no indicador de restrição de acesso do item Files & Folders como reflexo do estado real

      • Mesmo que um app não apareça na lista ou pareça estar bloqueado, em alguns casos ele ainda pode acessar pastas protegidas
      • Depois que a permissão de acesso é concedida uma vez, ela não é revogada sem um comando no Terminal e uma reinicialização, o que traz o risco de o usuário perder o controle sobre o acesso

  • Discussão adicional (resumo dos comentários)

    • Após o experimento, foi levantada a hipótese de que o atributo estendido com.apple.macl foi adicionado à pasta Documents e passou a permitir o acesso do Insent
    • O comando tccutil reset remove as entradas macl do banco de dados, mas o xattr (atributo estendido) pode permanecer, mantendo o acesso
    • Com o SIP ativado, é difícil remover esse atributo, e ele só pode ser apagado no modo de recuperação com o comando xattr -d com.apple.macl path/to/Documents
    • Por isso, o usuário fica em uma situação em que é difícil verificar ou controlar o estado real de acesso do app

Leituras relacionadas

1 comentários

 
GN⁺ 19 일 전
Comentários no Hacker News

  • Para mim, isso parece um problema simples. Se você dá a um app permissão para acessar uma pasta, é natural esperar que ele também possa acessar os arquivos dentro dela

    • É preciso ler a documentação com atenção. A configuração Files & Folders não reflete com precisão o estado real das permissões. Na UI, pode parecer bloqueado, mas o app ainda pode ter acesso irrestrito à pasta Documents
    • O ponto central é que “a permissão foi concedida e depois desativada na UI, mas o acesso ainda continua possível”
    • No início do texto também está explícito que “as configurações de segurança podem mostrar incorretamente o estado real de acesso de um app”
    • Eu esperava que o macOS reconhecesse as pastas já vinculadas pela UI e fizesse a integração no backend, mas isso é tratado como uma simples exceção de caminho, o que desativa a UI. Parece o tipo de coisa que eu enviaria como feedback report. O autor costuma lidar com problemas de Gatekeeper e TCC, então faz sentido
    • O texto está escrito de forma vaga demais. Falta explicar qual é o mecanismo que permanece depois que a permissão é removida

  • Depois de ler o texto, desativei todas as permissões de pasta e testei; o Insent ainda conseguia ler Documents mesmo aparecendo como “None” na UI. Parece uma falha de transparência

    • Fico me perguntando se apps não têm acesso por padrão à pasta home do usuário

  • É a ironia de um OS centrado em GUI. Para bloquear completamente o acesso à pasta Documents, é preciso usar o terminal e executar
    tccutil reset All co.eclecticlight.Insent
    depois reiniciar

    • O Jobs estaria se revirando no túmulo. Dizem que já na era NeXT havia muito desse conflito entre GUI e CLI
    • Também há uns comportamentos estranhos na GUI. Eu desliguei com o Wi‑Fi desativado, mas ao iniciar e fazer login o ícone de Wi‑Fi pareceu ficar ativo por um instante antes de voltar para desativado. Não sei se é só bug visual ou se ele realmente liga por um momento

  • O título seria mais preciso se fosse algo como “apps no macOS mantêm acesso a pastas mesmo depois de o usuário revogar esse acesso”

    • Mas, na prática, o usuário não revogou um acesso específico; ele apenas desativou o acesso geral à pasta. Não há como revogar acessos detalhados individualmente

  • O sistema de sandbox do Mac me lembra o UAC do Windows. É uma estrutura que só aumenta o cansaço do usuário.
    Acho muito melhor a abordagem opcional de contêineres do *nix.
    É especialmente estranho que processos em segundo plano iniciados pelo Terminal mantenham as permissões mesmo depois de o processo pai morrer. Dá a sensação de que todo o sistema de permissões é mais formalidade do que proteção real

    • A Apple devia rever seus anúncios antigos (link do YouTube)
    • Só para constar: UAC não é uma fronteira de segurança, então bypass de UAC não é tratado como vulnerabilidade de elevação de privilégio
    • O problema maior é que muitos desenvolvedores ainda continuam presos ao paradigma antigo de que “tudo pode acessar tudo”. A UX do macOS não é perfeita, mas ter acesso irrestrito como padrão é ainda mais perigoso
    • Além disso, a Apple cria exceções para seus próprios apps. Isso é para não prejudicar a experiência do usuário
    • Isso não é a sandbox do Mac, e sim o sistema TCC. Apps que usam App Sandbox nem sequer podem exibir o prompt de acesso a Documents. Em vez disso, podem manter acesso usando algo chamado Security Scoped Bookmark (link de referência)

  • Além de tccutil reset, também dá para redefinir alternando a permissão nas configurações de segurança, ligando e desligando.
    A UI apenas mostra o estado errado por causa de um bug, mas a permissão real funciona normalmente.
    A cor das caixas de seleção também muda conforme o foco e confunde ainda mais. Isso continua na versão Sequoia.
    Também é curioso como jogos instalados em drives externos pedem acesso a “removable volumes” e acabam enchendo a lista

  • Fico em dúvida se isso é bug, vulnerabilidade de segurança ou simples engano. Estou pensando se vale a pena executar o comando de reset para todos os apps

    • É apenas uma omissão na UI. O sistema interno está funcionando normalmente
    • Isso entra na categoria de bug de UI de segurança. Como impede o usuário de perceber o estado real das permissões, pode até virar caso de CVE
    • É um exemplo de choque entre os procedimentos formais de segurança da Apple e a estrutura real de acesso a arquivos. As configurações deveriam mostrar o estado das permissões com clareza e dificultar a reautorização depois da revogação. E permissões que exigem reiniciar o app já deveriam ter deixado de existir há muito tempo

  • Mesmo nas versões mais recentes do macOS há uma confusão parecida na UI de segurança.
    Em “Full Disk Access”, alguns apps aparecem em cinza, e não dá para distinguir se estão ativados ou desativados.
    Não tem como saber se isso é bug ou se o app realmente tem a permissão

    • A explicação da Apple é vaga. A lista “Files & Folders” apenas mostra o histórico de solicitações de permissão.
      Mesmo ao desligar o Full Disk Access, só algumas pastas sensíveis ficam protegidas, enquanto pastas comuns (Desktop, Documents etc.) continuam acessíveis (documentação da Apple)

  • A causa do problema é o atributo estendido com.apple.macl definido na pasta Documents. Não dá para removê-lo por causa do SIP

    • Isso não é um bug, e sim uma incompatibilidade de UI entre dois sistemas de segurança. A proteção real funciona, mas a UI não consegue representar isso

  • Fico curioso se o mesmo aconteceria no iOS

    • No iOS, apps não podem acessar nada fora do seletor de arquivos ou da própria pasta do app, então o mesmo problema não acontece