[ZBXNEXT-4943] Change Zabbix Agent and Server to use different user accounts in packages Created: 2019 Jan 07  Updated: 2019 Feb 13

Status: Open
Project: ZABBIX FEATURE REQUESTS
Component/s: Agent (G), Packages (C)
Affects Version/s: None
Fix Version/s: None

Type: Change Request Priority: Major
Reporter: W. S. Story Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: account, agent, package, security, user
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS 7


 Description   

At the suggestion of Richlv, I am creating this. Per Chapter 1, page 15 of the Zabbix Network Monitoring: Second Edition book, it is a bad idea to use the same account for server and agent on the server.

Steps to fix:

  1. Create a /var/log/zabbixagent
  2. Create a zbxagent user account with nologin
  3. sudo cp /usr/lib/systemd/system/zabbix-agent.service /etc/systemd/system
  4. Modify the PidFile parameter to /var/run/zabbixagent/zabbix_agentd.pid
  5. Add a line User=zbxagent under the [Service] section
  6. Modify PidFile and LogFile in /etc/zabbix/zabbix_agentd.conf
  7. systemctl daemon-reload
  8. systemctl start zabbix-agent

Currently both start as zabbix user which could be a security vulnerability as the Zabbix agent on the server could read its configuration and give up details there were not intended outside of the server.

 

 Comments   
Comment by W. S. Story [ 2019 Jan 07 ]

I failed to mention that volter discovered this vulnerability.

Comment by Edgar Akhmetshin [ 2019 Jan 07 ]

Hello W.S. Story,

You can change the user in accordance with the security policy applied in your enterprise. The steps that you use to change a user are not correct:

Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Drop-in files must contain appropriate section headers. For instantiated units, this logic will first look for the instance ".d/" subdirectory (e.g. "[email protected]/") and read its ".conf" files, followed by the template ".d/" subdirectory (e.g. "[email protected]/") and the ".conf" files there. Moreover for units names containing dashes (""), the set of directories generated by truncating the unit name after all dashes is searched too. Specifically, for a unit name foo-bar-baz.service not only the regular drop-in directory foo-bar-baz.service.d/ is searched but also both foo-bar.service.d/ and foo-.service.d/. This is useful for defining common drop-ins for a set of related units, whose names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose systematic naming structure is built around dashes as component separators. Note that equally named drop-in files further down the prefix hierarchy override those further up, i.e. foo-bar-.service.d/10-override.conf overrides foo-.service.d/10-override.conf.

man 1 systemd

Could you describe in more detail what the vulnerability is?

Regards,
Edgar

Comment by richlv [ 2019 Jan 07 ]

ZBX-4916 initially covered this.

Comment by Arturs Lontons [ 2019 Jan 08 ]

Hi,
Thank you for pointing out the possible security flaw. As richlv mentioned, the issue was discussed a while back in ZBX-4916. It was decided then that we will cover the possible security flaws and ways to fix them in the Zabbix official documentation. 
Since agent and server running under the same account out of the box the intended behavior, I've changed the ticket to a feature request.

Generated at Sat Apr 20 10:39:58 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.