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

24

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.

Um monte de "software" da web recomenda para arquivos chmod 0777 . Estou nervosa com os nossos clientes seguindo esses tutoriais imprudentemente, abrindo seus arquivos para nossos outros clientes. (Eu certamente não estou usando cmod 0777 desnecessariamente eu mesmo!) Existe um método para garantir que os clientes possam acessar apenas seus próprios arquivos e impedi-los de acessar arquivos legíveis de outros usuários?

Eu olhei para o AppArmor , mas isso está intimamente ligado a um processo, que parece falhar nesse ambiente.

    
por Phillipp 11.07.2014 / 11:33

8 respostas

34

Coloque um diretório restricted 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 / 0750 ou alguns ACLs ).

A imutabilidade pode ser feita com chattr +i ou mudando a propriedade para algo como root:joe .

Uma maneira fácil de criar essa hierarquia no Ubuntu seria editar /etc/adduser.conf e defina GROUPHOMES para yes .

    
por 11.07.2014 / 11:56
15

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

Como os 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ê poderia chroot-los em sua própria casa, basicamente limitando o acesso ao shell, primeiro, apenas o diretório raiz que você quer (AKA o diretório inicial) e, segundo, impedir que os usuários executem tudo que você não deseja que eles executar.

Eu fiz uma abordagem semelhante quando tinha um usuário para acessar os arquivos da Web, mas não queria que ele visse outros arquivos fora da web.

Isso teve muita sobrecarga, foi uma bagunça na configuração e toda vez que eu atualizava algo, ele quebrava.

Mas, hoje, acho que você pode conseguir muito fácil com a opção OpenSSH chroot:

OpenSSH do WikiBooks

    
por 11.07.2014 / 12:12
11

Descobri que as Listas de Controle de Acesso POSIX permitem que você, como administrador do sistema, proteja seus usuários do pior de sua própria ignorância, sobrepondo-se à permissão do sistema de arquivos regular de grupo de usuários, sem muita chance de quebra qualquer coisa crucial.

Eles podem ser especialmente úteis se, por exemplo, (f.i.) precisar de diretórios de usuário para serem acessíveis, porque o webcontent precisa estar acessível para o apache em ~/public_html/ . (Embora com o ACL, agora você pode fazer o inverso, remover o acesso de todos e usar uma ACL efetiva específica para o usuário do apache).

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

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

 mount -o remount,acl /home

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

Usando o ACL, agora é trivial impedir que outros usuários acessem os diretórios base:

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 do diretório efetivo para membros do grupo users como 0 sem 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 de ACL nesse local. E o getfacl pode confirmar isso:

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

Os group:users:--- mostram que o grupo não tem acesso direito, apesar das permissões regulares para os outros serem other::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 automounter montado em diretórios home sob demanda e um servidor dedicado ao acesso ao shell. Isso está longe de ser a prova de erros, mas normalmente apenas um punhado de usuários será logado ao mesmo tempo, significando que apenas os diretórios iniciais desses usuários estão visíveis e acessíveis.

    
por 11.07.2014 / 13:49
3

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

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

  2. Você pode fornecer ao usuário um sistema operacional completo e fazer chroot nele, portanto, quando o usuário fizer login, ele acessará seu contêiner. E você também pode limitar o uso do processador e da memória.

Stéphane Graber, o autor do LXC, tem um bom tutorial sobre para ajudar você a começar.

    
por 11.07.2014 / 13:57
3

Por exemplo, se você quer que o usuário tenha acesso somente ao seu próprio diretório home , você deve fazer:

cd /home
sudo chmod 700 *

Agora, /home/username é visível apenas para seu proprietário. Para tornar esse o padrão para todos os novos usuários, edite o /etc/adduser.conf e defina DIR_MODE para 0700 em vez do 0755 padrão.

É claro que se você quiser alterar o DIR_MODE padrão depende da sua distribuição, o que eu postei funciona em Ubuntu .

editar

Como @Dani_l mencionado corretamente, esta resposta está correta em torná-los NÃO legíveis para o mundo.

    
por 11.07.2014 / 11:41
2

Apenas para ser pedante - Não, não há. @Marek deu uma resposta correta, mas a sua pergunta está incorreta - você não pode impedir que alguém acesse arquivos "legíveis para o mundo"

Ou eles são legíveis pelo mundo ou não são. @ Resposta de Marek está correta em torná-los não é legível pelo mundo.

    
por 11.07.2014 / 11:54
0

Não vejo menção ao 'escudo restrito' nas respostas dadas até agora.

ln / bin / bash / bin / rbash

Defina isso como o shell de login.

    
por 13.07.2014 / 05:35
0

Se o servidor da Web estiver sendo executado como o mesmo usuário e grupo para cada domínio hospedado, será difícil (se não impossível) tornar a configuração segura.

Você deseja que determinados arquivos sejam acessíveis ao usuário, bem como ao servidor da Web, mas não a outros usuários. Mas assim que o servidor web puder acessá-los, outro usuário poderá lê-los colocando um link simbólico no arquivo dentro de seu próprio site.

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

Crie um grupo contendo esses dois usuários. Agora crie um diretório com esse grupo e o usuário root. Esse diretório deve ter permissões 750 , o que significa que a raiz 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 formato /home/username , mas sim algo com pelo menos mais um componente de diretório. Isto não é um problema, nada requer que os diretórios home sejam nomeados de acordo com essa convenção específica.

Obter sites da Web em execução com diferentes usuários e grupos pode ser complicado, se você estiver usando vhosts baseados em nome. Se você só puder fazer a separação funcionar com vhosts baseados em IP e não tiver IPs suficientes para cada site, poderá hospedar cada site em um endereço IPv6 e colocar um proxy reverso para todos eles em um endereço IPv6. Endereço IPv4.

    
por 09.08.2014 / 14:30