SELinux: Posso desativar a cópia de determinados arquivos?

Question

Por favor, me desculpe se isso é muito básico e você está tentado a lançar um RTFM para mim. Eu quero impedir que os usuários copiem determinados arquivos enquanto concedem a eles acesso de leitura aos mesmos arquivos. Achei que isso era impossível até me deparar com este exemplo no Wiki do SELinux:

 allow firefox_t user_home_t : file { read write };

Então, eu estava pensando, é possível dar aos arquivos em questão um modo de 0700, por exemplo, e usar o SELinux para conceder acesso de leitura apenas ao aplicativo que os usuários normalmente usariam para ler os arquivos?

Mais uma vez, me desculpe se isso é muito básico, é só que estou com uma agenda apertada e quero dar uma resposta ao meu chefe de uma forma ou de outra (se for possível ou não) assim que possível e eu não sei nada sobre o SELinux, então eu tenho medo de ler por conta própria para determinar se é possível ou não, me levaria muito tempo. Por favor, note que eu não sou avesso a ler per se e apreciaria enormemente os ponteiros para a documentação relevante, se existir.

Então, basicamente, minha pergunta é: existe uma maneira de fazer isso no SELinux ou estou perdendo meu tempo buscando uma alternativa?

P.S. Estou ciente de que conceder acesso de leitura pode permitir que usuários realmente interessados em copiar os arquivos copiem e cole-os de dentro do aplicativo com o qual os lerão; Estou apenas procurando uma primeira linha de defesa.

EDITAR

Para explicar melhor meu caso de uso:

• Os arquivos em questão são uma mistura de texto e binários.
• Eles precisam ser lidos por software comercial proprietário: eles são modelos de simulação para um software de simulação eletrônica.
• Esses modelos são próprios e não queremos que os usuários simulem com eles o vazamento para uso não autorizado.
• O software só precisa ler os modelos e executar alguns scripts desses arquivos; não vai escrever o seu conteúdo em qualquer lugar.
• Em suma, quero que apenas o software de simulação tenha acesso de leitura e execução a esses arquivos, evitando o acesso de leitura para os usuários.

Answer 1

Acho importante observar que o cat não é o problema no meu comentário acima, mas o redirecionamento de shell. Você está tentando restringir a cópia de binários ou arquivos de texto? Se for binários, então acredito que você pode trabalhar com o rbash (veja link ).

No entanto, se forem arquivos de texto, não sei como você pode impedir que alguém simplesmente copie de seu terminal local.

Não tenho certeza se alguma solução geral do SELinux seria útil aqui. Seu aplicativo que lê arquivos precisa gravar dados em qualquer lugar? Se não, e esses arquivos só precisam ser lidos pelo seu aplicativo, você poderia apenas dar acesso de somente leitura do tipo do seu aplicativo aos arquivos do tipo que você gostaria que ele lesse e não escrever em lugar algum.

Acho que mais algumas informações sobre as permissões exatas exigidas pelo seu caso de uso podem ser úteis, desculpe pela resposta vaga.

ATUALIZAÇÃO - RESPOSTA MAIS ESPECÍFICA

Eu acho que você pode conseguir o que quiser sem o SELinux, pois é assim que muitas coisas são tratadas (por exemplo, usuários normais mudando sua senha em / etc / shadow através do comando passwd ):

• Crie um usuário e / ou grupo separado para o seu software comercial (talvez já esteja pronto)
• Conceder acesso somente leitura aos arquivos pelo usuário e / ou grupo mencionado
• Verifique se os usuários normais não têm acesso a esses arquivos
• Faça o seu setuid ou getgid executável (dependendo se você usou um grupo ou usuário) chmod g+s ou chmod u+s
• Quando os usuários executam o aplicativo, eles agora terão as mesmas permissões que o usuário ou grupo do aplicativo, permitindo assim o acesso de leitura a esses arquivos específicos no aplicativo desejado.

UPDATE2 - USUÁRIOS E GRUPOS MÚLTIPLOS Se você tiver vários aplicativos e grupos, provavelmente conseguirá a funcionalidade que está procurando com sudo . Muitas pessoas estão cientes de sua capacidade de permitir que você execute comandos em uma raiz, mas sua utilidade vai muito além desse exemplo. Não tenho certeza se é uma configuração ideal, mas é uma maneira de fazer o que você está tentando.

Ainda é possível criar todos os arquivos de aplicativo de propriedade do aplicativo, mas você pode criar grupos separados para cada conjunto de arquivos. Isso é o que o seu /etc/sudoers ou um arquivo em /etc/sudoers.d/ poderia ter:

User_Alias    FILEGROUP1 = user1, user2
User_Alias    FILEGROUP2 = user3, user4
Cmnd_Alias    MYEDITOR = /usr/local/bin/myeditor, /usr/local/bin/mycompiler

FILEGROUP1    ALL=(:fileset1) NOPASSWD: MYEDITOR 
FILEGROUP2    ALL=(:fileset2) NOPASSWD: MYEDITOR 

Onde user1 e user2 precisam de acesso aos arquivos de propriedade do grupo fileset1 e user3 e user4 precisam de acesso aos arquivos de propriedade do grupo fileset2 . Você também pode usar grupos em vez de usuários.

Os usuários podem acessar seus arquivos através do editor fazendo sudo -g fileset1 /usr/local/bin/myeditor ou algo semelhante.

Pode ser útil criar alguns scripts de wrapper para os comandos sudo -g necessários para seus usuários, especialmente porque parece que pode ser um aplicativo gráfico.

Mais detalhes:

link

link

link

    

Answer 2

Você pode conseguir isso apenas como caranguejo. O problema é que não há "copy ()" syscall. Copiar arquivos é feito lendo a fonte e escrevendo / criando o alvo.

Assim, sua única chance é limitar o acesso a esses arquivos para aplicativos que não permitem fazer cópias. Essa pode ser uma avaliação difícil, já que "não fazer cópias" geralmente não é o destino do design de um aplicativo. O Firefox obviamente parece inadequado para isso.

Mas você pode usar uma solução de dois níveis:

1. Restringir o Firefox para gravar acessos em um determinado diretório (árvore); isso pode se tornar um mal considerando / tmp. Então você pode ter que iniciar o Firefox com $ TMP apontando para algum lugar em seu diretório de configuração.
2. Impede que todos os outros aplicativos (que o usuário pode acessar) leiam esse diretório. (Da minha perspectiva do AppArmor) Isso se resume a proibir o acesso dos processos de login a esses diretórios (para todos os usuários) e a conceder acesso ao Firefox.

Uma abordagem mais genérica, mas indireta: Verifique quais arquivos são criados e compare-os com os proibidos. Isso é bastante fácil se o aplicativo tiver ambos os arquivos abertos simultaneamente, mas isso pode ser uma suposição insegura. Além disso, executar tudo através de strace não torna um sistema mais rápido, é claro. E eu não sei como o FAM / fileschanged é dimensionado em um sistema de arquivos inteiro. Este problema de escala (se existir) pode ser "resolvido", restringindo todas as aplicações (exceto para um gerenciador de arquivos) para escrever acesso em um único diretório (e seu diretório de configuração, é claro) para que apenas este diretório (e / tmp) precisa ser verificado pelo FAM. Você pode registrar os acessos de leitura a todos os arquivos protegidos por processo para acelerar essas verificações. O FAM não pode fazer isso, mas a auditoria do AppArmor pode (então eu acho que o SELinux pode fazer isso também).

Uma solução realmente interessante seria um módulo FUSE para o diretório gravável (para evitar condições de corrida) para fazer a verificação.