Sinter

Sinter é um agente de segurança de endpoint 100% em modo de usuário para macOS 10.15 e superior, escrito em Swift.

Sinter utiliza a API EndpointSecurity em modo de usuário para se inscrever e receber callbacks de autorização do kernel do macOS, para um conjunto de tipos de eventos relevantes para segurança. A versão atual do Sinter suporta permitir/negar execuções de processos; em versões futuras pretendemos suportar outros tipos de eventos, como eventos de arquivo, socket e kernel.

Sinter é um trabalho em andamento. Feedback é bem-vindo. Se você tiver interesse em contribuir ou nos patrocinar para ajudar a atingir seu potencial, entre em contato.

Funcionalidades

• Permitir ou negar execução de processos por hash do diretório de código (também conhecido como "CD hash")
  • opção para negar todos os programas desconhecidos (qualquer programa que não esteja explicitamente permitido)
  • opção para negar todos os programas não assinados
  • opção para negar todos os programas com assinaturas inválidas
• modo "monitor" para rastrear e registrar (mas permitir) todos os eventos de execução de processos
• Aceita regras de permitir/negar de um servidor de sincronização Santa
• Configurar regras de negação em JSON, fornecidas localmente ou por um servidor de sincronização
• Registrar no sistema de arquivos local em formato JSON estruturado

Funcionalidades planejadas futuras:

• Negar execução de processos por caminho do arquivo executável
• Negar execução de processos por ID da equipe do certificado

Anti-Funcionalidades

• Não utiliza extensões de kernel (que serão oficialmente descontinuadas no macOS 11 Big Sur)
• Não suporta macOS legado (10.14 ou anterior)
• Não utiliza nenhum código inseguro de memória
• Limita dependências de bibliotecas de terceiros
• Não é um anti-malware ou antivírus. Sem banco de dados de assinaturas. Nega apenas o que você mandar negar, usando regras.

Contexto

A primeira solução de código aberto para macOS para permitir/negar processos foi o Google Santa. Somos fãs do Santa e contribuímos com sua base de código no passado. Por muito tempo, no entanto, muitos na comunidade macOS pediram uma solução de código aberto para rastrear e gerenciar mais do que apenas eventos de processo.

Vimos a plataforma ideal para construir essa capacidade com a API EndpointSecurity no macOS 10.15. Começar do zero em torno de uma API estritamente em modo de usuário significava que poderíamos tentar um design mais simples e usar uma linguagem de programação moderna com tratamento de memória mais seguro e melhor desempenho. Assim, partimos para desenvolver o Sinter, abreviação de "Sinter Klausen", outro nome para o Papai Noel.

Primeiros Passos

Baixe e instale a versão mais recente do Sinter usando o link do instalador pkg na página de Releases.

Após instalar o Sinter, você deve habilitar a permissão "Acesso total ao disco" para Sinter.app. Faça isso abrindo Preferências do Sistema, guia Segurança e Privacidade, Acesso total ao disco. Marque o item para Sinter.app. Se estiver usando MDM, você pode ativar automaticamente essa permissão em seus endpoints, e nenhuma interação do usuário será necessária.

Configuração

O Sinter requer que um arquivo de configuração esteja presente em /etc/sinter/config.json. Um exemplo é fornecido na árvore de origem em ./config/config.json:

{
  "Sinter": {
    "decision_manager": "local",
    "logger": "filesystem",

    "allow_unsigned_programs": "true",
    "allow_invalid_programs": "true",
    "allow_unknown_programs": "true",
    "allow_expired_auth_requests": "true",
    "allow_misplaced_applications": "true",

    "config_update_interval": 600,

    "allowed_application_directories": [
      "/bin",
      "/usr/bin",
      "/usr/local/bin",
      "/Applications",
      "/System",
      "/usr/sbin",
      "/usr/libexec",
    ],
  },
  
  "FilesystemLogger": {
    "log_file_path": "/var/log/sinter.log",
  },

  "RemoteDecisionManager": {
    "server_url": "https://server_address:port",
    "machine_identifier": "identifier",
  },

  "LocalDecisionManager": {
    "rule_database_path": "/etc/sinter/rules.json",
  }
}

