Segurança, privacidade e recuperação

Modelo de ameaças inicial

O Flowral integra compositor, serviços com privilégios, ferramentas que executam comandos locais e providers remotos de IA. Os riscos principais são: execução arbitrária por MCP malicioso, vazamento de tokens, manipulação de configurações por terceiros, escalonamento indevido de privilégios, atualizações com origem não verificada e operações destrutivas em disco.

Princípios

Privilégio mínimo: UI executa como usuário comum, não como root.
Aprovação explícita: ações de partições, pacotes de sistema, habilitar servidores executáveis e alterar usuários exigem confirmação clara.
Isolamento e escopos: definir capabilities por projeto, agente, servidor e sessão. Nada de escopo global automático.
Credenciais seguras: preferir armazenamento de segredos mantido e auditado (keyring/libsecret, conforme viabilidade) ou variáveis de ambiente gerenciadas; nunca construir cifragem caseira.
Origem verificável: hashes/assinaturas/version pin para downloads, releases e builds.
Rollback: backup anterior a mudanças de tema, config do Swirl, provider, MCP, monitor e pacotes.
Transparência: mudanças explicadas antes de aplicar; logs legíveis com segredos redigidos.

Policy engine de comandos

Classificar por níveis:

Read-only: ver estado de rede, hardware, XBPS, MCP registry sem credenciais.
User config: wallpaper, cores, fontes, theme, configurações locais; sem elevar privilégios.
Privileged: habilitar daemon, instalar/remover XBPS, gestão de usuários, partições; polkit + helper allowlisted.
Risky execution: MCP stdio, agentes capazes de shell, comandos arbitrários; autorização por app/projeto/sessão, não apenas autenticação de sistema.

Helper privilegiado não recebe shell scripts arbitrários; recebe mensagens tipadas e allowlisted (ex.: InstallPackages {packages: Vec<PackageId>}), valida inputs e faz logging redigido. Aplicativo nunca solicita senha para armazená-la.

MCP e agentes

Ao instalar MCP local mostrar comando exato e publisher; pedir aceite para download/execução.
Permitir desativar MCP por cliente/projeto, não compartilhar tokens entre servidores.
Sempre mostrar endpoint externo e implicações de transferência de dados em providers.
Agent/ACP com workspace roots declarados; operações fora do workspace exigem autorização especial.
Logs de ACP/MCP ocultam Authorization, apiKey, env vars sensíveis e tokens em headers.
Sessões de IA não fazem autostart; processos órfãos de MCP/agent são encerrados.
Nunca executar agente como root para ‘resolver permissão’.
Transporte não garante segurança: validação de servidor, timeouts e verificação de outputs permanecem necessários.

Privacidade e rede

Nenhuma telemetria obrigatória. Crashes/analytics apenas opt-in quando implementados. Preferir offline quando possível. Provider cloud só é invocado quando o usuário inicia sessão ou teste consciente; mostrar custo/endpoint sempre que conhecido.

Atualizações e supply-chain

XBPS repositórios confiáveis, chaves de assinatura e verify; packages locais documentados, reprodutíveis. Flatpak/AppImage/upstream binaries: checksum, fornecedor e manifest, sem downloads de URLs desconhecidas pela interface. Atualizar/configurar ferramentas proprietárias exige respeitar termos de licença.

Plano de recuperação

TTY de manutenção, fallback void-installer, backup config em $XDG_STATE_HOME/flowral, rollback themes/outputs, inicialização com compositor fallback quando Swirl falhar, instruções para recuperar conexões e pacotes. Teste de instalação sempre em VM/disco sacrificial antes do E430.

Aceite

Config e segredo não aparecem em logs; helper recusa payload arbitrário; provider HTTPS funciona com keyring; falhas e cancelamentos deixam arquivos consistentes; ações de root solicitam confirmação/autorização granular; recovery inicia sem desktop.

Gates de UI de sessão e automação

O Slint MCP é ferramenta de teste sem autenticação, de acesso local; não habilitar em release nem expor endpoint de debug. Capturas reais de GUI nunca devem coletar janelas sensíveis por padrão. A VM automatizada é descartável, isolada e não monta discos do host para escrita.

Tela de login: manter greetd como backend de autenticação; Flowral Greeter, se implementado, é apenas frontend e deve usar IPC oficial. Bloqueio: não substituir swaylock por janela comum. Lock nativo exige ext-session-lock-v1, autenticação auditada, comportamento fail-closed e recuperação segura de sessão. Notificações: garantir que só um daemon seja dono do nome freedesktop.Notifications por sessão; não persistir conteúdos privados.