Your data. Anywhere you go.

New Relic for iOS or Android

Download on the App Store    Android App on Google play

New Relic Insights App for iOS

Download on the App Store

Learn more

Close icon

Feature Idea: SELinux support



A link to an SELInux module is here. It didn’t let me paste it transparently since I am a new user to the forum.

This guy created an SELinux policy for you, guys. Really, take this seriously. It is not even funny to ask to disable SELInux and, asking us, users, to maintain the policy is ridiculous.

The maintainer is a Red Hat employee so he’s on the right track.

Please, include yourselves into this and help take it upstream. It is not difficult. Just help out.

New Relic edit

  • I want this, too
  • I have more info to share (reply below)
  • I have a solution for this

0 voters

We take feature ideas seriously and our product managers review every one when plotting their roadmaps. However, there is no guarantee this feature will be implemented. This post ensures the idea is put on the table and discussed though. So please vote and share your extra details with our team.


Wow! This is truly amazing, @renich! We take this kind of hard work very seriously! Who is the creator/maintainer?

We have a handful of open source repos/solutions posted in the forum where users have taken projects upon themselves to help New Relic meet specific needs. I am always in awe of the talent and time it takes. Thanks for sharing! I’ll be passing this along to my product managers so they can see! :blush:


Good to “read” @Linds. I hope this one gets supported. I am in the process of adding an allow for ptrace.


One thing I’ve noticed, though. NewRelic whats to write it’s socket in /tmp/.newrelic.sock as a default:

; Setting: newrelic.daemon.port
; Type   : string or integer
; Scope  : system
; Default: /tmp/.newrelic.sock

It should write it in:

  • SystemD systems: /run/newrelic/.newrelic.sock
  • Others: /var/run/newrelic/.newrelic.sock


Nice :thumbsup: @renich—I’ll be sure our product managers see this input as well!


Hey @renich

So I just wanted to pop in here and just clarify some things. New Relic doesn’t have configuration for SELinux at all at this time as this is outside the scope of New Relic support.

Server security is something that should be decided on a case by case basis. The only person deciding what can run or can’t run on your server should be someone tasked with server security for your machines.

As such the decision to use SELinux is very much something each company makes for themselves, it unfortunately isn’t a New Relic product, so configuration of it to allow services, just like any service that communicates internally, must be made as an active decision on your behalf. This is why we don’t provide a security policy to apply to solve this problem.

I would also like to clarify that we don’t suggest to just turn SELinux off. Switching SELinux to permissive mode will solve the problem, but opens your server up to potential security issues. The solution in all cases is to configure SELinux in the right way to allow the processes you need to function to have sufficient privileges whilst leaving this enabled if SELinux is what you want for your server security.

As @Linds mentioned, we feed all of this stuff back to Product Management regardless, because they want to know what people are asking for and the problems they are coming up against. With SELinux, I do believe all security decisions should be made by someone responsible for server administration and security, and the repo above should be used as an awesome resource but you should review each of the features it enables to be sure this aligns with your companies security policy. Nobody should define that for you.

I hope this brings some additional clarity to it. Additional information can also be found on our documentation page for SELinux;


@acuffe thank you for your reply.

It’s not the way you’re putting it. In the link you shared, you’re blaming SELinux for not letting NewRelic do it’s job. Also, there is a link on that page on how to disable it.

Just so you know, a great part of Fedora and it’s children (RHEL, CentOS, Scientific Linux, etc) rely on SELinux being active. Maintainers of packages, such as myself, take care of things and make sure that the right policies are in place so your application does only what it is supposed to do.

A good example is nginx or apache. They should never be able to write stuff in /etc. This is one thing that SELinux help us do. Same case for all of our services.

Anyway, I’ve been suggesting NewRelic, as a package maintainer for it’s own product, to collaborate with Fedora and the SELinux maintainers so that they provide support for it for three years now. Up to now, NewRelic doesn’t seem to care. They just DO suggest to turn off SELinux.

Now, you’re not making security decisions for anyone here. I am asking you to be collaborative with the SELinux team @ Fedora so that they can provide support to YOUR application and ensure it only does what it is supposed to.

Do I need to remind you that your app sends sensible data through the Internet? Imagine if it gets exploited… you’re introducing serous risks to any server; which would be greatly minimized if SELinux was making sure that your daemon is doing what it’s supposed to.

I am just saying. That guy has done your work for you. You should acknowledge it and not avoid it saying it’s out of scope.


