Por que o chmod 777 é tão ruim se eu sou o único usuário no sistema?

Você pode ser o único usuário humano no sistema. Mas se você der uma olhada, /etc/passwdverá que há muitos outros usuários:

root:x:0:0:root:/root:/bin/ash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/mail:/sbin/nologin
news:x:9:13:news:/usr/lib/news:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
man:x:13:15:man:/usr/man:/sbin/nologin
postmaster:x:14:12:postmaster:/var/mail:/sbin/nologin
cron:x:16:16:cron:/var/spool/cron:/sbin/nologin
ftp:x:21:21::/var/lib/ftp:/sbin/nologin
sshd:x:22:22:sshd:/dev/null:/sbin/nologin
at:x:25:25:at:/var/spool/cron/atjobs:/sbin/nologin
squid:x:31:31:Squid:/var/cache/squid:/sbin/nologin
xfs:x:33:33:X Font Server:/etc/X11/fs:/sbin/nologin
games:x:35:35:games:/usr/games:/sbin/nologin
cyrus:x:85:12::/usr/cyrus:/sbin/nologin
vpopmail:x:89:89::/var/vpopmail:/sbin/nologin
ntp:x:123:123:NTP:/var/empty:/sbin/nologin
smmsp:x:209:209:smmsp:/var/spool/mqueue:/sbin/nologin
guest:x:405:100:guest:/dev/null:/sbin/nologin
nobody:x:65534:65534:nobody:/:/sbin/nologin
nginx:x:100:101:nginx:/var/lib/nginx:/sbin/nologin
vnstat:x:101:102:vnstat:/var/lib/vnstat:/bin/false
redis:x:102:103:redis:/var/lib/redis:/bin/false

Essas são contas do sistema , ou seja, contas que executam os diferentes serviços e daemons no sistema: servidores web, serviços de e-mail (entrada e saída), servidores FTP, tarefas cron, etc.

Geralmente esses serviços rodam em seu próprio diretório e fazem suas coisas como bons meninos. Mas, no caso de um bug ou, mais provavelmente, se alguém hackear sua máquina por meio de um desses serviços (por exemplo, servidor web), você não quer que essas contas de usuário tenham acesso irrestrito de leitura e gravação em todo o seu sistema.

Em suma, você não tem nada a ganhar e tudo a perder ao dar a esses usuários mais acesso do que eles precisam. Isso é chamado de princípio do menor privilégio .

(Nota: o arquivo de senha foi retirado daqui . )

Você perguntou,

Ouvi dizer que chmod 777 é uma ideia horrível. […] Por que não devo permitir tudo?

e então mencionado em um comentário,

Estou tendo problemas de permissão para fazer o Steam baixar jogos em outro sistema de arquivos

Se for um sistema de arquivos nativo do Linux, você pode alterar o ponto de montagem para seu proprietário ou, se necessário, defini-lo para ser gravável para todos os usuários. Esta segunda opção não é ideal por causa do princípio do menor privilégio : você não dá acesso a menos que seja necessário/apropriado. Você não pode prever o que pode acontecer, então não permite o que não espera.

Exemplo

# Take ownership
sudo chown "$USER" /path/to/mountpoint

Se você já baixou itens como root, mas realmente deveria tê-los baixado como você mesmo, use o sinalizador recursivo para assumir a propriedade de tudo sob o ponto de montagem do sistema de arquivos

sudo chown -R "$USER" /path/to/mountpoint

Observe que se você tentar esses comandos em /qualquer um dos diretórios do sistema, seu sistema será danificado.

Uma razão técnica significativa é que alguns programas relevantes para a segurança se recusam a trabalhar com arquivos que são muito permissivos. Por exemplo, sshdnão usarão um .ssh/authorized_keysarquivo a menos que ele tenha permissões muito restritivas.

Em segundo lugar, você pode tornar seu sistema não inicializável removendo ou descartando acidentalmente arquivos em /etcou de outra forma. Forçar-se a usar sudoou o que quer que você precise fazer para modificar esses arquivos é um passo para se salvar de seus próprios erros.

