I have been asked to install this on my linux boxes, and after installing on one of my test systems, noticed the process runs as root.
That’s not good for a network service.
I tried modifiying the init script to start it as a normal user (bes), and the process did not stay running, it didn’t give me an error either.
(modified line 34 of /etc/init.d/BESClient-6.0.2.68 to include --user bes)
Can I run it as an unprivileged user?
or
Can it start as root, then pass off the process to an unprivileged user (similar to apache)
or
If you think it has to run as root, do you have an AppArmor or SELinux policy/configuration that I can apply to minimize the effect of any potential problems?
or
If none of the above are possible, is there a configuration option to turn off the listening service component (tcp&udp listening on any port - including 52311) and just have the client use the scheduled client originated queries to update the bes server?
or
Do you not recommend using this tool in untrusted networks (across the internet, in a dmz, on wireless connections, or on laptops that could be used at home/in cafe’s/etc)
The BES Agent needs to run as a fully privileged account because it is fundamentally performing privileged operations such as installing software, inventoring the computer, etc. These operations require continued full access to the computer, which is different from other services like Apache that need very limited access to the system (just a few folders).
If I understand your post correctly, you are worried that any service that listens on the network (the agent listens for UDP packets on 52311)is potentially a source of a network based attack as are commonly seen with other network services that you mention. We agree with you completely, but there a few key differences that significantly mitigate the likelihood of such an attack:
The BES Agent listens only on UDP (not TCP, which tends to involve more complex interactions).
The BES Agent UDP listener is very simple. It listens for very specific packets and ignores everything else. This keep the code short and easy to review for vulnerabilities.
The BES Agent UDP listener code has been reviewed many times for any vulnerabilities and it is not common to change it.
Of course, this does not guarantee there isn’t a vulnerability in there somewhere (we believe such a guarantee is not possible with software), but it does make an attack much less likely than for a much more complex piece of software like a web server.
Hopefully that will help convince you that an attack on the BES Agent listening service is very small. If you are still not convinced, that is OK too because we allow an option for disabling the agent listener. To do this, change the BES Agent setting “_BESClient_Comm_ListenEnable” to “0”. More info at http://support.bigfix.com/bes/misc/besconfigsettings.html
Note that if you disable the BES Agent listener the BES Agent won’t know about new actions until its polling cycle (which is once per day by default). This will mean that if you take an action, you will expect the BES Agent to respond within a day (instead of within a minute or so). You can change the polling cycle using the two “Comm_CommandPoll” settings documented on that same web page above. Setting the polling interval to 30 minutes is reasonable.
To answer your other question:
We do expect BES Agent to be running in DMZs, public Internet, untrusted networks, trusted networks, hostile networks, and anywhere else without any problems.
If the listener service is that simple, could it not run as unpriveliged separately from the ‘query-system-info’/‘apply-update’ components, and thereby eliminate the ran-as-root concern?
I’m not doubting that the BigFix developers have worked hard to make the code robust, and I also understand that compared to the likes of iis/apache, this tool has very little mindshare in the malicious software developer world. All the same, a portential vulnerability is just that-potential, the risk analysis as to wether one is comfortable with that potential can be based heavily on the data/tools hosted by the system bigfix is being installed on. Just as with apache, there may not be a significant risk to run the proccess as root if all it’s doing is hosting casserole recipes, but that changes significantly when a server hosts critical business/personnal data or server management software. The apache (and other service - ntp/samba/etc) developers have simplified that risk analysis by taking the view that one’s data
could
be critcal, and therefore why tempt fate by running the service as root, no matter whether the application/content hosted by the service displays recipies, social security numbers, or provides server management functionality (e.g. Webmin/rhn/samba’s swat/etc). In the case where a service still runs as root or is otherwise critical in nature, the major enterprise distributions (redhat/suse) have additional protection in the form of SELinux and/or AppArmor policies that application developers can use which limit a rogue (root or otherwise) process from accessing critical portions of the system.
From what is sounds like, if I want to minimize risk (especially in dmz’s, on the internet, etc), I should be running this with the udp listener agent disabled - particularly since one has fewer options in managing udp traffic at a firewall than with tcp traffic.
The difference between the BES Agent and the Apache example you use is that it is not normal for the Apache process to access critical portions of the system, but it is very normal for the BES Agent to access all parts of the system as it does the standard inventory, patch, software distribution, and other systems and configuration managment activities.
I think you are right and it would be technically possible for the UDP listener piece to run as a different user and then allow the BES Client to continue to run as a fully privileged account, and the two processes could communicate. We will consider this to be an enhancement request.
Until then, you do have the option of disabling the UDP listener, which hopefully will meet your needs.
This is a good topic for discussion. We always want to take the system security very seriously and it helps us to hear your concerns that go above and beyond our protections in place. Thanks for bringing up this discussion.