Adicionando o diretório atual ao caminho

Question

Aqui está uma pergunta que não consigo encontrar uma resposta boa .

No Windows / DOS, fomos "ensinados" que não há problema em usar para iniciar programas a partir do diretório atual sem precisar prefixar o caminho.

No entanto, o comportamento padrão para o Linux é que você deve prefixar ./ para aplicativos / scripts no diretório atual.

As pessoas dizem que é uma prática de segurança ruim permitir que programas / scripts sejam executados sem prefixar o diretório. Há um monte de "más práticas de segurança", mas esta não faz sentido para mim. Por exemplo, não vou entrar no diretório / some / unfamiliar / e começar a executar programas como o ls. Gostaria cd (para chegar ao meu diretório home), em seguida, digite ls -la / alguns / desconhecido / diretório. Claro, em um dia ruim eu faria.

Eu posso ver a "ameaça" se alguém colocar um programa com o nome de ls em um diretório e um sysadmin ruim para esse diretório e executar o ls como root e o ls adicionar um usuário de backdoor e outras coisas ruins. Bem. Mas, geralmente, nesse caso, um usuário iria reclamar "oh ls não está funcionando, você pode verificar isso?". Eu sudo su "usuário" e tente ls como ele.

A menos que eu esteja completamente perdendo algo, está adicionando "." para o seu PATH realmente tão ruim assim?

Editar:

Todas as respostas até agora são boas para apontar os riscos de segurança - no entanto - todos estão perdendo os argumentos para o Windows. No Windows, o diretório atual NÃO está em seu caminho, portanto, não há como desabilitar a capacidade de executar apenas o programa .exe afaik. No entanto, o prompt de comando aceita a habilidade de prefixar o comando com. \ (. \ Parece funcionar, no entanto, você deve usar \ caso contrário, você pode acabar com uma seqüência de escape de algum tipo). No Windows deveríamos sempre prefixar o comando? Além disso, devemos entrar em contato com a Microsoft e dizer que eles são ruins para implantar esse comportamento esperado?

Meu histórico é Windows, então estou inclinado a esperar que programas no diretório atual possam ser executados, embora eu saiba que não é assim que funciona no mundo Unix. Por isso, apresentei a questão por aí.

Expandir o que quero dizer com "más práticas de segurança" (e por que elas estão entre aspas) é porque poderíamos citar milhões, se não bilhões, de práticas de segurança que as pessoas DEVEM estar fazendo ... mas nós não fazemos e se o fizéssemos, uma pessoa certamente enlouqueceria. Devemos atenuar todos os riscos de segurança com o potencial de interferir na experiência do usuário? Eu digo não, mas isso é porque eu acredito que a segurança deve ser transparente para o (s) usuário (s), mas eu gosto da primeira sentença de haus em sua resposta "Tanto quanto qualquer outra coisa, é uma mentalidade". E acho que devemos deixar isso assim.

    

Answer 1

Tanto quanto qualquer outra coisa, é uma mentalidade.

Por ter seu diretório atual como parte de seu caminho, você está realmente aumentando seu risco. Só porque um programa de trojan foi executado, não significa que ele não fará o que se espera dele. Em outras palavras, para usar o seu exemplo ls, o programa trojan, a menos que fosse projetado por um burro, forneceria a lista de diretórios que você solicitou, de modo que, a menos que você diga o arquivo ali, você não teria razão para esperar algo deu errado (talvez seja inteligente e decida se remover da lista de diretórios fornecida para diminuir ainda mais a chance de detecção).

Para que isso ocorra, isso significaria que alguém já se infiltrou em um determinado sistema ao ponto de poder colocar arquivos em seu sistema de arquivos. Assim, você já está mal, mas ainda há espaço para que as coisas piorem.

Como prática geral, eu não coloco meu diretório atual no meu caminho em meus sistemas linux / unix, e isso não é uma grande dificuldade. Quando escrevo um programa ou script que desejo usar com frequência, coloco-o em uma pasta que está no meu caminho e restringo as permissões de gravação ao arquivo.

Curto respondedor, adicionando o diretório atual para o seu caminho levar a determinada desgraça para um usuário não privilegiado, provavelmente não, mas por que arriscar?

Para root, NÃO FAÇA ISTO.

    

Answer 2

