Os links executáveis / graváveis / executáveis no mundo em brechas de segurança / usr / bin?

Question

% ls -l /usr/bin/edit                                                                                                
lrwxrwxrwx 1 root root 3 Jan 10 05:54 /usr/bin/edit -> vim*

Isso parece se aplicar a muitos binários em update-alternatives , pelo menos em Suse e talvez em outras distribuições do Linux. Isso não significa que qualquer conta comprometida no Suse poderia modificar o symlink, enganando o usuário para executar alguma coisa? Em caso afirmativo, por que essas são as permissões padrão?

    

Answer 1

Em a entrada da Wikipedia para Symbolic link :

The file system permissions of a symbolic link usually have relevance only to rename or removal operations of the link itself, not to the access modes of the target file which are controlled by the target file's own permissions.

Como esse link simbólico é de propriedade do root, somente ele pode alterá-lo. Por exemplo,

# ln -s /bin/ls blah
# ls -la blah
lrwxrwxrwx 1 root root 7 Fev 28 15:07 blah -> /bin/ls
$ rm blah
rm: cannot remove 'blah': Operation not permitted
$ ln -s blah /bin/true
ln: failed to create symbolic link '/bin/true': File exists

    

Answer 2

Em uma palavra, não.

O kernel apenas usa o symlink para encontrar o arquivo / diretório para o qual o link aponta.

Veja o exemplo view = > vim (um link simbólico comum em / usr / bin, chame vim pelo nome view e ele abrirá o arquivo de texto somente para leitura).

O kernel irá 'abrir' view , veja se é um ponteiro para o vim, feche view e abra vim . Quando é aberto / vim do executivo, ele usa todas as verificações de segurança em vim . Então o vim ainda é aberto com as permissões no vim, que é o que você espera.

Ah ha! Mas um symlink iss um arquivo, e se for gravável, eu posso abri-lo, editá-lo e mudar o alvo! / usr / bin / view torna-se um apontador para / tmp / myevilexec. Em uma palavra, não. É um arquivo especial, você não pode abrir o arquivo 'symlink' e editá-lo desta maneira. Você só pode substituir o symlink, e então os perms no symlink são irrelevantes - o diretório perms determina se você pode deletar arquivos / criar novos arquivos.

Em suma, o 777 para links simbólicos não é uma falha de segurança, e faz com que perms do symlink 'invisible' e perms sejam o arquivo de destino, que é o que você espera.

    

Answer 3

respondendo a sua própria pergunta depois de descobrir:

Eu percebi isso. Isso seria uma falha de segurança, exceto pelo fato de que /usr/bin é de propriedade de root e não é gravável por todos e, portanto, não é possível modificar o link. Se /usr/bin fosse mundialmente gravável, você poderia substituir o link pelo seu próprio link, mas esse não é o caso.

Como prova de conceito:

% cd
% sudo touch rootfile
% sudo ln -s rootfile rootfile_link
% touch evilfile
% ln -s evilfile evilfile_link

# works, but only if directory permissions are correct:
% cp evilfile_link rootfile_link

No entanto, se houvesse uma maneira de editar o arquivo de link simbólico real (é apenas um pequeno trecho de texto eu acho), seria possível ser mal.

Assim, vou deixar de aceitar qualquer resposta até que alguém possa apresentar strongs evidências de que um link simbólico pode / não pode ser modificado, ou substituído-com-permissões-intacto, e aceitar essa resposta. / strong>