Closed jean-io closed 2 years ago
The user inside the container doesn't really matter. There are no security gains as Docker handles the container users, any escalation or escape potential is handled in ID mapping.
The warning message you see is for non-containerized or non-virtualized environments.
Hi @dschaper, sorry but I don't agree.
From Are Docker containers really secure? :
Just assume that privileged processes running within the container are the same as privileged processes running outside of the container.
And later about best practice:
- Drop privileges as quickly as possible
- Run your services as non-root whenever possible
- Treat root within a container as if it is root outside of the container
I think this also applies to pi-hole. This is why there is a warning at startup: to remind admins that running as root is a risk from a security point of view and so a bad practice.
No system is invulnerable! 😱
How do you propose Pi-hole attach to a priv'd low numbered port?
Also, that's an article that's older than Pi-hole, from 2014, a lot has changed since then.
Also, this is a bigger deal than the service running as non root IMO.
The non-root user is essentially root through sudo so securing that is a pre-req to securing the container by making it not run as root. If the users that are supposed to be secure are given sudo all nopasswd
it may as well be root.
@dschaper
How do you propose Pi-hole attach to a priv'd low numbered port?
Since Pi-Hole FTL is based on DNSMASQ, I found a --user
option in DNSMASQ configuration documentation. With this option DNSMASQ should be started as root so it can attach it self to a priv'd low numbered port and then drop privilege with forking to the specified user.
-u, --user=<username>
Specify the userid to which dnsmasq will change after startup. Dnsmasq must normally be started as root, but it will drop root privileges after startup by changing id to another user. Normally this user is "nobody" but that can be over-ridden with this switch.
-g, --group=<groupname>
Specify the group which dnsmasq will run as. The default is "dip", if available, to facilitate access to /etc/ppp/resolv.conf which is not normally world readable.
Also, that's an article that's older than Pi-hole, from 2014, a lot has changed since then.
Yes, a lot of thing have changed. Risk as been lowered but it is still present.
Here is another article from 2017, you can easily find other article from 2019 or 2020.
@diginc
The non-root user is essentially root through sudo so securing that is a pre-req to securing the container by making it not run as root. If the users that are supposed to be secure are given
sudo all nopasswd
it may as well be root.
Agreed 🤔 but it's only for ${LIGHTTPD_USER}
. Not sure why this is necessary.
My guess to solve this issue, fill in this line: https://github.com/pi-hole/pi-hole/blob/6b536b7428a1f57ff34ddc444ded6d3a62b00a38/advanced/dnsmasq.conf.original#L99
🙂
With this option DNSMASQ should be started as root
So the user inside the container still needs to be root.
pihole-FTL
drops privs by default but that capability does not exist inside docker containers, the filesystem does not expose that kind of metadata:
docker run -it --rm --entrypoint=pihole-FTL pihole/pihole:latest "-f"
[2020-10-29 16:18:57.102 1M] Using log file /var/log/pihole-FTL.log
[2020-10-29 16:18:57.103 1M] ########## FTL started! ##########
[2020-10-29 16:18:57.103 1M] FTL branch: master
[2020-10-29 16:18:57.103 1M] FTL version: v5.2
[2020-10-29 16:18:57.103 1M] FTL commit: dbd4a69
[2020-10-29 16:18:57.103 1M] FTL date: 2020-08-09 22:09:43 +0100
[2020-10-29 16:18:57.103 1M] FTL user: root
[2020-10-29 16:18:57.103 1M] Compiled for x86_64 (compiled on CI) using gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
[2020-10-29 16:18:57.103 1M] Starting config file parsing (/etc/pihole/pihole-FTL.conf)
[2020-10-29 16:18:57.103 1M] SOCKET_LISTENING: only local
[2020-10-29 16:18:57.103 1M] AAAA_QUERY_ANALYSIS: Show AAAA queries
[2020-10-29 16:18:57.103 1M] MAXDBDAYS: max age for stored queries is 365 days
[2020-10-29 16:18:57.103 1M] RESOLVE_IPV6: Resolve IPv6 addresses
[2020-10-29 16:18:57.104 1M] RESOLVE_IPV4: Resolve IPv4 addresses
[2020-10-29 16:18:57.104 1M] DBINTERVAL: saving to DB file every minute
[2020-10-29 16:18:57.104 1M] DBFILE: Using /etc/pihole/pihole-FTL.db
[2020-10-29 16:18:57.104 1M] MAXLOGAGE: Importing up to 24.0 hours of log data
[2020-10-29 16:18:57.104 1M] PRIVACYLEVEL: Set to 0
[2020-10-29 16:18:57.104 1M] IGNORE_LOCALHOST: Show queries from localhost
[2020-10-29 16:18:57.104 1M] BLOCKINGMODE: Null IPs for blocked domains
[2020-10-29 16:18:57.104 1M] ANALYZE_ONLY_A_AND_AAAA: Disabled. Analyzing all queries
[2020-10-29 16:18:57.104 1M] DBIMPORT: Importing history from database
[2020-10-29 16:18:57.104 1M] PIDFILE: Using /run/pihole-FTL.pid
[2020-10-29 16:18:57.104 1M] PORTFILE: Using /run/pihole-FTL.port
[2020-10-29 16:18:57.104 1M] SOCKETFILE: Using /run/pihole/FTL.sock
[2020-10-29 16:18:57.104 1M] SETUPVARSFILE: Using /etc/pihole/setupVars.conf
[2020-10-29 16:18:57.104 1M] MACVENDORDB: Using /etc/pihole/macvendor.db
[2020-10-29 16:18:57.104 1M] GRAVITYDB: Using /etc/pihole/gravity.db
[2020-10-29 16:18:57.105 1M] PARSE_ARP_CACHE: Active
[2020-10-29 16:18:57.105 1M] CNAME_DEEP_INSPECT: Active
[2020-10-29 16:18:57.105 1M] DELAY_STARTUP: No delay requested.
[2020-10-29 16:18:57.105 1M] NICE: Cannot change niceness to -10 (permission denied)
[2020-10-29 16:18:57.105 1M] BLOCK_ESNI: Enabled, blocking _esni.{blocked domain}
[2020-10-29 16:18:57.105 1M] NAMES_FROM_NETDB: Enabled, trying to get names from network database
[2020-10-29 16:18:57.105 1M] Finished config file parsing
[2020-10-29 16:18:57.105 1M] WARNING: Starting pihole-FTL as user root is not recommended
[2020-10-29 16:18:57.105 1M] No database file found, creating new (empty) database
[2020-10-29 16:18:57.132 1M] Database version is 1
[2020-10-29 16:18:57.132 1M] Updating long-term database to version 2
[2020-10-29 16:18:57.154 1M] Updating long-term database to version 3
[2020-10-29 16:18:57.163 1M] Updating long-term database to version 4
[2020-10-29 16:18:57.167 1M] Updating long-term database to version 5
[2020-10-29 16:18:57.174 1M] Updating long-term database to version 6
[2020-10-29 16:18:57.183 1M] Updating long-term database to version 7
[2020-10-29 16:18:57.193 1M] Database successfully initialized
[2020-10-29 16:18:57.193 1M] Imported 0 queries from the long-term database
[2020-10-29 16:18:57.193 1M] -> Total DNS queries: 0
[2020-10-29 16:18:57.193 1M] -> Cached DNS queries: 0
[2020-10-29 16:18:57.193 1M] -> Forwarded DNS queries: 0
[2020-10-29 16:18:57.193 1M] -> Blocked DNS queries: 0
[2020-10-29 16:18:57.193 1M] -> Unknown DNS queries: 0
[2020-10-29 16:18:57.193 1M] -> Unique domains: 0
[2020-10-29 16:18:57.193 1M] -> Unique clients: 0
[2020-10-29 16:18:57.193 1M] -> Known forward destinations: 0
[2020-10-29 16:18:57.193 1M] Successfully accessed setupVars.conf
[2020-10-29 16:18:57.193 1M] *************************************************************************
[2020-10-29 16:18:57.193 1M] * WARNING: Required Linux capability CAP_NET_ADMIN not available *
[2020-10-29 16:18:57.194 1M] *************************************************************************
[2020-10-29 16:18:57.194 1M] *************************************************************************
[2020-10-29 16:18:57.194 1M] * WARNING: Required Linux capability CAP_SYS_NICE not available *
[2020-10-29 16:18:57.194 1M] *************************************************************************
[2020-10-29 16:18:57.194 1M] PID of FTL process: 1
[2020-10-29 16:18:57.195 1/T7] Listening on port 4711 for incoming IPv4 telnet connections
[2020-10-29 16:18:57.195 1/T9] Listening on Unix socket
This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.
Thank GitHub actions 😄
Issue still open and valid: daemon should drop privilege after starting as root to book low numbered port.
I found a workaround on my server by running docker containers without root privileges: https://docs.docker.com/engine/security/userns-remap
As of tag 2022.01
, pihole-FTL
runs as pihole
, not root
, by default....
Good news! Thank @PromoFaux for making Pi-hole better, this app is great.
Closing this issue.
I know this is old, but with Docker you don't really need to listen on privileged ports. User can map non-privileged ports from within container to privileged ports outside of it if they want to. There should be no need to even start as root
.
Other possible solutions include authbind and CAP_NET_BIND_SERVICE.
Hello there 🤝
I see in my logs (
/var/log/pihole-FTL.log
) and in htop that pi-hole (inside container) is running as root.Is it possible to make it run as a non-root user?
Benefits:
[2020-10-04 15:55:49.267 373M] WARNING: Starting pihole-FTL as user root is not recommended
Thank 🍺