Questão seguindo o link simbólico de outro usuário


Como alguém atravessa um symlink de outro usuário?

Na minha caixa do Ubuntu, eu tenho um link simbólico:

root@anonymous:/var/tmp# ls -l
total 24
lrwxrwxrwx 1 lab  lab    26 Dec 15 18:27 blank.zip -> /home/admin/important6.zip

Acessando-o como root dá:

root@anonymous:/var/tmp# more blank.zip 
blank.zip: Permission denied

Se eu alterar a propriedade para root, no entanto:

root@anonymous:/var/tmp# chown -h root:root blank.zip ; more blank.zip 
PK...

0


origem


Devo salientar que o / var / tmp não possui bits fixos definidos. - Ari Trachtenberg
Mais dados: isso parece ser um problema apenas em / var / tmp e / tmp, mas não em outro diretório (digamos ~ root). Isso sugere que isso é algum tipo de verificação de controle de acesso no nível do kernel ... mas eu não pareço ter o selinux ou o apparmor em execução. - Ari Trachtenberg


Respostas:


chown -h muda a propriedade de /home/admin/important6.zip não de blank.zip. Você já tem acesso total ao blank.zip link simbólico como root.

Se você olhar as permissões do important6.zip, sem dúvida verá por que ele não funciona.


2



Eu acho que o oposto ... chown -h faz não desreferencia o link. Eu estou fazendo isso como root ... Eu tenho acesso a ler important6.zip. - Ari Trachtenberg
Eu acho que você está certo, e eu interpretei mal a página do homem :) - Paul


Isso acontece por causa do fs.protected_symlinks característica. Desde a /var/tmp é um diretório público (gravável pelo mundo e com o bit 'pegajoso'), existe o risco de alguém criar um link simbólico para, por exemplo, /etc/passwd e enganar um serviço do sistema para gravar dados personalizados para ele. Para evitar isso, os links simbólicos localizados em um diretório 'fixo' são seguidos apenas quando o proprietário deles corresponde.

Veja os seguintes artigos para mais informações:


1



"Alguém poderia criar um link simbólico para, por exemplo, /etc/passwd e enganar um serviço do sistema para escrever dados personalizados para ele ". Eu acho que é chamado problema deputado confuso. - Kamil Maciorowski
O problema é que, como eu mencionei no meu comentário sobre o problema original, / var / tmp / faz não ter o bit pegajoso definido. - Ari Trachtenberg
Tem certeza que? Ele tem isso em quase todos os sistemas Linux. (E se isso não acontecer, devemos...) - grawity
Sim ... eu solto isso. - Ari Trachtenberg


Eu acho que o problema não é sobre a propriedade do symlink, mas a propriedade do /home/admin diretório. Como o laboratório do usuário não tem permissão para visualizar o diretório inicial de outro usuário (a menos que seja de outra forma modificado), o link simbólico não pode ser seguido.

Como o root pode visualizar o diretório inicial da anoyone, a alteração da propriedade para o root resolve o problema no seu caso.

Você pode adicionar lab ao grupo de admin e chmod /home/admin para 770 (ou 740 por permitir apenas ler para os membros do grupo). Geralmente, os diretórios iniciais são modificados 700. Não é recomendado aumentar a permissão para todos os outros (últimos 3 bits) para fins de segurança.


0



Por que a propriedade do admin é importante? Estou fazendo tudo isso como root. - Ari Trachtenberg
Bem, eu estou preso :) Eu mudei a propriedade do link simbólico para um usuário não-sudoer e até mesmo chmod'ed o arquivo vinculado para 0, mas o root ainda acessa. - Serhat Cevikel
Pode ser por causa de um problema relacionado ao SELinux ou ao fusível. - Serhat Cevikel
Você pode verificar: serverfault.com/questions/12162/…  ask.fedoraproject.org/en/question/41452/… - Serhat Cevikel