Por que o syslog é um usuário?

Quando verifico /var/log, encontro algo muito estranho

me@me:~$ ls -lt /var/log |head -6 '
total 160368
-rw-r-----  1 syslog            adm              19919118 Jan 15 16:55 auth.log
-rw-r-----  1 syslog            adm             139702302 Jan 15 16:55 syslog
-rw-r-----  1 syslog            adm                191122 Jan 15 16:55 mail.log
-rw-r-----  1 syslog            adm               2210432 Jan 15 16:32 kern.log
-rw-r--r--  1 root              root              1741863 Jan 15 14:22 dpkg.log

Observe que o proprietário dos quatro primeiros arquivos de log é syslog. É estranho, porque há apenas um usuário no meu sistema:

me@me~$ users
me

Por que um nome de arquivo pode syslogser um usuário?

Tem a ver com segurança e permissões para acessar seu sistema.

E não, você tem muito mais usuários do que apenas seu próprio usuário. Há "raiz", "daemon", "bin", "jogos", "ninguém" e "lista".

Faça um more /etc/passwdpara obter uma lista de usuários em seu sistema. Você verá muitas linhas com "/ usr / sbin / nologin". Isso significa que eles não podem ser usados ​​como um usuário normal com um login como o seu próprio usuário. A terceira coluna é o ID do usuário. Todos os IDs de usuário abaixo de 1000 são pseudo-usuários. Seu primeiro usuário do sudo (aquele que instalou o sistema) possui 1000 por padrão.

Basicamente, o usuário syslog tem permissão para usar o /var/log/diretório definido como um diretório de propriedade da raiz . Para não precisar comprometer as permissões no diretório (ou seja, diminuir as permissões para que outros usuários possam usá-lo), esse usuário foi criado.

O mesmo é feito com o usuário para Apache e MySQL (você verá um usuário e grupo www-data e um usuário e grupo MySQL quando os instalar), mas é usado para muitas coisas. Há um grupo "discagem" que é usado para acessar dispositivos para externos. Os usuários são adicionados a esse grupo para permitir que o usuário use esses dispositivos. Caso contrário, você receberá um erro de permissão negada. Ele funciona de duas maneiras: negar o acesso de um usuário significa remover o grupo.

O serviço syslog, que grava mensagens de log criadas pelo kernel e por outros serviços em vários arquivos de log, no console e / ou em outros destinos, é executado sob sua própria conta de usuário especial. O mesmo acontece com muitos outros serviços. Isso é para implementar o princípio do menor privilégio :

Para minimizar o possível impacto de um serviço comprometido ou com defeito (por exemplo, um serviço que possui um bug que por sua vez é explorado por um invasor, ou um serviço que possui um bug que causa é fazer coisas indesejadas aleatórias ou um serviço que foi deliberadamente projetado por um desenvolvedor maligno para fazer coisas ruins), você deseja que cada serviço tenha acesso apenas ao que precisa para sua operação e nada mais.

Em qualquer sistema operacional unix (que inclui todas as distribuições GNU / Linux, como o Ubuntu), você pode atribuir privilégios mais facilmente (que é principalmente o direito de ler e / ou gravar de / em determinados arquivos ou coisas semelhantes a arquivos, como nós do dispositivo) com base em usuários e grupos. Existem outras possibilidades, mas elas costumam ser mais entediantes e propensas a erros, ou funcionam apenas em contextos específicos.

Portanto, o serviço syslog é executado na conta de usuário syslog. Se agora, por exemplo, um invasor pode fazer com que o serviço syslog faça o que eles mandam, em vez do que deveria, o serviço syslog ainda está restrito (imposto pelo kernel com base na conta do usuário, não imposto pelo syslog próprio software, que seria inútil porque está comprometido) para gravar apenas nos arquivos de log (os únicos arquivos aos quais o usuário do syslog tem acesso de gravação). Assim, o invasor não pode usar o serviço syslog comprometido para, por exemplo, alterar o conteúdo de um site ou banco de dados hospedado no mesmo computador, porque os arquivos relevantes são configurados para serem graváveis ​​apenas por um conjunto específico de outro usuário (humano ou sistema ) contas, não pela conta do usuário syslog.

Para causar mais danos do que apenas excluir / modificar os arquivos de log e ler os arquivos "públicos" (com permissão de "leitura" para todos), o invasor precisará primeiro explorar adicionalmente um segundo bug, no kernel ou em algum software instalado para executar com privilégios diferentes do usuário que o chamou ( setuid ) e, assim, obter privilégios adicionais ( escalonamento de privilégios ).

---

O userscomando que você usou, de acordo com sua página de manual , mostra apenas os usuários que estão conectados no momento . Como o usuário syslog é um usuário do sistema , ele nunca efetuará login, portanto nunca aparecerá nesta lista. Você pode procurar no arquivo /etc/passwdou usar qualquer um dos outros métodos descritos aqui para obter uma lista de todos os usuários (humanos e do sistema) em seu sistema.

Porque o syslog não é um arquivo; é um daemon usado pelo sistema para armazenar daemon do sistema e mensagens de aplicativos (depuração, erro, aviso e informações) em arquivos.

Leia aqui para uma breve história do syslog.

Em outras distribuições, por exemplo, baseadas no Red Hat Linux, a saída do syslog para o sistema é armazenada em um arquivo chamado /var/log/messages. Depende da configuração.

Como Rinzwind diz, por razões de segurança, diferentes componentes do sistema operacional são executados com um usuário específico e cada usuário tem seus próprios direitos. Por exemplo, o syslog tem pelo menos permissão de gravação na /var/logpasta.

Um sistema possui muitos serviços e geralmente existem usuários para cada serviço ou para um pequeno grupo de serviços. Por exemplo apache get www-data|httpd|apache,. Normalmente, esses usuários do daemon não têm acesso ao Bash para evitar vazamentos de segurança.