Quero executar um servidor shell antigo para algumas pessoas, ou seja. aquele onde os usuários obtêm acesso ssh para que possam executar software (próprio ou fornecido).Minha preocupação é a separação adequada entre os usuários.
Não quero que eles vejam os processos uns dos outros, acessem os arquivos uns dos outros (a menos que seja explicitamente permitido), etc. Seria bom não ser mordido por todos os bugs de escalonamento de privilégios ou reiniciar o servidor com cada pequena atualização do kernel. Seria perfeito manter a opção de executar serviços comuns (como hospedagem de web e email) com essas medidas de segurança em vigor.
Antigamente eu usava grsec, mas isso requer permanecer em um kernel mais antigo e lidar com o incômodo de compilá-lo sozinho.Existe uma maneira mais moderna e mais Ubuntu de garantir a separação de usuários em um servidor compartilhado?
Talvez você possa fazer algo com o AppArmor nesse sentido? Ou talvez exista um repositório de kernels pré-configurados para ambientes compartilhados? Ou uma solução baseada em containers? Estes estão em voga ultimamente.
Responder1
hidepid
procfs
no Linux agora suporta a hidepid
opção. Deman 5 proc
:
hidepid=n (since Linux 3.3)
This option controls who can access the information in
/proc/[pid] directories. The argument, n, is one of the
following values:
0 Everybody may access all /proc/[pid] directories. This is
the traditional behavior, and the default if this mount
option is not specified.
1 Users may not access files and subdirectories inside any
/proc/[pid] directories but their own (the /proc/[pid]
directories themselves remain visible). Sensitive files
such as /proc/[pid]/cmdline and /proc/[pid]/status are now
protected against other users. This makes it impossible to
learn whether any user is running a specific program (so
long as the program doesn't otherwise reveal itself by its
behavior).
2 As for mode 1, but in addition the /proc/[pid] directories
belonging to other users become invisible. This means that
/proc/[pid] entries can no longer be used to discover the
PIDs on the system. This doesn't hide the fact that a
process with a specific PID value exists (it can be learned
by other means, for example, by "kill -0 $PID"), but it
hides a process's UID and GID, which could otherwise be
learned by employing stat(2) on a /proc/[pid] directory.
This greatly complicates an attacker's task of gathering
information about running processes (e.g., discovering
whether some daemon is running with elevated privileges,
whether another user is running some sensitive program,
whether other users are running any program at all, and so
on).
gid=gid (since Linux 3.3)
Specifies the ID of a group whose members are authorized to
learn process information otherwise prohibited by hidepid
(ie/e/, users in this group behave as though /proc was mounted
with hidepid=0. This group should be used instead of approaches
such as putting nonroot users into the sudoers(5) file.
Portanto, montar /proc
com hidepid=2
é suficiente para ocultar os detalhes dos processos de outros usuários no Linux > 3.3. O Ubuntu 12.04 vem com 3.2 por padrão, mas você pode instalar kernels mais recentes. Ubuntu 14.04 e superior atendem facilmente a esse requisito.
ACLs
Como primeira etapa, remova rwx
as permissões de outras pessoas de cada diretório inicial (e também do grupo, se necessário). Estou assumindo, é claro, que as pastas que contêm os diretórios iniciais não têm permissões de gravação para ninguém, exceto root.
Em seguida, conceda a serviços como servidor web e servidor de e-mail acesso aos diretórios apropriados usando ACLs. Por exemplo, para conceder ao processo do servidor web acesso às páginas iniciais do usuário, assumindo www-data
que é o usuário e ~/public_html
é onde a página inicial é mantida:
setfacl u:www-data:X ~user
setfacl d:u:www-data:rX ~user/public_html
Da mesma forma, adicione ACLs para os processos de correio e os diretórios de caixa de correio.
As ACLs são habilitadas por padrão no ext4, pelo menos no Ubuntu 14.04 e superior.
/tmp
eumask
Outro problema é /tmp
. Defina umask
para que os arquivos não sejam legíveis por grupos ou por todos, para que os arquivos temporários dos usuários não sejam acessíveis a outros usuários.
Com essas três configurações, os usuários não poderão acessar os arquivos de outros usuários ou examinar seus processos.