Caso de uso típico para uma senha de grupo

Question

Eu verifiquei mais de meio século de experiência em Unix e nem meus colegas, nem eu jamais definimos uma senha em um grupo ( sge gpasswd). Qual seria um caso de uso típico para uma senha de grupo ou ela existe apenas por motivos históricos?

Answer 1

Eu também nunca vi esse recurso ser usado, nem uma vez. A maioria das SA nem sequer sabe que esta facilidade existe. Ao olhar para a página de manual, gpasswdhavia esta nota:

Notas sobre senhas de grupo

  Group passwords are an inherent security problem since more than one 
  person is permitted to know the password. However, groups are a useful 
  tool for permitting co-operation between different users.

Por que eles existem

Acho que foi uma ideia natural imitar o modelo de usuários com senhas, que fazia sentido duplicar esse modelo de caso de uso para grupos também. Mas na prática eles não são tão úteis para nada.

A ideia com uma senha de grupo é que, se você precisasse obter acesso a um grupo específico (um do qual não estava listado como membro), você poderia fazê-lo usando o newgrpcomando e ser desafiado com uma senha para obter acesso para esses grupos alternativos.

O grande problema com eles é que existe apenas uma senha para cada grupo, obrigando as pessoas a compartilhar essa senha única, quando várias pessoas exigem acesso a esse grupo específico.

Grupos

A maioria dos ambientes que encontrei normalmente coloca as pessoas em grupos secundários e, em seguida, concede a esses grupos acesso aos arquivos no sistema de arquivos, e isso satisfaz praticamente todo o uso que precisa ocorrer.

sudo

Com o advento de sudopermissões adicionais poderiam ser distribuídas conforme necessário aos grupos, prejudicando ainda mais quaisquer casos de uso que as senhas de grupo possam ter fornecido. Se você precisasse conceder mais permissões aos usuários, seria muito mais fácil criar funções sudoe, em seguida, apenas permitir o nome de usuário ou grupo em que eles estavam, permissões para elevar suas permissões para que pudessem executar uma tarefa específica.

ACLs

Finalmente, a capacidade de criar listas de controle de acesso (ACLs) realmente proporcionou a última gota de flexibilidade que o modelo de permissões Usuário/Grupo/Outros não poderia fornecer sozinho, relegando à obscuridade qualquer possível necessidade de senhas de grupo.

Answer 2

Aqui está um uso prático para senhas de grupo, que eu mesmo implementei em nosso servidor de trabalho, já que os logs indicavam que minha conta estava sofrendo força bruta (ou poderia ter sido um ataque de dicionário).
Usei ssh-keygene puttygenrespectivamente para gerar pares de chaves para uso em minha estação de trabalho e computador doméstico. A chave que uso em casa requer uma senha. Adicionei ambas as chaves públicas ao .ssh/authorized_keys, criei um grupo marionettecom uma senha e sem membros. Como root eu costumava visudoadicionar as seguintes linhas.

Cmnd_Alias      SUDOING = /bin/bash, /usr/bin/sudo -i
%marionette     ALL=NOPASSWD:SUDOING

Desativei a senha da minha conta, ninguém poderá fazer login dessa forma. Agora faço login apenas com minhas chaves e entrar no grupo protegido por senha newgrp marionettepermite que eu me torne root usando sudo -i.
Sem a NOPASSWD:opção, isso exigirá que vocêconta de usuáriosenha. Se estiver desabilitado e este grupo não tiver NOPASSWD, você não conseguirá sudo -i. Também exigirá que vocêconta de usuáriosenha se sua lista de comandos não tiver /bin/bashou qualquer shell que seu root esteja usando por padrão.

Embora isso torne o caminho para o sudo mais longo, adiciona uma boa camada de segurança. Se você optar por fazer todas as suas contas assim, crie uma conta local com uma senha e privilégios sudo, mas negue a entrada ssh /etc/ssh/sshd_configadicionando algo como:

DenyUsers root caan
DenyGroups root daleks

Isso é necessário para acesso local caso você reinstale e esqueça de fazer backup de suas chaves de acesso.

Answer 3

Também nunca vi um caso de uso para essa senha. E isso equivale a cerca de 20 anos de experiência *nix.

O único caso de uso que me vem à mente é defini-lo como "!" - bloqueado, para que ninguém que não seja membro desse grupo possa mudar para ele com o newgrpcomando.

Se eu olhar para /etc/group no SLES ou /etc/gshadow em sistemas baseados em RedHat, este parece ser o caso de uso "típico". O SLES nem se preocupou em criar um mecanismo de sombra para essa senha.

Answer 4

Deixe-me sugerir um caso de uso.

Primeiro, deixe-me dizer que estamos tão acostumados com o termo “usuário” que nem pensamos nisso. Mas "usuário" não é realmente umdo utilizador. Por exemplo, em casa temos três computadores - o laptop da minha esposa, o meu laptop e um computador desktop comum. Quando uso o laptop da minha esposa, faço login com a conta de usuário dela. Quando ela usa meu laptop, ela faz login com minha conta de usuário. Se alguém precisar do desktop, ele usará a única conta comum. Vemos aqui que aquilo que o sistema de computador chama de “usuário” não é realmente umdo utilizadormas umfluxo de trabalho- um conjunto de atividades.

Eis a questão: Por que não posso ter mais de uma atividade – uma para cada trabalho diferente que tenho? Eu posso. No meu computador de trabalho, criei (experimentalmente) muitos usuários diferentes para poder me concentrar na tarefa atual. Coloquei todos esses usuários no mesmo grupo para poder acessar meus arquivos, independentemente do usuário que estou usando no momento.

Então, onde o gpasswd se encaixa nisso?

O comportamento padrão do Ubuntu é criar um grupo especial para cada usuário.

E se decidirmos pensar nesses grupos primários comoUsuáriose pensar nos usuários do sistema comofluxos de trabalho?

Então esses novos usuários precisariam de uma senha para fazer login, certo? Aqui é o lugar do gpasswd. Ainda preciso descobrir como fazer login no grupo (até agora o que sei é que você pode trocar de grupo com o gpasswd se já estiver logado).