Restrinja um usuário do Linux aos arquivos que ele possui

Imagine uma configuração de servidor de uma empresa de hospedagem compartilhada na qual vários (~ 100) clientes tenham acesso shell a um único servidor.

Muitos "softwares" da web recomendam os arquivos chmod 0777 . Estou nervoso com nossos clientes imprudentemente seguindo esses tutoriais, abrindo seus arquivos para outros clientes. (Certamente não estou usando cmod 0777desnecessariamente!) Existe um método para garantir que os clientes possam acessar apenas seus próprios arquivos e impedir que acessem arquivos legíveis por outros usuários?

Olhei para AppArmor , mas que é muito firmemente acoplado a um processo, que parece falhar nesse ambiente.

Coloque um diretório restrito e imutável entre o mundo externo e os arquivos protegidos, por exemplo

/
 ├─ bin
 ├─ home
 │  └─ joe <===== restricted and immutable
 │     └─ joe <== regular home directory

ou /home/joe/restricted/public_html.

Restrito significa que apenas o usuário e talvez o servidor da Web podem lê-lo (por exemplo, modos 0700/ 0750ou algumas ACLs ).

A imutabilidade pode ser feita com chattr +iou alterando a propriedade para algo assim root:joe.

Uma maneira fácil de criar essa hierarquia no Ubuntu seria editar /etc/adduser.confe definir GROUPHOMEScomo yes.

Há uma opção que você pode querer considerar (dependendo de quanto trabalho você deseja fazer para isso).

Como outros já postaram, "normalmente", você não pode impedir que alguém com acesso ao shell leia arquivos legíveis pelo mundo.

No entanto, você pode inseri-los em sua própria casa, basicamente limitando o acesso do shell a, primeiro, apenas o diretório raiz que você deseja (AKA o diretório inicial) e, segundo, impedir que os usuários executem tudo o que você não deseja que eles executem.

Fiz uma abordagem semelhante quando tive um usuário para ter acesso aos arquivos da web, mas não queria que ele visse outros arquivos fora da pasta da web.

Isso tinha muita sobrecarga, era uma bagunça para configurar e toda vez que eu atualizava alguma coisa, ela quebrava.

Mas hoje, acho que você pode conseguir isso com a opção chroot do OpenSSH :

WikiBooks OpenSSH

Eu descobri que as Listas de Controle de Acesso POSIX permitem que você, como administrador do sistema, proteja seus usuários da pior ignorância possível, substituindo a permissão regular do sistema de arquivos por outro grupo de usuários, sem muita chance de quebrar algo crucial .

Eles podem ser especialmente úteis se você, por exemplo (fi), precisou que os diretórios pessoais fossem acessíveis mundialmente porque o conteúdo da web precisa ser acessível para o apache ~/public_html/. (Embora com as ACLs agora você possa fazer o inverso, remova o acesso para todos e use uma ACL efetiva específica para o usuário apache.)

Sim, um usuário experiente pode removê-lo / substituí-lo novamente, é incomum o suficiente para que isso seja improvável, e os usuários que podem normalmente não são os que convenientemente chmod -R 777 ~/, certo?

Você precisa montar o sistema de arquivos com a aclopção mount:

 mount -o remount,acl /home

Em muitas distribuições, o padrão é criar grupos de usuários, cada usuário tem seu grupo principal e eu configurei todos os usuários em um grupo secundário com o nome sem imaginação de users.

Usando ACLs, agora é trivial impedir que outros usuários acessem os diretórios pessoais:

Antes:

 chmod 0777 /home/user* 

 ls -l /home/user*
 drwxrwxrwx.  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx.  2 user2  user2  4096 Jul 11 15:24 user2

Agora defina as permissões de diretório efetivas para os membros do usersgrupo como 0sem leitura, gravação ou acesso:

 setfacl setfacl -m g:users:0 /home/user*

 ls -l 
 drwxrwxrwx+  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx+  2 user2  user2  4096 Jul 11 15:24 user2

