sudo credential caching on por padrão

4

Acabou de instalar um mínimo do Ubuntu 12.04 e, em seguida, instalou xfce4 e xinit a partir da linha de comando após a primeira inicialização. Totalmente instalação de baunilha afaik.

Estou percebendo que o sudo armazena a senha em cache até eu emitir sudo -k para limpá-la.

Isso é um comportamento inesperado em minha mente. Eu rodei o xfce4 antes e não me lembro do cache de credenciais em uso, nem o experimentei nas muitas instalações anteriores do ubuntu que tive ao longo dos anos.

Este é um novo recurso do Ubuntu? Isso é algo que é o resultado da instalação mínima? Este é um padrão xfce que foi adicionado recentemente?

    
por Dan Dman 18.09.2012 / 21:09

1 resposta

14

Na verdade, armazena em cache o direito de elevar, mas não sua senha, e tem feito isso por um bom tempo. No entanto, ele faz isso por apenas quinze minutos , por padrão. Isso ocorre por design:

De link :

  

Depois que um usuário é autenticado, um registro de data e hora é atualizado e o usuário pode usar o sudo sem uma senha por um curto período de tempo (5 minutos, a menos que seja substituído em sudoers).

e como uma nota de segurança dos man sudoers :

  

O sudo irá verificar a propriedade do seu diretório de registro de data e hora (/ var / db / sudo por padrão) e ignorar o conteúdo do diretório se ele não for de propriedade do root ou se for gravável por um usuário diferente de root. Em sistemas que permitem que usuários não-raiz distribuam arquivos via chown (2), se o diretório de registro de data e hora estiver localizado em um diretório gravável por qualquer pessoa (por exemplo, / tmp), é possível que um usuário crie o diretório de registro de data e hora antes que o sudo seja executado. No entanto, como o sudo verifica a propriedade e o modo do diretório e seu conteúdo, o único dano que pode ser feito é "ocultar" arquivos colocando-os no registro de data e hora. É improvável que isso aconteça, uma vez que, uma vez que o diretório de registro de data e hora é de propriedade de raiz e inacessível por qualquer outro usuário, o usuário que coloca os arquivos lá não poderá obtê-los de volta. Para contornar este problema, você pode usar um diretório que não seja gravável mundialmente para os timestamps (/ var / adm / sudo, por exemplo) ou criar / var / db / sudo com o proprietário apropriado (root) e permissões (0700) nos arquivos de inicialização do sistema.

e da mesma página:

  

Como os arquivos de registro de data e hora residem no sistema de arquivos, eles podem sobreviver à sessão de login de um usuário. Como resultado, um usuário pode fazer login, executar um comando com sudo após autenticar, efetuar logout, efetuar login novamente e executar o sudo sem autenticação, desde que o tempo de modificação do arquivo de registro de data esteja dentro de 5 minutos (ou seja qual for o tempo limite definido para em sudoers). Quando a opção tty_tickets é ativada em sudoers, o registro de data e hora tem granularidade por perimetria, mas ainda pode sobreviver à sessão do usuário. Nos sistemas Linux em que o sistema de arquivos devpts é usado, sistemas Solaris com o sistema de arquivos devices, assim como outros sistemas que utilizam um sistema de arquivos devfs que aumenta monotonicamente o número de inodes dos dispositivos criados (como o Mac OS X), sudo é capaz para determinar quando um arquivo de registro de data e hora baseado em tty é obsoleto e irá ignorá-lo. Os administradores não devem confiar nesse recurso, pois ele não está disponível universalmente.

Como visto aqui , esse comportamento tem persistiu por um longo tempo.

Se você quiser alterar isso, use visudo para definir a opção timestamp_timeout .

    
por hexafraction 18.09.2012 / 21:36