Where is the location for everything in /etc/pihole configured?
I could understand if just the conf files were in there (dns-servers.conf, pihole-FTL.conf, setupVars.conf), but having block lists and even the logging database pihole-FTL.db in there, growing at 30MB/day, is ridiculous.
pihole-FTL --help doesn't mention any options for this. Are the paths configurable in pihole-FTL.conf or when starting pihole-FTL?
This is described in the documenation:
https://docs.pi-hole.net/ftldns/configfile/
Which file in your setup is growing at 30 MB / day?
Thanks for the documentation link.
pihole-FTL.db is growing by upward of 30MB/day.
30MB a day? That's it?
Yes, but I don't want that sort of growth in my /etc/ directory. Or even on my root partition if I can help it.
You can move the database elsewhere, or limit the number of days the database stores data, or disable the database completely. That should be the only file in the /etc/pihole directory that has any growth.
I also moved macvendor.db and setupVars.conf as there are options for those.
Is there a way to also move out lists.* files, gravity.list and regex.list?
You might be able to set up a symbolic link for the whole folder and have everything elsewhere.
Iām curious - why do you want these files elsewhere?
Partly philosophical, partly security.
Philosophical part is that the remaining files in question (mostly blocklists) are data rather than configuration and should not live in /etc/ (/var/lib/pihole/ seems like a more reasonable choice).
On the other hand, especially where the web interface is empowered to touch things outside if the /var/www/ sandbox, I really don't want it to be able to read/write things in /etc/, that seems like far too great a security risk.
I am a little concerned that various pihole components don't seem to have been designed with security in mind, which is a little startling in 2019. Having said that, given the curl | sudo bash recommended installation method, all bets are off.
To address all this, I am working on building rpm packages that include various changes to make the setup more secure out of the box and less triggering of SELinux screaming about something trying to break out of the sandbox it is supposed to be confined to.
There is a very clear disclaimer on the use of curl on the Pi-Hole documentation page. Users have the option to use whichever install method they like.
"Those who want to get started quickly and conveniently, may install Pi-hole using the following command:
curl -sSL https://install.pi-hole.net | bash
Piping to bash is a controversial topic, as it prevents you from reading code that is about to run on your system.
If you would prefer to review the code before installation, we provide these alternative installation methods."
I am aware of it, but it is rather difficult to argue that "read the shell script" is a great alternative, especially since the script goes and fetches pre-built binaries. Packaging and packagability are a long standing, well understood practice that retains its value despite the proliferation of security unconscious methods such as the ones mentioned and containerisation.
For those that are interested in a more traditional approach, I have rpms for el7 (source and binary) here:
http://ftp.redsleeve.org/pub/misc/pihole/
It is still WIP, and I haven't yet packaged AdminLTE, but it mostly already "works for me". I hope to have the AdminLTE component packaged up and tested tomorrow.
As an added bonus of my approach, my pihole-FTL x86-64 binary is 1,024,544 vs. 4,640,016 for the shipped one (1,856,096 stripped). Improvements like this make a significant cumulative difference when running on memory constrained systems such as micro VM instances or Raspberry Pis.
If you find anything, let us know. The whole package has been audited a few times by a few different organizations and individuals and minor things have been caught and the code updated to reflect that.
Good to hear your found reduction in binary size, I look forward to seeing how to run an x86-64 binary on an ARM device like a Raspberry Pi.
Oh, and take a look at GitHub - pi-hole/docker-pi-hole: Pi-hole in a docker container for more information.
Please remove the google adsense from that page or I will have to remove the link from your post.
I haven't had a chance to audit the code, nor do I expect to get around to it, I am only looking at the practices exhibited in various places, such as keeping growing databases in /etc/, invoking sudo from web php code and suchlike, that I honestly didn't expect to see again after the early '00s.
As for the wisecrack about running an x86 binary on an ARM device, I am testing packaging on x86 because that's what I have in front of me right now. Various hosting providers offer cheap tiny x86 instances that only have 512 or 1GB of RAM. Once I have working .src.rpm files, it becomes trivial to rebuild them from source on any rpm distribution on any platform (e.g. armv5tel). But I will happily share the space savings achieved on ARM when I get to that point in the coming days.
I think I removed the adsense - can you confirm? Apologies for that, my ad-blocking must have been pretty good, I haven't seen any ads in a decade, so I hadn't realised it was still on that site.
I guess it comes down to a matter of trust. Do you trust us, those that have written the code and those that have audited it, or do you trust someone that posts a link to download an RPM from a site that may contain any matter of malware or security issues itself as the content of the site is not known and wasn't checked prior.
I know my tone is not friendly and my actions bruising. Here's my end.
Someone I have never dealt with before and I have not clue who they are or what they know comes to our house and tells us we are doing is wrong and they know better. They post a link to unknown packages that are even further obfuscated from the original code. There is no audit trail or ability to check the authenticity or sterility of the package. I have no clue if you are distributing malware or something nefarious and I can't take the risk of relying on "Trust me" as a given fact. You may have the best intentions but that's not a risk we can afford. You don't even know the contents of a simple site with less than a dozen lines of HTML. As someone in the security field as you seem to be, I would assume you'd make the same decisions I have.
It's not purely a matter of trust - if I didn't trust your code, I wouldn't be using it at all. It's a step removed from that, and comes down to two points:
Now, recognise that I am talking about legacy AdminLTE here - mainly because that's what the install script seems to have installed in my test VM. I haven't had a chance to look at the new web front end - that may well not suffer from any such potential issues.
One of the other things I'm working on is making sure that the packages I'm working on play nice with default SELinux policies on EL7, which I think will be of value to anyone wanting to run it on RH/CentOS/Fedora.
As for the packages - if you look under SRPMs, you will find that they contain sources, not binaries. The tarballs therein are as per the source tarballs that come from github. The only thing that is changed is the names of the directory in the tarball to make it a little more straightforward to build. All of the patches applied and additional files such as the service scripts are also included with the source. This is, IMO, more scrutinizable than curl | sudo bash, reading a large shell script (the rpm spec file is far shorter than the install bash script), or downloading binaries.
I'll grant you that not deleting an ancient header from my index page was an oversight on my part. But I hope you also agree that there is merit to the issues I raised on this thread, most of which are mitigatable easily enough that I've been able to do it in a day.
Finally - apologies if I came across as disrespectful and/or abrasive. It was not intentional. Such is the difficulty of the typed medium. 
I am trying to help with changes that I think would benefit others. A handful of alterations in defaults and packaging can go a long way.
So, from a relatively agnostic perspective, I agree with @gordan on the architecture /layout he's describing /recommending.
From a "Good Practices" point of view, /etc should contain configuration and other "how do we run" information and data should live somewhere else such as "/var/lib" or "/var/db". Web functions should be in their own sandbox /chroot, and whatnot.
While it doesn't mean a whole lot on a micro system like a Rasberry Pi, the ability to have data on it's own partition /slice can help prevent system lock if a DB or log file "runs away" and starts maxing capacity.
I also agree that the proposed structure would be a pro-active measure to improve compatibility with the SELinux project, as well as potentially limit the impact of any "zero-day" compromise that might crop up in lighttpd or other supporting apps.