Para root, é mortal. Para outros usuários, o motivo que eu recomendaria não adicionar "." para o caminho (bem como para a segurança) é que isso o levará a problemas estranhos e confusos, por ex. os processos que pesquisam o caminho podem começar a demorar muito tempo ou encontrar um programa diferente com o mesmo nome. / usr / ucb no solaris por exemplo contém a versão BSD do comando ps. Crie um novo sistema de arquivos e preencha-o com um grande número de arquivos com "." no seu caminho tente fazer uma conclusão do bash para "grep". Levará mais tempo porque. tem que ser pesquisado e há um milhão de arquivos lá. "" também poderia estar em algumas mídias dolorosamente lentas como uma montagem NFS muito distante ou algo do tipo. Você pode se dar bem com isso e nunca vê-lo causar um problema, mas quando ele causa um problema, pode não ser óbvio imediatamente qual é a causa raiz. Eu vi muitos problemas de desempenho no passado distante ser causado PATHs muito longos, o PATH não é o mesmo em diferentes ambientes e assim por diante. Meu 2D: em sua própria caixa com seu próprio usuário, faça isso se isso facilitar a vida. Na produção, mantenha o ponto fora do caminho.

    

Answer 3

Como mencionado, o risco de segurança mais óbvio é apenas ter algum código malicioso no diretório atual que suplanta um executável existente. Se isso é explorável ou não depende realmente de quão rigoroso você é em sua política "Não executar comandos de um diretório não vinculado".

No entanto, um problema mais sutil e potencialmente mais sério que pode ocorrer é que a resolução de comandos não é mais previsível. Por exemplo, se você está acostumado a usar runcommand apenas digitando runc<tab> no BASH, isso funcionará na maioria dos diretórios, mas falhará se você estiver em um diretório com um executável runcom . Novamente, isso pode ser contornado com apenas estar ciente do que você está fazendo, mas na minha experiência depois de digitar runc<tab> cinquenta vezes sem problema, a quinquagésima primeira vez pode facilmente passar despercebida.

A parte chata disso é que não envolve intenção maliciosa. Não há vírus infectando seu sistema, não há trojans plantados clandestinamente em seu diretório pessoal. Este é apenas dois comandos diferentes, em dois diretórios diferentes, que fazem duas coisas diferentes. O runcom pode legitimamente excluir apenas metade dos arquivos do seu diretório pessoal, mas isso não significa que você queira executá-lo acidentalmente.

Isso pode ser ainda mais perigoso se você estiver lidando com scripts. Se você executar um script de shell típico a partir da linha de comando, ele adotará sua variável $ PATH. Semelhante ao exemplo acima, isso significa que o comportamento do script pode ser diferente se você o executar a partir de diretórios diferentes. Você pode acabar executando uma versão diferente de qualquer comando se estiver em, digamos, /usr/bin em vez de usar a versão /usr/local/bin . Ou, alternativamente, você pode acabar tendo comandos disponíveis que normalmente sinalizariam um erro legítimo quando estiver faltando - uma das poucas coisas piores do que um script importante falhando inesperadamente é o script falhando inesperadamente e pensando conseguido. Scripts bem escritos contornam isso configurando seus próprios $ PATH, ou explicitamente chamando comandos precedidos pelo nome completo do caminho.

Nem todos os scripts são bem escritos.

Muitos desses problemas podem ser resolvidos apenas definindo o diretório atual como o último ponto de resolução no caminho em vez do primeiro ( PATH=$PATH:. em vez de PATH=.:$PATH ), mas essa ainda não é uma solução perfeita . Vendo como explicitamente prefixar um comando com ./ para executar a versão do diretório local é apenas um extra de duas teclas de qualquer maneira, eu vou ficar com isso.

    

Answer 4

Ataques inteligentes, embora provavelmente raros, podem combinar várias técnicas a partir de um ambiente não privilegiado usando um executável falso em um "." PATH do diretório atual para inserir um alias no ambiente usando uma técnica semelhante à minha pergunta / resposta aqui que o seguiria em um ambiente privilegiado.

1. O caminho do usuário não privilegiado contém "." - o diretório atual
2. Um executável malicioso com um nome comum é criado em um diretório gravável pelo usuário
3. Agora alguém entra nesse diretório com cd e executa o malware pensando que está executando seu próprio programa útil
4. O executável malicioso cria um alias oculto para su escrevendo para o usuário ~/.bashrc
5. Também cria um arquivo rc malicioso com um nome que não é digno de nota (vamos chamá-lo de "badrc")
6. Alguém faz login, executando assim a definição de alias que faz algo como alias su='sudo bash --rcfile /path/to/badrc'
7. O usuário usa su - e obtém um prompt de shell e começa a usar comandos com alias em "badrc" usando técnicas ocultas de alias
8. Lucro (para o invasor)

Esta é certamente uma sequência complicada e outras variações são possíveis, mas por que deixar-se em aberto? Omitir "ponto" do seu caminho (além de um controle rígido sobre os usuários e manter bons hábitos) aumenta o nível para os invasores.

    

Answer 5

Junto com o pwd está em um sistema de arquivos remoto lento vem este problema: se. não existe mais por algum motivo, você não pode mais executar comandos diferentes de shell builtins, o que é muito confuso. O pwd pode ter sido excluído, o sistema de arquivos que o contém pode ter sido desmontado à força ou em um servidor que foi desligado.