O plugin do gerenciador de decisões pode ser selecionado alterando o valor decision_manager. O plugin local ativará a seção de configuração LocalDecisionManager, apontando o Sinter para usar o banco de dados de regras local presente no caminho fornecido. É possível usar um servidor de sincronização compatível com Santa, utilizando o plugin sync-server em vez disso. Isso ativa a seção de configuração RemoteDecisionManager, onde a URL do servidor e o identificador da máquina podem ser definidos.

Atualmente, existem dois plugins de logger implementados:

1. filesystem: As mensagens são escritas em arquivo, usando o caminho especificado em FilesystemLogger.log_file_path
2. unifiedlogging: Os logs são emitidos usando o Unified Logging, usando com.trailofbits.sinter como subsistema.

Diretórios de aplicativos permitidos

É possível configurar o Sinter para registrar e opcionalmente negar aplicativos que não foram iniciados a partir de uma pasta permitida.

• allow_misplaced_applications: Se definido como true, aplicativos mal colocados gerarão apenas um aviso. Se definido como false, qualquer execução que não inicie a partir de um caminho válido é negada.
• allowed_application_directories: Se não estiver vazio, será usado para determinar se os aplicativos estão na pasta errada.

Ativando notificações de interface do usuário

1. Instale o servidor de notificação (o instalador PKG fará isso automaticamente): sudo /Applications/Sinter.app/Contents/MacOS/Sinter --install-notification-server
2. Inicie o agente: /Applications/Sinter.app/Contents/MacOS/Sinter --start-notification-server

Configurando o Sinter no modo MONITOR

Os modos não são implementados no Sinter, pois tudo é baseado em regras. É possível implementar a funcionalidade de monitoramento ajustando as seguintes configurações:

• allow_unsigned_programs: permitir aplicativos que não são assinados
• allow_invalid_programs: permitir aplicativos que falham na verificação de assinatura
• allow_unknown_programs: permitir automaticamente aplicativos que não são cobertos pelo banco de dados de regras ativo
• allow_expired_auth_requests: a API EndpointSecurity exige que o Sinter responda a uma solicitação de autorização dentro de um prazo não especificado (normalmente, menos de um minuto). Aplicativos grandes, como o Xcode, levarão um tempo considerável para serem verificados. Essas execuções são negadas por padrão, e espera-se que o usuário tente novamente uma vez que o aplicativo tenha sido verificado. Definir esta configuração como true muda esse comportamento para que essas solicitações sejam sempre permitidas.

Formato de regra

Bancos de dados de regras são escritos em formato JSON. Aqui está um exemplo de banco de dados que permite o pacote de aplicativos CMake do cmake.org:

{
  "rules": [
    {
      "rule_type": "BINARY",
      "policy": "ALLOWLIST",
      "sha256": "BDD0AF132D89EA4810566B3E1E0D1E48BAC6CF18D0C787054BB62A4938683039",
      "custom_msg": "CMake"
    }
  ]
}

O Sinter suporta apenas regras BINARY por enquanto, usando políticas ALLOWLIST ou DENYLIST. O valor do hash do diretório de código pode ser obtido da saída da ferramenta codesign (exemplo: codesign -dvvv /Applications/CMake.app). Observe que, embora as ferramentas de CLI possam adquirir o hash SHA256 completo, a API Kernel/EndpointSecurity está limitada aos primeiros 20 bytes.

Construindo a partir do código fonte

Construir o Sinter requer certificados de assinatura de código e permissões que a Apple deve conceder à sua organização. No entanto, o Sinter ainda pode ser construído a partir do código fonte e executado localmente em um sistema de teste com SIP desativado. Para instruções, consulte o wiki do Sinter.

Licença

O Sinter é licenciado e distribuído sob a licença AGPLv3. Entre em contato se você estiver procurando por uma exceção aos termos.