Evitar que outros usuários visualizem meus arquivos [closed]

Question

Ref: O root / superusuário pode ler meus arquivos protegidos contra leitura? arquivos?

Meu nome de conta de usuário do Ubuntu "user-3121" com tipo como "Administrador". Há mais uma conta chamada "admin" com o tipo "Administrador". Como posso ter certeza se o "admin" pode logar ou não visualizar meus arquivos em "user-3121"?

Eu discuti isso com o outro usuário e tentamos modificar /etc/sudoers para proteger meus arquivos:

Cmnd_Alias   SHELLS = /bin/sh,/bin/bash,/bin/ksh, /usr/bin/x11/passwd

Cmnd_Alias   SU = /usr/bin/su,/bin/su,/usr/bin/gksudo,/usr/bin/sudo,/usr/bin/su bash,/usr/bin/sudo /bin/bash,/usr/sbin/visudo

Cmnd_Alias   PASS = /usr/bin/passwd root,/bin/* * root,/bin/* * sysadmin,/bin/* * /home/sysadmin,/usr/bin/passwd

Cmnd_Alias      EDIT= /bin/* /etc/sudoers,/bin/* sudoers,/bin/* /etc/passwd,/bin/* passwd,/bin/* /etc/group,/bin/* group,/bin/* /etc/shadow,/bin/* shadow,/*/*/[a-z]* /etc/sudoers,/*/*/[a-z]* /etc/passwd,/*/*/[a-z]* /etc/group,/*/*/[a-z]* /etc/shadow,/*/*/[a-z]* sudoers,/*/*/[a-z]* passwd,/*/*/[a-z]* group,/*/*/[a-z]* shadow

Cmnd_Alias   CMDS = /usr/sbin/userdel * sysadmin,/usr/sbin/userdel sysadmin,/usr/sbin/deluser * sysadmin,/usr/sbin/deluser sysadmin

root    ALL=(ALL) ALL, !CMDS

%admin ALL=(ALL) ALL, !SHELLS, !SU, !CMDS, !PASS, !EDIT
%sudo  ALL=(ALL) ALL,!SHELLS, !SU, !CMDS, !PASS, !EDIT

admin ALL=(ALL) ALL
administrator ALL=(ALL) ALL

Se "admin" ainda puder ler meus dados, como evitá-los? Além disso, como funciona essa configuração, ele permite que o "user-3121" execute alguns comandos sudo, mas não menciona "user-3121" em lugar algum?

P.S. Eu sou a única pessoa que sabe a senha do usuário "root", para que eu possa fazer login como root usando o comando "su".

    

Answer 1

Ok, agora eu entendo o que isso está dizendo

Cmnd_Alias   CMDS = /usr/sbin/userdel * sysadmin, ...
%admin ALL=(ALL) ALL, !SHELLS, !SU, !CMDS, !PASS, !EDIT

infelizmente é uma ideia terrível.

Na segurança, um princípio geral é que você deve ser capaz de descrever o que está permitindo . É surpreendentemente raro poder fazer uma lista do que não é permitido, e ter certeza de que você não perdeu nada.

Especificamente

$ cp /usr/sbin/userdel ./letsbefriends
$ sudo ./letsbefriends sysadmin

(e o mesmo princípio se aplica a uma configuração que bloqueia especificamente sudo su / sudo sudo ).

Como um exemplo positivo, considere esta listagem de tarefas permitidas para o seu usuário "admin" [*]:

# admin can run 'reboot'.  (They can't run e.g. 'reboot --force').
admin ALL=(ALL) reboot ""

Why [is] "user-3121" missing in /etc/sudoers?

Excelente pergunta! user-3121 é um membro do sudo group . Em /etc/sudoers , esse grupo é correspondido pela linha %sudo .

Você pode pensar "Esse é um hack fofo que você me mostrou. Certamente eu poderia pensar em uma maneira de bloquear isso também". E existem abordagens que você pode seguir. Mas você estaria argumentando por causa disso, e tentando não aceitar o princípio geral.

Alguém mais aparece, com uma ideia diferente. O que isso faz? [**]

$ sudo /proc/self/exe sh

