☰

hidepid

tag-icon • tag-icon server kernel ssh security multi-user
hidepid

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

procfsno Linux agora suporta a hidepidopçã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 /proccom 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 rwxas 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-dataque é 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.

/tmpeumask

Outro problema é /tmp. Defina umaskpara 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.

informação relacionada