started this on Reddit and got instructed to move it here.
I wanted to see support for SE Linux on PiHole, mainly so I can recommend it to commercial projects.
Since I could, I wrote a quick shell script which creates a module (source in heredoc within the script), compiles and loads it. After running it, you can enable SE Linux and PiHole works fine. Tested on CentOS 7 and CentOS 8 .
I have no problem committing a few hours of my time (almost) every week to this project. I believe in supporting F/OSS projects and want to see this done, so I'm doing it.
What should I do next? If I understood correctly I should add it to advanced/Scripts and just create a pull request? Is this OK?
I've created a quick GitHub for this, and uploaded:
I'm interested in working on and maintaining this, I want to dedicate my own time here.
Thanks for sharing and the PR. Over the past couple years I have made a few attempts at building a sane policies for the project but decided to not release as I felt I was potentially causing security issues for other administrators. Due to this reason, we have recommended system administrators to accept their own risks by generate their own policy.
My hopes where to wait until PHP was removed from the project as I have issues setting policy on others computers which allow httpd to read/write/exec various file types. That said, completely disabling selinux could be viewed as a worse solution.
If @DanSchaper and other core team members would like to accept the risks of softening end-users systems, then I will contribute my selinux efforts as well as there is some stuff that I have which are not in your solution which would be required.
First of all thanks for taking the time to take a look, especially since it's the weekend. As I've said, I don't have a problem spending time to fix this in any way you see fit - I've always wanted to work on an Open Source project.
As for the risk, in my experience, PHP isn't an issue. I know quite a few places that run Odoo (former OpenERP) in PHP, installed one a month a go for a client. Also, I expect PiHole to be running in a single responsibility VM, when running in an enterprise-like environment, which really does address the risk as well.
My goal was to prevent perfect from being an enemy of good, and just get this out. I can and will work on it as required. Let me know what you'd like to see there, and I'll add it.
Glad to hear your interested in helping out! Just so expectations are set, This may take a while thresh out as we are still discussing internally about shipping a policy with the project. This has came up a few times in the past and we decided not to include it.
That said, I am definitely interested in re-visiting this to see where it goes. As previously mentioned, there is work being done for future versions that will replace the external webserver and php dependencies. This work should also help remove some of the selinux issues (ie httpd context having too much system access).
If you are interested on working towards this, here are a few of my thoughts/recommendations for this feature:
move the policy .te file into a standalone file instead of burying in inside a script so it can be used manually and/or other installation methods
have you fully tested the entire project with your policy to ensure it is complete? Ensure you have went though all the features and settings to ensure everything is in-fact functioning properly with the policy you have created.
the .te content you provided appears to be the standard output of a few audit2allow runs. I would prefer the .te file to be documented with comments for each policy line explaining why it is required. This assist with users understanding what is happening and also assist with the cleanup and additions required as the project evolves.
I have a few ideas.. but more-so around the implementation. I would suggest focusing on getting all the required policies figured out and ensure all features of the project are functional.
I've used heredoc as a simple way of packaging for myself. I'll repackage, create separate files, and document. I agree a separate file is more readable, this was just more convenient. Yes, it was created with audit2allow, but I can document it much better, once in separate file.
I've tested using CentOS 7 and 8, and verified it's working. I'll recreate the VM's, and retest, and I'll edit the setup script to skip "don't install if SE Linux active" part, so I can test the installation as well.
OK, so, you can drop my original pull request. If it's OK, I'd keep this Feature Request open, and document here.
I've setup a small github repo where I've uploaded the file for the original. I've now split the file into a .te module source, and a shell script, and started documenting as well. Also added on top is a comment that this written for PiHole and that it's released under EUPL, to be compliant.
Tomorrow I'll start on detailed testing, on both CentOS 7 and 8. Any changes will go into my repo. Once done, I'll make a new pull request. Hope this is OK, and in line with what you've envisioned.
My repo:
The old file is in there as well, just for me to keep track.
I've done some work, made a new shell script, a much smaller one, and a separate module. Done more testing, thank you /u/bcambl - I've found quite a few edge cases.... the module is much larger now.
Now I have to stop testing, because, on both CentOS 7 and 8 I get
[✗] Unsupported OS detected: CentOS Linux 7 (Core)
errors. This is on a clean VM :
[root@localhost automated install]# uname -a
Linux localhost.localdomain 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost automated install]# cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)
And same sa CentOS 8....
I'm guessing this is a fluke. Should I wait out, or is it OK to make a pull request now, with the work done so far - and then continue later, or wait out for this to be resolved? There are a lot of corner cases I've covered, and haven't tested before, like dark theme and the like. My work so far is here:
I've setup a few Vagrant files, for CentOS 7 and 8, and have been testing on them for the last week or so, rebuilding per your instructions, cleaning it up - and testing edge and corner cases... So, I've tested on the same Vagrantfile before - must be something in the vagrant upstream image for CentOS .
This got me stuck, so I assumed it's a small bug - and thought it might now be the right time to make a new pull request. If the code standard is OK, of course.
Please do not create a pull request.
May I ask you to review the third point in my comment above:
the .te content you provided appears to be the standard output of a few audit2allow runs. I would prefer the .te file to be documented with comments for each policy line explaining why it is required. This assist with users understanding what is happening and also assist with the cleanup and additions required as the project evolves.
If I was to elaborate on this request, every line in your policy file that begins with allow should have a comment explaining what the policy change affects on the system as a whole as well as what functionality within the pihole project requires said policy change. These can be grouped into similar project functionality.
As mentioned, anyone with root access and the audit2allow tool can iterate and build a policy that softens the selinux security of a system to the point where the project works with it enabled. Problem is, you are softening the entire system globally which is not something that is recommended especially in an enterprise. I know you say that you only recommend running the project on a stand-alone system; however, that is not realistic. Users do infact run multiple workloads on servers and virtual machines. At this point in time I would rather recommend the project isolated in a container as opposed to softening the global httpd_t selinux policies.
I'm just a bit out of time, haven't been discouraged by this . Just a few thoughts:
It's not me who thins that PiHole, or any other system, should be isolated, Single Responsibility isn't a new concept. However, and you are right, what's a good concept in theory isn't always followed in reality. So, yes, I agree, many will run in with "something else" alongside....
Second, and more important: A requirement for documentation is NEVER wrong. I fully agree. I'll see to fixing that when I get some time, hopefully this week. Keeping everything documented isn't just so that anyone can enable only portions he needs - it's just good practice. Never seen good documentation hurt anyone
Also, I expect PiHole to be running in a single responsibility VM, when running in an enterprise-like environment, which really does address the risk as well.
