Caso de uso típico para uma senha de grupo

Eu verifiquei mais de meio século de experiência no 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 existe apenas por motivos históricos?

Eu também nunca vi esse recurso usado, nem mesmo uma vez. A maioria das SA nem sabe que esse recurso 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

Eu acho que eles eram uma ideia natural em imitar o modelo de senhas do usuário, que fazia sentido duplicar esse modelo de caso de uso para grupos também. Mas, na prática, eles realmente não são tão úteis para nada.

A idéia com uma senha de grupo é que, se você precisar obter acesso a um grupo específico (um do qual não esteja listado como membro), poderá fazê-lo usando o newgrpcomando e ser desafiado por uma senha para obter acesso a esses grupos alternativos.

O grande problema deles é que existe apenas uma senha para cada grupo, forçando as pessoas a compartilharem essa senha, quando várias pessoas precisavam acessar esse grupo em particular.

Grupos

A maioria dos ambientes que encontrei geralmente colocam pessoas em grupos secundários e, em seguida, dão 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, os grupos podem ser entregues conforme necessário, comprometendo ainda mais os casos de uso que as senhas de grupos possam ter fornecido. Se você precisava permitir mais permissões aos usuários, era muito mais fácil criar funções sudoe permitir apenas o nome de usuário ou grupo em que eles estavam, permissões para elevar as permissões para que eles pudessem executar uma tarefa específica.

ACLs

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

Aqui está um uso prático para senhas de grupo, que eu implementei em nosso servidor de trabalho, uma vez que os logs indicavam que minha conta estava sendo forçada brutalmente (ou poderia ter sido um ataque de dicionário).
Usei ssh-keygene puttygenrespeitosamente 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. Eu adicionei as duas chaves públicas ao .ssh/authorized_keys, criei um grupo marionettecom uma senha e sem membros. Como root, costumava visudoadicionar as seguintes linhas.

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

Desabilitei a senha da minha conta, você não pode fazer login dessa maneira. Agora, logon 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, será necessária a senha da sua conta de usuário. Se estiver desativado e esse grupo não tiver NOPASSWD, você não poderá sudo -i. Também exigirá a senha da sua conta de usuário se sua lista de comandos não tiver /bin/bashou qualquer shell que sua raiz esteja usando por padrão.

Embora isso faça com que o caminho para executar algumas etapas seja mais longo, ele adiciona uma boa camada de segurança. Se você optar por criar todas as suas contas dessa maneira, crie uma conta local com senha e privilégios de sudo, mas negue a entrada ssh /etc/ssh/sshd_configadicionando algo como:

DenyUsers root caan
DenyGroups root daleks

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

Eu nunca vi um caso de uso para essa senha também. E isso são cerca de 20 anos de experiência * nix.

O único caso de uso que me vem à cabeça é 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 deu ao trabalho de criar um mecanismo de sombra para essa senha.

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 um usuário . Por exemplo, em casa, temos três computadores - o laptop da minha esposa, meu laptop e o computador 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 da área de trabalho, ele ou ela usará a conta comum. Vemos aqui que aquilo que o sistema de computador chama de "usuário" não é realmente um usuário, mas um fluxo de trabalho - um conjunto de atividades.

Aqui está a pergunta: 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 que eu possa 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 como usuários e pensar nos usuários do sistema como fluxos de trabalho ?

Do que esses novos usuários precisariam de uma senha para entrar, certo? Aqui é o lugar de gpasswd. Eu ainda preciso descobrir como fazer login com o grupo (até agora, o que eu sei é que você pode alternar grupos com gpasswd se você já estiver logado).