O +sinal indica a presença de configurações da ACL lá. E o getfaclpode confirmar que:

getfacl /home/user1
getfacl: Removing leading '/' from absolute path names
# file: home/user1
# owner: user1
# group: user1
user::rwx
group::rwx
group:users:---
mask::rwx
other::rwx

O group:users:---programa mostra que o grupo efetivamente não tem direito de acesso, apesar das permissões regulares para outrosother::rwx

E testando como usuário1:

[user1@access ~]$ ls -la /home/user2
ls: cannot open directory /home/user2: Permission denied

Uma segunda solução comum em sistemas compartilhados é ter o montador automático montando diretórios pessoais sob demanda e um servidor dedicado ao acesso ao shell. Isso está longe de ser uma prova de idiotice, mas geralmente apenas alguns usuários serão conectados simultaneamente, o que significa que apenas os diretórios pessoais desses usuários são visíveis e acessíveis.

O Linux Containers (LXC) pode ser a melhor combinação de chroot e sistema separado.

1. Eles são mais como um chroot avançado, não como virtualização, mas você pode combinar diferentes sistemas operacionais em um servidor.

2. Você pode fornecer a um usuário um sistema operacional completo e colocá-lo como chroot nele, para que, quando o usuário efetue login, ele vá para o contêiner. E você também pode limitar o uso do processador e da memória lá.

Stéphane Graber, o autor do LXC, tem um bom tutorial para ajudá-lo a começar.

Por exemplo, se você deseja que o usuário tenha acesso apenas ao seu próprio homediretório, faça:

cd /home
sudo chmod 700 *

Agora /home/usernamesó é visível para o proprietário. Para tornar isso o padrão para todos os novos usuários, edite /etc/adduser.confe defina DIR_MODEcomo em 0700vez do 0755padrão.

Obviamente, se você deseja alterar o DIR_MODE padrão, isso depende da sua distribuição, a que eu publiquei funciona Ubuntu.

editar

Como o @Dani_l mencionou corretamente, esta resposta está correta, tornando-os NÃO legíveis pelo mundo.

Só para ser pedante - Não, não existe.
O @Marek deu uma resposta correta , mas sua pergunta está incorreta - você não pode impedir que alguém acesse arquivos "legíveis pelo mundo".
Ou são legíveis pelo mundo ou não são. A resposta de Marek é correta, tornando-os NÃO legíveis pelo mundo.

Não vejo menção do 'shell restrito' nas respostas dadas até agora.

ln / bin / bash / bin / rbash

Defina isso como seu shell de logon.

Se o servidor da web estiver sendo executado como o mesmo usuário e grupo para todos os domínios hospedados, é difícil (se não impossível) tornar a configuração segura.

Você deseja que certos arquivos sejam acessíveis ao usuário e ao servidor da web, mas não a outros usuários. Porém, assim que o servidor da web puder acessá-los, outro usuário poderá lê-los colocando um link simbólico no arquivo em seu próprio site.

Se você conseguir que cada site seja executado como um usuário separado, isso se tornará bastante simples. Agora, cada cliente terá dois usuários no sistema, um para o servidor da Web e outro para acesso ao shell.

Crie um grupo contendo esses dois usuários. Agora crie um diretório com esse grupo e raiz do usuário. Esse diretório deve ter permissões 750, o que significa que o root tem acesso total e o grupo tem acesso de leitura e execução. Dentro desse diretório, você pode criar diretórios pessoais para cada um dos dois usuários. Isso significa que o diretório inicial do usuário não terá mais o formulário /home/username, mas algo com pelo menos mais um componente de diretório. Isso não é um problema, nada requer que os diretórios pessoais sejam nomeados de acordo com essa convenção específica.

Obter sites funcionando com diferentes usuários e grupos pode ser complicado, se você estiver usando vhosts baseados em nome. Se for possível fazer a separação funcionar apenas com vhosts baseados em IP e não houver IPs suficientes para cada site, você poderá hospedar cada site em um endereço IPv6 e colocar um proxy reverso para todos eles em um site. Endereço IPv4.