Hey @renich

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.


Thank you for your reply and ACKs.

Lets establish one thing first. My petition is based on the fact that SELInux comes activated by default on any of Fedora’s children and, also, that this petition comes from the users that want SELInux on.

If a user makes the, hopefully informed, desission to disable it, then none of this applies and, also, it doesn’t affect them.

I am not asking for NewRelic to promote SELinux and ask it’s users to turn it on. I am asking NewRelic to do it’s part on maintaining the correspondent part; for the users that want it on.

My concern is based on the premise that the user needs SELInux on. That’s why I am asking you to cooperate with the maintainers of the global SELInux policy (Fedora Security team).

Yes; that’s why I disagree fervently with NewRelic’s stance. I don’t think you should give instructions for disabling SELInux; it’s out of scope as well. Also, I think it is in the scope of NewRelic to run as it should either the user has SELinux turned on or off. It is like that for, say, the PHP maintainers in Fedora. They need to make sure PHP runs well with SELinux turned on or off. If it doesn’t, either, they write the policy or contact the security team for support and provide all relevant information about it so that the security team takes care of it.

NewRelic claims it supports RHEL/CentOS, right? Well, it doesn’t quite do… at least not fully. You need to support SELinux if you want to claim those things.

This is the point of disagreement. I do not consider maintaining the policy for a daemon that NewRelic wrote is managing the a server’s security. Who better than NewRelic to support the policy? Who knows better what the daemon is supposed to do? It is just a matter of the devs taking care of this. It is for NewRelic’s own benefit. Plus, Fedora is willing to support, contribute and maintain this for free! Obviuosly, much better if NewRelic invest some time in it themselves!

I believe NewRelic does care. This is why I am raising the subject to see if NewRelic can reconsider. Don’t look at it as managing anyone’s security; it’s just making sure your daemon communicates as it should; through the ports it should and it reads/writes what it should (sockets included).

I think it would do all of us great good if NewRelic took the time to understand how SELinux works to change it’s view of what it does and what it means to write a policy. It is not like you need to spend months of development for this. I am sure there is a Fedora/RHEL enthusiast amongst your ranks that would gladly volunteer to do this.

I try to write with utmost respect to you, but as objective and direct as I can. If I offended you in any way, please, forgive me. It is not the point; rather, to express myself as clearly as possible.

Here’re some references: (this thing didn’t let me paste the links here)

Try going to fpaste dot org and add a forward slash, then the number: 351309

Also, english is not my first language. Forgive any gramatical and lexical catastrophes I might’ve committed. :wink:


Hey @renich

Thanks for the super detailed reply again. First off, nothing you have said is offensive or anything I would consider other than an engaging conversation on server security.

I appreciate your side of this conversation, I think you do have some good points, unfortunately right now the company policy is to not define an SELinux policy as a blanket approach and end users configuring a policy leaves them firmly in control of their own security and what their services can and can’t do on a particular machine.

What I wanted to do is have some good forward movement from this excellent conversation. So here is two things I can tell you I have done as a result of this.

  1. I have added to my own personal to-do list ( I am a Technical Support Engineer in New Relic, not a developer or security expert), to engage with our developers on permissions we expect our agent to require. I will then elaborate on the configuration of SELinux section of our documentation with the permissions we expect the agent/daemon to require on any given machine. This will aid and facilitate anyone defining their own policy.

  2. I have brought this discussion to the New Relic security team to ensure that they at least have seen our conversation. While I cannot guarantee that anything would change because of this, I can tell you that I have put this in front of them to ensure the overall discussion and both sides of the discussion are visible and reviewable by them.

I hope that is at least something, potentially not what you were advocating for entirely but I wanted to at least take some forward motion from such a good discussion.


@acuffe you’ve done well. I appreciate it and thank you for it. Let’s hope the security team gives the idea a chance.

It is awesome to work with FOSS communities. You can get work done and it benefits everybody around you. I hope they realize this and move towards this goal.


This is important to me too. What’s the best way to voice my support?


Thanks for letting us know that this is also something that is important to you, @greg8! I have added a poll to the top of this thread so that we can collect votes on this feature idea! Thanks for voicing your request—our product team is always eager to know what our customers need. :blush:


Hey guys,

It’s more than two years already. I came across this issue and had to search the internet for solution.

Quite a pain since our infrastructure are all-in with SELinux.