Por que o root está na roda e no operador? A raiz de estar em um grupo pode fazer alguma diferença?

Question

Eu só notei na minha máquina FreeBSD que o root está na roda e no operador. Estou tentando pensar em uma situação em que o UID 0 estar em um grupo teria algum efeito sobre ... bem ... qualquer coisa, e eu estou chegando em branco. Aliás, o root precisa mesmo de um grupo de login primário em / etc / passwd? Ou o login (3) engasga e morre se o usuário tiver um campo de grupo primário em branco?

(Para esclarecer: eu entendo o propósito da existência do grupo "root", já que os arquivos precisam do dono do grupo. Eu não entendo como é importante que o usuário root / toor / whatever tenha essa participação no grupo.)

Isso é apenas uma questão de décadas atrás, ou existe uma razão real para isso?

    

Answer 1

Em suma: não. Ter raiz em wheel e operator group não muda nada.

Mas você também está questionando duas outras coisas:

• O ID do grupo

  root é (por padrão) definido como 0, que é a coisa mais próxima de um valor vazio que você pode obter.

  $ head -4 /etc/passwd
  # $FreeBSD: releng/9.2/etc/master.passwd 243947 2012-12-06 11:52:31Z rwatson $
  #
  root:*:0:0:Charlie &:/root:/bin/csh
  toor:*:0:0:Bourne-again Superuser:/root:
  

  Como dito, todo usuário tem que ter um grupo, então você não pode configurar o id do grupo root (nem qualquer usuário gid) para um valor vazio ou em branco. Se você tentar definir um usuário como em branco, você será avisado por pwd_mkdb :

  pwd_mkdb: no gid for user root
  pwd_mkdb: at line #3
  pwd_mkdb: /etc/pw.Rlb2U3: Inappropriate file type or format
  re-edit the password file?
  

  Assim, o fato de root estar definido é mais sobre ter o nome correto em vez de apenas um número estúpido. Você pode alterar o gid de raiz para qualquer número sem sentido (gid não dentro de /etc/group ). Seu usuário root ainda poderá efetuar login, su ou qualquer outra coisa que o root possa fazer. Você acabará tendo algo assim:

  $ id
  uid=0(root) gid=10000 groups=10000,5(operator)
  

• sobre por que alguns usuários estão no grupo wheel que é uma história totalmente diferente, como FreeBSD , como OpenBSD ou NetBSD , os usuários precisam fazer parte do wheel para su raiz .

  Da documentação do FreeBSD ( capítulo 9.4 ):

  To su to root (or any other account with superuser privileges), you must be in the wheel group. If this feature were not there, anybody with an account on a system who also found out root's password would be able to gain superuser level access to the system. With this feature, this is not strictly true; su(1) will prevent them from even trying to enter the password if they are not in wheel.

  Mas você está certo, remover o usuário raiz da roda não alteraria as coisas. Isso é puramente formal, tanto quanto o usuário toor não faz parte de roda ou raiz faz parte do operador grupo.

• O grupo de operadores é, no entanto, puramente formal, sem nenhum significado especial em si.

Aqui está também o que Richard Stallman pensa sobre o grupo roda (de gnu su manual ):

Why GNU "su" does not support the 'wheel' group ===============================================

(This section is by Richard Stallman.)

Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)

However, occasionally the rulers do tell someone. Under the usual "su" mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers.

I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.

    

Answer 2

login (3) e outros esperam um grupo primário. Eles precisam disso para poderem definir campos válidos nos arquivos utmp / wtmp. E mesmo que não o fizessem (mudou o formato do arquivo), você teria um problema mais fundamental quando o login (1) ou o sshd (8) ou outros programas tentassem configurar a sessão do usuário - independentemente do utmp / wtmp eles precisavam preencher ambos As propriedades do processo de kernel UID e GID (como arquivos criados pelo usuário logado devem ter UID e GID preenchidos, como você percebe).

Quanto ao motivo pelo qual todo-poderoso-root precisa de mais do que o grupo primário, ele não é usado para verificações de permissão (como são ignoradas para o UID 0), mas serve para outros usos.

O grupo "wheel" é usado especialmente para várias verificações de autenticação adicionais, como por exemplo pam_wheel

Outros grupos como "operador" podem ser usados para recursos de segurança (por exemplo, algum processo quando executado pelo root pode setuid (2) para USER não privilegiado (como" nobody "), mantendo os membros do GROUP (como "operador"). Ele permitiria que tal processo continuasse a acessar os arquivos pertencentes a esse grupo, reduzindo significativamente os problemas de segurança da execução com acesso total ao UID 0.

Não tenho certeza se existem programas fazendo uso desse recurso em seu sistema (ou se o FreeBSD CURRENT padrão)

    

Answer 3

Isso pode fazer a diferença - assim que qualquer programa verificar a associação ao grupo e se comportar de maneira diferente, dependendo do resultado. É claro que não há diferença para os privilégios que o usuário root pode forçar .

    

Answer 4

Não é que, se ninguém é um membro da roda de grupo, a roda é simplesmente ignorada e todos os usuários podem executar su ... e potencialmente adivinhar a senha. Por ter pelo menos um userid um membro da roda de grupo (ou seja, userid root), os controles de roda são verificados e somente outros membros da roda de grupo podem tentar executar su.