São dois exemplos diferentes que você teria que configurar seu sistema para bloquear. Você pode confiar em eu saber mais. Você acaba escrevendo esta configuração personalizada complexa. Os sistemas complexos incluem inevitavelmente bugs. Você deseja criar um sistema personalizado, solucionar problemas e mantê-lo? Normalmente você quer tentar e trabalhar com o sistema operacional que você instalou, para que você possa se beneficiar de todo o trabalho que está sendo desenvolvido, documentando e dando suporte a ele.

[*] Na prática, limitar o sudo a certos propósitos tende a ser mais difícil do que se pode gostar. Eu espero que não seja comum confiar nas regras do sudo para fornecer uma barreira de segurança verdadeira. Em vez disso, é usado para delegar permissão para tarefas específicas, enquanto protege os usuários de si mesmos. Ele reduz as chances de cometer um erro e de escrever zeros em todo o disco rígido valioso ou no firmware da placa de rede.

[**] Spoiler:

sudo /proc/self/exe sh executaria um shell como usuário root.

Ele ignora a lista de bloqueio definida como SU , usando a mesma técnica de execução de um comando (sudo) usando um nome de arquivo alternativo que não esteja na lista de bloqueio. Portanto, essa segunda instância de sudo é executada com êxito como o usuário root . A configuração publicada permite que o usuário root execute qualquer comando através de sudo . A segunda sudo instance é, portanto, permitida para executar um shell como usuário root.

O shell resultante pode ser usado para executar qualquer comando como root . O shell não usa o sudo, portanto, ele não vê nenhuma lista de comandos bloqueados em sudoers . Por exemplo. o shell pode executar su para efetuar login em um shell executando como qualquer usuário, sem saber sua senha.

    

Answer 2

Fácil, se for uma conta do tipo "administrador", você deve assumir que pode fazer qualquer coisa. (Exemplo fornecido abaixo)

(Também se um usuário tiver acesso ao menu do gerenciador de inicialização ou à interface de configuração do firmware, como a tela de configuração do BIOS).

Se você puder executar comandos de sua escolha em ID de usuário 0 (por exemplo, sudo), você têm essencialmente o mesmo nível de acesso que o processo que instalou o seu sistema operacional em primeiro lugar. Ou como um dos discos de resgate dos quais você pode fazer o boot - eles podem fazer o backup todos os seus arquivos, ou migrá-los de uma unidade para outra para fins de atualização, etc.

Sem algum software TPM (que não esteja implementado no Ubuntu ou similar), eles podem instalar um keylogger para capturar sua senha ou desabilitar quaisquer verificações de autenticação que você implemente.

A criptografia

Por usuário pode impedir o acesso casual. A documentação da comunidade do Ubuntu atualizada há dois anos afirma que você pode ativar isso: link

Exemplo de acesso ao arquivo

Aparentemente, alguns usuários pensam, por exemplo chmod 0700 protege seus diretórios. Isso está incorreto. Você pode inventar situações em que funciona, mas não é suficiente por si só. Exemplo rodando no Fedora Workstation 24, ext4 filesysem:

$ mkdir secret    # directory with "secret" contents
$ chmod 0700 secret    # apply access control
$ ls -ld secret    # show access control
drwx------. 2 alan-sysop alan-sysop 4096 Nov 13 20:31 secret
$ sudo -u nobody ls -l secret    # other user ("nobody") is denied access
[sudo] password for alan-sysop: 
ls: cannot access 'test': Permission denied
$ sudo ls -l secret    # but root user bypasses access controls (CAP_DAC_OVERRIDE)
total 0

    

Answer 3

Ok, resumindo o bate-papo para qualquer pessoa que tenha essa pergunta. Basicamente, o que ele fez foi alterar as permissões de seu diretório home para 0700 (somente ele pode ler a execução de gravação)

chmod 0700 /homedirectory

Em seguida, o restante do bate-papo estava tentando garantir que o administrador não poderia su ele ou sudo su dele. (Sim, ele normalmente poderia obter os arquivos de outras maneiras, mas ele não tem as permissões.) Isso implica em alterar as permissões fornecidas em /etc/sudoers e garantir que apenas root tenha permissões para editar /etc/sudoers .