Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1364611 - pdns has no context that allows using the sqlite backend
Summary: pdns has no context that allows using the sqlite backend
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-05 23:25 UTC by Felix Kaechele
Modified: 2018-08-14 10:22 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
Patch for a working policy (deleted)
2016-08-26 17:37 UTC, Felix Kaechele
no flags Details | Diff
New patch using bools (deleted)
2016-09-23 01:10 UTC, Felix Kaechele
no flags Details | Diff
Newest patch without guardian bool (deleted)
2016-09-25 21:10 UTC, Felix Kaechele
no flags Details | Diff

Description Felix Kaechele 2016-08-05 23:25:06 UTC
Description of problem:
pdns has no context and location you can put SQLite files in.
Technically this means you cannot use the SQLite backend with local database files while SELinux is enabled.


Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.13.1-191.8.fc24.noarch


How reproducible:
Always


Steps to Reproduce:
1. # dnf -y install pdns pdns-backend-sqlite
2. # cat << EOF > /etc/pdns/pdns.conf
setuid=pdns
setgid=pdns

master

launch=gsqlite3
gsqlite3-database=/var/lib/pdns/pdns.sqlite
gsqlite3-dnssec
gsqlite3-pragma-foreign-keys
EOF

3. # curl https://heffer.fedorapeople.org/pdns-sqlite-schema.sql | sqlite3 /var/lib/pdns/pdns.sqlite
4. # chown -R pdns: /var/lib/pdns
5. # systemctl start pdns (this fails)
6. # setenforce 0
7. # systemctl start pdns
8. # pdnsutil create-zone example.com ns1.example.com
9. # pdnsutil add-record example.com ns1 A 192.168.1.2 (the last two will trigger a write to the database and subsequent AVC denial)

Actual results:
pdns fails to start because of AVC denial


Expected results:
There should be a well-known location to place local sqlite databases for pdns where it can read, write and just be itself.


Additional info
audit2allow suggests:

allow pdns_t var_lib_t:dir { add_name remove_name write };
allow pdns_t var_lib_t:file { create getattr unlink write };

Comment 1 Felix Kaechele 2016-08-05 23:27:08 UTC
Also see: https://github.com/PowerDNS/pdns/tree/master/contrib/selinux

Comment 2 Ruben Kerkhof 2016-08-06 10:20:53 UTC
Indeed, I never considered sqlite when writing the policy.

The policy for pdns is in selinux-policy-targeted, this is not the same policy as https://github.com/PowerDNS/pdns/tree/master/contrib/selinux

Comment 3 Felix Kaechele 2016-08-26 17:37:58 UTC
Created attachment 1194418 [details]
Patch for a working policy

These are the modifications I have been using in the last couple of weeks. I see no AVC denials any more.
If you could maybe review this so we could start upstreaming these changes.
Thanks!

Comment 4 Ruben Kerkhof 2016-08-27 10:33:27 UTC
Thanks Felix.

These changes look fine to me. The only issues I see are:

# needed when using the guardian
  allow pdns_t self:capability kill;

I don't think we're using the guardian on Fedora, so is this really needed?

# optional embedded webserver listens on 8081 (transproxy) per default
corenet_tcp_bind_transproxy_port(pdns_t)

Perhaps put this behind a boolean? None of my pdns installations use the embedded webserver, and I really like the idea of SELinux stopping a potentially compromised pdns server from opening a listening tcp port.

Comment 5 Felix Kaechele 2016-09-23 01:10:05 UTC
Created attachment 1203981 [details]
New patch using bools

I decided to open up the binding to all unprivileged TCP ports for the webserver and hiding it behind a bool.
If the user enables the bool I assume he knows what he is doing.

Comment 6 Ruben Kerkhof 2016-09-23 10:12:32 UTC
Sounds good to me.

Can you answer my other question about the guardian as well?

Comment 7 Felix Kaechele 2016-09-23 15:14:01 UTC
Oh, sorry. Missed that.

Just found a spot in the documentation that reads:
"When the init-system of the Operating System does not properly supervises processes, like SysV init, it is recommended to run PowerDNS with the guardian option set to 'yes'."

Since we're on systemd for both Fedora and EL I assume we wouldn't need the guardian anyway and we can drop it from the policy.

Comment 8 Ruben Kerkhof 2016-09-24 10:18:30 UTC
Indeed. Systemd supervises powerdns, and powerdns talks the systemd notifaction protocol.

Comment 9 Felix Kaechele 2016-09-25 21:10:46 UTC
Created attachment 1204631 [details]
Newest patch without guardian bool

Well, this should be it then :)

Comment 10 Ruben Kerkhof 2016-09-26 12:17:00 UTC
I see you now also introduced a new boolean, pdns_use_supermaster.

While I'm all for fixing issues, this is unrelated to the topic of this BZ, namely adding SQLite support to the policy.

Can you explain why you need this? Slaves of supermasters normally connect to port 53.

Comment 11 Felix Kaechele 2016-09-26 16:40:03 UTC
When you enable supermaster replication pdns will open one udp and one udp6 socket each for out of band notifications and queries.
This is actually not really documented at all (at least I couldn't find it). But the sockets are bound in the mastercommunicator.cc source file.
The closest I could get to proof that this is what actually happens is here: https://github.com/PowerDNS/pdns/issues/402

If you'd disable the bool I introduced (and thus preventing pdns to wait for datagrams on those two sockets) your slaves will not be notified of domains which they don't already carry, hence taking the super out of supermaster.

I agree that this is outside of the scope of this particular bug, but when updating the policy anyway I figured we could make it as complete as it gets.

Comment 12 Ruben Kerkhof 2017-07-14 21:38:39 UTC
Hi Felix,

You are right, I checked the code and discussed this on #powerdns.
A Powerdns master binds to an unprivileged udp port to send NOTIFY messages to its slaves. It doesn't have to be a supermaster to do that however, there's also the 'also-notify' setting, so perhaps pdns_use_supermaster isn't the best name for that boolean.

Comment 13 Fedora End Of Life 2017-07-25 22:16:25 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 14 Fedora End Of Life 2018-05-03 08:36:58 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 15 Jan Kurik 2018-08-14 10:22:25 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.


Note You need to log in before you can comment on or make changes to this bug.