systemd DynamicUser = serviços v.s. divisões de journald

4

systemd-journald tem a configuração padrão SplitMode=uid , para criar arquivos individuais de diário (log) para cada usuário, que eles podem ler.

Ao executar serviços com DynamicUser= , isso significa que o serviço pode ler os logs de% oldDynamicUser= services aleatórios?

E, em caso afirmativo, existem possíveis preocupações (segurança?) de poder ler um arquivo de diário que não é estritamente seu?

EDIT: certamente há uma preocupação com coredumps que systemd salva como arquivos separados ou no diário? (systemd-coredump)

A postagem no blog de DynamicUser = não menciona o periódico, ao discutir as implicações da reutilização de UIDs.

link

You may wonder why system users are generally not deallocated when the package that registered them is uninstalled from a system (at least on most distributions). The reason for that is one relevant property of the user concept (you might even want to call this a design flaw): user IDs are sticky to files (and other objects such as IPC objects). If a service running as a specific system user creates a file at some location, and is then terminated and its package and user removed, then the created file still belongs to the numeric ID ("UID") the system user originally got assigned. When the next system user is allocated and — due to ID recycling — happens to get assigned the same numeric ID, then it will also gain access to the file, and that's generally considered a problem, given that the file belonged to a potentially very different service once upon a time, and likely should not be readable or changeable by anything coming after it. Distributions hence tend to avoid UID recycling which means system users remain registered forever on a system after they have been allocated once.

...

In order to counter the problem, two strategies easily come to mind:

  1. Prohibit the service from creating any files/directories or IPC objects

  2. Automatically removing the files/directories or IPC objects the service created when it shuts down.

In systemd we implemented both strategies, but for different parts of the execution environment...

    
por sourcejedi 12.03.2018 / 11:31

2 respostas

2

Não há nenhum problema de segurança com isso. (Eu chequei no systemd v239).

Os usuários no intervalo de UID usados pelo DynamicUser =, não podem ler seus próprios diários do systemd ou systemd coredumps. A mesma restrição se aplica a usuários "do sistema" (geralmente UID < 1000) e nobody .

link

if (uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY)
        return 0;


/* Make sure normal users can read (but not write or delete)
 * their own coredumps */

link

static bool uid_for_system_journal(uid_t uid) {

        /* Returns true if the specified UID shall get its data stored in the system journal*/

        return uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY;
}
    
por 12.08.2018 / 13:43
0

SplitMode = uid significa simplesmente que o diário é dividido em arquivos diferentes para instâncias do systemd diferentes de cada usuário, para o systemd do uid 1000, um para pid1 (diário do sistema) e o modo de acesso é definido de acordo pelo daemon journald. Atualmente, você não pode dividi-lo de outra forma, o que acho uma vergonha.

    
por 12.08.2018 / 12:34