Como o restaurorecon manipula links?

Question

Eu notei que a regra

/usr/sbin/shutdown  --  gen_context(system_u:object_r:shutdown_exec_t,s0)

rotula /usr/sbin/shutdown shutdown_exec_t quando /usr/sbin é um diretório. Mas ele não restaura o mesmo rótulo quando /usr/sbin é um link simbólico para bin e shutdown está em /usr/bin . Por quê? Se /usr/sbin é um link simbólico para bin , existe uma maneira fácil de fornecer aos arquivos que deveriam estar em /usr/sbin os contextos corretos?

Parece que se um inode tiver 2 links físicos para ele e os caminhos tiverem contextos de arquivo padrão diferentes, o contexto do arquivo resultante será diferente dependendo de qual caminho é fornecido para restorecon . Que contexto terá se eu renomear o sistema de arquivos inteiro? É determinista? Está certo ou bom fazer isso?

    

Answer 1

restorecon não manipula links simbólicos da mesma forma que manipula arquivos. De acordo com a página de manual (um pouco antiga, tão útil como ponto de partida):

Note
restorecon does not follow symbolic links.

Isso foi observado em um relatório de bug, Bug 825221: o restorecon desconsidera regras customizadas para links sym , com estes comentários pertinentes:

• Daniel Walsh 2012-05-29 13:54:13 EDT

  We just fixed this in F17.

• Daniel Walsh 2012-08-15 14:01:52 EDT

  restorecon is doing a realpath on the file, so it is translating the file via realpath. We are doing this so that a symbolic link attack will not cause the file to get mislabeled.

• Karel Srot 2012-08-23 06:14:05 EDT

  Just tested this on RHEL6.3 and Fedora 17.

  On RHEL6 restorecon doesn't restore the context of the symlink (when symlink is the actual item). On Fedora 17 the context is restored. I belive this is the problem mentioned in #c6.

  Dan, could you please confirm that this is what's is going to be fixed? Thank you.

• Miroslav Grepl 2012-08-23 09:59:41 EDT

  Ok, we discovered bug in the policy. We do not have the following rule on RHEL6

  allow setfiles_t file_type : lnk_file { read getattr relabelfrom relabelto } ;

  We have just

  allow setfiles_t file_type : lnk_file { getattr relabelfrom relabelto } ;

  So I am switching this bug to selinux-policy component.

Mais tarde (2015), em Algumas perguntas sobre como usar o restorecon no link simbólico , Stephen Smalley comentou

Yes, they resolve to different inodes (a symbolic link is its own file/inode in Linux, separate and independent of the target). The symbolic link SELinux label only controls access to the symlink (i.e. the ability to unlink, rename, or read it), not access to its target (which is controlled based on the target's label).

Então ... exceto alguma regra adicional, os links simbólicos são (principalmente) irrelevantes para as permissões no destino que você está preocupado.