O contexto do caminho do arquivo SELinux não funciona com o regex

Question

Eu reformatei a legibilidade com base nas sugestões nos comentários.

Eu tenho um servidor RADIUS que usa o google authenticator, e o SELinux está impedindo que o RADIUS acesse os arquivos .google_authenticator nos diretórios pessoais dos usuários (esses também são usuários winbind, com diretórios home em /home/API ). Eu tentei dar acesso construindo os seguintes arquivos de política:

$ cat ./google-authenticator.fc 
/home/API(/.*)?/\.google_authenticator      gen_context(system_u:object_r:radiusd_google_authenticator_t,s0)
$ cat ./google-authenticator.te
policy_module(radiusd_google_authenticator, 0.0.10)

require {
  type radiusd_t;
  type user_home_dir_t;
  type admin_home_t;
}

type radiusd_google_authenticator_t;

role object_r types radiusd_google_authenticator_t;

allow radiusd_t radiusd_google_authenticator_t:file { rename create unlink rw_file_perms };

files_type(radiusd_google_authenticator_t)
filetrans_pattern(radiusd_t, user_home_dir_t, radiusd_google_authenticator_t, file, ".google_authenticator")
filetrans_pattern(radiusd_t, admin_home_t, radiusd_google_authenticator_t, file, ".google_authenticator")

A instalação mostra o caminho em semanage fcontext -l , mas não funciona:

 $ sudo semanage fcontext -l | grep google_authenticator
 /home/API(/.*)?/\.google_authenticator             all files          system_u:object_r:radiusd_google_authenticator_t:s0 
 $ matchpathcon /home/API/tcr/.google_authenticator
 /home/API/tcr/.google_authenticator    unconfined_u:object_r:user_home_t:s0

Estranhamente, quando eu o altero para que o caminho corresponda exatamente (mesmo com o período de escape), ele funciona:

$ sudo semanage fcontext -l | grep google_authenticator
/home/API/tcr/\.google_authenticator               all files          system_u:object_r:radiusd_google_authenticator_t:s0 
$ matchpathcon /home/API/tcr/.google_authenticator
/home/API/tcr/.google_authenticator system_u:object_r:radiusd_google_authenticator_t:s0

Ainda mais estranho, o regex funciona quando, como sugerido na resposta de Iain, eu adiciono o caminho diretamente com semanage ao invés dos arquivos de política (removendo o caminho da política primeiro para que não haja conflito):

$ sudo semanage fcontext -l | grep google_authenticator
$ matchpathcon /home/API/tcr/.google_authenticator
/home/API/tcr/.google_authenticator unconfined_u:object_r:user_home_t:s0
$ sudo semanage fcontext -a -t radiusd_google_authenticator_t '/home/API(/.*)?/\.google_authenticator'
$ sudo semanage fcontext -l | grep google_authenticator
/home/API(/.*)?/\.google_authenticator             all files          system_u:object_r:radiusd_google_authenticator_t:s0 
$ matchpathcon /home/API/tcr/.google_authenticator
/home/API/tcr/.google_authenticator system_u:object_r:radiusd_google_authenticator_t:s0

Eu também tentei várias configurações usando HOME_DIR, mas também não tive sorte.

    

Answer 1

Tente usar

HOME_DIR/\.google_authenticator -- gen_context(system_u:object_r:radiusd_google_authenticator_t,s0)

Em vez disso. Os diretórios base não estão necessariamente em / home e isso funciona como uma macro quando você recria a diretiva.

EDITAR

Então, verifiquei o código-fonte e ele fornece o seguinte texto, que provavelmente indica o que está acontecendo aqui.

label_file.c
680     /*
681      * Check for matching specifications in reverse order, so that
682      * the last matching specification is used.
683      */

Regex que combina por último, vença. A biblioteca do SELinux está usando a seguinte ordem de pesquisa de arquivos para corresponder:

/etc/selinux/targeted/contexts/files/file_contexts.subs_dist
/etc/selinux/targeted/contexts/files/file_contexts.subs
/etc/selinux/targeted/contexts/files/file_contexts
/etc/selinux/targeted/contexts/files/file_contexts.homedirs
/etc/selinux/targeted/contexts/files/file_contexts.local

O regex correspondente que vence no seu caso é o seguinte:

grep user_home_t /etc/selinux/targeted/contexts/files/file_contexts.homedirs
/home/[^/]+/.+  user_u:object_r:user_home_t:s0

Ao adicionar a entrada como um contexto local, ela é obtida desse arquivo: /etc/selinux/targeted/contexts/files/file_contexts.local , que aparece após o arquivo que corresponde no momento.

Então, para consertar isso (o que é basicamente um truque), você pode adicionar a entrada como uma substituição local.

Como alternativa, tentei adicionar isso como uma substituição HOME_DIR (como sugeri originalmente, mas usando o audio_home_t para testar o principal) fazendo o seguinte:

HOME_DIR/(tcr)?/\.google_authenticator          --      gen_context(system_u:object_r:audio_home_t)

Isso funcionou para mim, pois acrescentou a entrada para os arquivos posteriores e a 'última regex venceu' quando fiz isso.

Ele realmente mudou o regex para isso no arquivo:

grep tcr /etc/selinux/targeted/contexts/files/*
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:/home/[^/]+/(tcr)?/\.google_authenticator   --  user_u:object_r:audio_home_t:s0

Eu sugeriria tentar a opção HOME_DIR primeiro (que é a maneira atual de implementar a política) ou, alternativamente, usar uma substituição local.

    

Answer 2

Não tenho certeza do que você está tentando fazer, mas se quiser ter um curinga * após a API, para que, por exemplo,

/home/API/one/.google_authenticator
/home/API/two/.google_authenticator
...

todos têm tipo radiusd_google_authenticator_t , então isso parece funcionar

sudo semanage fcontext -a -t mysqld_db_t  "/home/API(/.*)?/.google_authenticator"

Note que usei o mysqld_db_t porque não tenho radiusd_google_authenticator_t

matchpathcon /home/API/one/.google_authenticator
/home/API/one/.google_authenticator     system_u:object_r:mysqld_db_t:s0
matchpathcon /home/API/two/.google_authenticator
/home/API/two/.google_authenticator     system_u:object_r:mysqld_db_t:s0