Uma razão adicional, mais psicológica: trabalhar com permissões é algo que você fará constantemente, em sistemas Unix*ish. Se você se acostumar a aplicar apenas 777 em todos os lugares, nunca será desafiado com os pequenos detalhes que são relevantes em sistemas "reais" (ou seja, aqueles que não são usados ​​apenas por uma única pessoa, com uma quantidade muito restritiva de aplicativos e nenhum dado relevante para a segurança). Isso significa que você está negando a si mesmo a chance de se acostumar com isso e desenvolver uma intuição de como essas coisas funcionam.

Afinal, uma vez que você esteja "respirando" o sistema de permissão, ele será muito, muito simples mesmo. Os padrões, ou seja, o umask padrão e coisas assim, são "sensatos" em sistemas modernos, então na maioria dos casos você pode simplesmente trabalhar com eles; especialmente se você estiver sozinho no sistema.

Se você trabalha em um sistema mais sensível, especialmente em um contexto empresarial, ficará muito feliz em saber que as permissões são naturais.

Aplicar chmod 777 aos arquivos e diretórios do sistema IRÁ quebrar seu sistema

Essa questão me intrigou tanto que eu fiz isso chmod -R 777 /*no meu sistema rhel-9.4 em casa. Como esperado, a /runpasta respondeu com sistema de arquivos somente leitura e a /procpasta não pegou. Depois de fazer isso, consegui yum updatereinicializar e fazer login no rhel-9.5 com sucesso. No entanto, a inicialização detalhada mostrou falha no serviço de auditoria de segurança e serviço ssh, e o ssh especificamente reconheceu suas permissões de arquivo de chave muito abertas, por isso não inicia. E então o firefox abre, mas ao tentar acessar qualquer site diz "não é possível acessar", como se a internet não funcionasse.

então dizer quebrar seu sistema está meio fora de contexto. Quero dizer, se não houvesse internet ou acesso à rede, ele seria completamente autônomo e isolado, então as coisas/serviços que lidam com permissões relacionadas a coisas, mas em geral, se você não estiver precisando delas, então é meio difícil definir as ramificações de um chmod 777 global. Você está basicamente dizendo para deixar tudo rodar, e com algumas exceções racionais como eu mencionei, eu acho que as coisas vão.

Agora você não declarou explicitamente quais pastas fazendo um chmod 777on aconteceriam. Então, assumindo fazer algo como chmod 777 /steamonde é apenas uma pasta, lamento desanimar muitas pessoas, mas eu lidei com isso nos últimos 20 anos no trabalho, voltando aos dias do SGI IRIX, e NÃO a chmod 777não é fundamentalmente ruim. É em grande parte uma questão de contexto , e se outra segurança lógica racional estiver em vigor, como apenas um usuário e localização física sendo o mecanismo de segurança primário para uma configuração de login automático de usuário único, um 777 pode ser feito e não causar problemas. Seria como dizer que uma caixa de bloqueio interna é ruim quando já está dentro de uma caixa de bloqueio. Tenho certeza de que você pode fazer chmod 777 em muitos arquivos do sistema e ter um sistema funcional, mas apenas uma pessoa preguiçosa e não tão inteligente balançaria esse martelo em todo o sistema para consertar um problema que não é de todo o sistema.

no seu contexto com jogos steam, o que significa internet, o que significa software de terceiros e bugs e segurança, e jogar contra outros usuários, um chmod 777 geral em todas as coisas steam seria ok no Linux, eu não sei. Eu não apostaria $1 que seria.

Por que eu não deveria permitir tudo?

Porque mesmo a segurança rudimentar de um sistema não deve falhar completamente se uma única de suas suposições for falsa.

O motivo é que ele fornece mais segurança para você lidar com permissões pelo menos um pouco restritivas, para que o próximo bug no serviço XYZ não vaze sua coleção de pornografia caseira e seus dados bancários para o mundo.