Caso de uso típico para uma senha de grupo

Question

Eu verifiquei mais de meio século que vale a experiência Unix e nem meus colegas nem eu mesmo definimos uma senha em um grupo ( sg e gpasswd ). O que seria um caso de uso típico para uma senha de grupo ou está praticamente lá apenas por razões históricas?

    

Answer 1

Eu também nunca vi esse recurso usado, nem mesmo uma vez. A maioria das SAs nem sabe que esta instalação existe. Ao olhar para a página de manual para gpasswd , havia esta nota:

Notes about group passwords

  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 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 não são tão úteis para nada.

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

O grande problema com eles é que há apenas uma única senha para cada grupo, forçando as pessoas a compartilhar essa senha única, quando várias pessoas exigiam acesso a esse grupo específico.

Grupos

A maioria dos ambientes que eu encontrei tipicamente colocam as pessoas em grupos secundários, e então dá acesso a arquivos no sistema de arquivos, e isso satisfaz praticamente todo o uso que precisa ocorrer.

sudo

Com o advento de sudo , as permissões adicionais podem ser distribuídas conforme necessário para os grupos, prejudicando ainda mais os casos de uso que as senhas de grupo podem ter fornecido. Se você precisasse permitir mais permissões aos usuários, era muito mais fácil criar funções em sudo e depois permitir apenas o nome de usuário ou grupo em que estavam, permissões para elevar as permissões para que pudessem executar uma tarefa específica.

ACLs

Finalmente, a capacidade de criar ACLs (Listas de Controle de Acesso) realmente deu a última flexibilidade que o modelo de permissões Usuário / Grupo / Outros não pôde fornecer sozinho, relegando qualquer possível necessidade de senhas de grupos à obscuridade.

    

Answer 2

Aqui está um uso prático para senhas de grupo, que eu implementei para mim em nosso servidor de trabalho, já que os logs indicaram que minha conta estava sendo forçada (ou poderia ter sido um ataque de dicionário). Eu usei ssh-keygen e puttygen respeitosamente 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 ambas as chaves públicas ao .ssh/authorized_keys , criei um grupo marionette com uma senha e nenhum membro. Como root, usei visudo para adicionar as seguintes linhas.

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

Desativei a senha da minha conta. Ninguém pode fazer login dessa maneira. Eu agora faço o login apenas com as minhas chaves e entrar no grupo protegido por senha com newgrp marionette permite que eu me torne root usando sudo -i .
Sem a opção NOPASSWD: , será necessária a senha da conta do usuário . Se estiver desativado e este grupo não tiver NOPASSWD , você não poderá sudo -i . Ele também exigirá sua senha da conta de usuário se sua lista de comandos não tiver /bin/bash ou qualquer shell que sua raiz esteja usando por padrão.

Embora isso torne o caminho para o sudoing 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 uma senha e privilégios sudo, mas negue a ela a entrada ssh de /etc/ssh/sshd_config adicionando algo como:

DenyUsers root caan
DenyGroups root daleks

Isso é necessário para o acesso local no caso de você reinstalar e esquecer de fazer backup de suas chaves de acesso.

    

Answer 3

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

O único caso de uso que me vem à mente é configurá-lo para "!" - bloqueado, então ninguém, não sendo um membro desse grupo, pode mudar para ele com o comando newgrp .

Se eu olhar em / etc / group no SLES ou no / 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 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 a coisa que o sistema do computador chama de "usuário" não é realmente um usuário , mas um fluxo de trabalho - um conjunto de atividades.

Eis a pergunta: Por que não posso ter mais de uma atividade - uma para cada trabalho diferente que eu tenho? Eu posso. No meu computador de trabalho eu criei (experimentalmente) muitos usuários diferentes para que eu possa me concentrar na tarefa atual. Eu coloquei todos esses usuários no mesmo grupo para que eu possa acessar meus arquivos não importa qual usuário eu estou usando atualmente.

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 pensarmos sobre os usuários do sistema como fluxos de trabalho ?

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