So first off, thanks for the really detailed reply. I love your passion for security, SELinux and protecting data. It’s something New Relic is passionate about too in our products. Whilst the position I am advocating might not feel like this for you, I’d like to at least engage with on this to discuss the topic at hand and the position we currently hold.
It’s great that you maintain packages and policies to allow applications function in the right way on any system using SELinux. I really admire anyone who gets involved and helps out with such items.
So first off, I totally understand your concern regarding a process not being allowed write to folders it’s not meant to write to. That’s obviously a massive security concern. If any process can start rewriting configurations of processes and system security, user details etc all found in /etc. It’s an important directory.
New Relic isn’t designed to write to that folder, and if compromised somehow, yes I totally agree it’s safer to have it under control of a security software in an ideal scenario. While to my mind in general any process should require to be whitelisted to touch such a directory, that’s another discussion about limiting access to the most important part of specific folders to read access unless defined otherwise very manually.
At a highest level description, if your server was your house, you protect is with locks, strong windows, strong door (Firewalls,IPtables) and SELinux in this context, tags everything in the house and prevents them from moving a chair or a TV from room to room unless configured to allow it to move. Some might not want to restrict the things they place in their house to be restricted. They put it in the house and therefore it’s trusted. So their belief may be that it shouldn’t be locked to a room that it’s in the house it’s free to do what it wants. Perhaps like having a lodger stay in a house, they are in the house, they can roam and there is an implied trust, even if in theory, they could do something bad.
If someone doesn’t want to lock down such permissions, SELinux might not be for them. IPtables and Firewalls would give them the protection them expect. They are not anticipating internal threats, but they made that security decision themselves.
Those that do want to limit the movement of items in the house, will turn on SELinux, however they should understand what they are turning on and understand what they are configuring. When someone is given a policy from an entity or organisation to allow certain functionality to allow their product to run, they are trusting that what is enabled by that policy is exactly what is needed and if they don’t review it to ensure that what it allows doesn’t undo some of the security expected by having SELinux could without realising, render the greatness of SELinux, redundant.
Security is only as good as an administrator wants to take responsibility for. I agree everyone should enable SELinux, I also however think, everyone should understand the tool they are using and configure it to allow the tools they need to have specific access’s and be the one that configured and granted that permission. The documentation we provide gives steps to turn SELinux to Permissive or OFF permanently. In the “configure SELinux” section, we do say that configuring the SELinux policy is outside the scope and not the responsibility of New Relic support.
It’s definitely not a case that New Relic don’t care. Our position is purely that server security should be managed by server administrators and not by 3rd parties. For this reason we like seeing policies like the one you cited, but the caveat is that this isn’t guaranteed to run or function 100% on all environments. Understanding SELinux and providing required permissions to the process will be the simplest solution, particularly if using se-troubleshoot and se-troubleshoot-server for human readable errors to solve what a service needs when running in permissive mode.
You also mention that we handle sensitive data over the web. Totally agree, all our customer information is potentially sensitive and we advocate for using SSL connectivity between your server and our collectors to secure the communication. Once the data has left your server, SELinux is no longer involved as it’s outside the machine. It’s vulnerable, but that’s true of anything that communicates via the web. The correct configuration is to use secure HTTPS communication to protect the data stream and we strongly advocate that parameters containing private information should be configured to be stripped. Another option is that our high security mode could be enabled to remove it all by default.
The majority of what our agents send up by way of packet data is averaged data that provides overview performance data and largely doesn’t contain any personally identifiable information unless the person using New Relic has configured it to send this. End users of New Relic should review any data in the UI and configure our agent to not send something they are not comfortable with, just like they should review their own security policies to allow services and processes to function in only a way they want them to function.
The gentleman with the repo has done some great work, he’s provided New Relic users with an extremely handy resource. Like any security policy it should be reviewed intensively to ensure that what it allows falls in line with their companies security policy.
I promise you that New Relic cares about security, I promise you that our decision to not provide a SELinux policy is purely from a belief that we as a company should not configure security policy of our customers machines or dictate the policy they might use.
We also are firmly of the belief. Keep SELinux ON! It’s super powerful, NSA level security and when configured right can be one of the best friends of a server administrator in the event their server was compromised.