Bug 473391 - [Patch] SELinux protection for unbound daemon
[Patch] SELinux protection for unbound daemon
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-28 04:14 EST by Adam Tkac
Modified: 2013-04-30 19:42 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 08:09:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
.fc file (252 bytes, text/plain)
2008-11-28 04:15 EST, Adam Tkac
no flags Details
.te file (1.27 KB, text/plain)
2008-11-28 04:15 EST, Adam Tkac
no flags Details

  None (edit)
Description Adam Tkac 2008-11-28 04:14:26 EST
Description of problem:
unbound daemon is new DNS resolver and it lacks SELinux protection. I've created proposed policy. Would it be possible put it to rawhide selinux-policy, please?
Comment 1 Adam Tkac 2008-11-28 04:15:19 EST
Created attachment 324951 [details]
.fc file
Comment 2 Adam Tkac 2008-11-28 04:15:53 EST
Created attachment 324952 [details]
.te file
Comment 3 Daniel Walsh 2008-12-04 10:49:32 EST
Would it be better to just add it to the bind policy, since it has the same security requirements?
Comment 4 Paul Wouters 2008-12-04 11:02:24 EST
that might change in the future anyway. I'd keep it separate.
Comment 5 Adam Tkac 2008-12-04 11:06:45 EST
Well, it is possible but I don't think it is good. Unbound is recursive-only
nameserver, it is not authoritative server as named. Unbound policy can be far
more stricter than named's one. But if you think reuse of named policy makes
more sence simply reuse it, I might be "security-paranoid" ;)

(In reply to comment #4)
> that might change in the future anyway. I'd keep it separate.

Both are DNS servers so I don't expect major differences.
Comment 6 Daniel Walsh 2008-12-04 11:39:55 EST
If unbound needs less privs then bind, fine we can add a boolean to turn off privs.  But adding an additional policy for basically the same security domain is a mistake.


If we find they become very different in the future, we can separate the policy.  But I think they are more similar then different, lastly there is probably little likelyhood that you would have bind data on the same machine as unbound, so I don't see them attacking each other.
Comment 7 Paul Wouters 2008-12-05 10:44:27 EST
I think quite a few people will test with unbound having bind as a backup, or even using both on different IP's on the same box, while testing out things like DNSSEC.

But we've tried to ensure that bind and unbound use the same files for DNSSEC keys and all.
Comment 8 Adam Tkac 2008-12-08 06:45:45 EST
(In reply to comment #7)
> I think quite a few people will test with unbound having bind as a backup, or
> even using both on different IP's on the same box, while testing out things
> like DNSSEC.

I can imagine someone will use unbound and named on same box so one policy won't be good enough (unbound will be allowed to interfere named and opposite).
Comment 9 Daniel Walsh 2008-12-08 09:01:33 EST
That may be true, but for those users they are going to have to do some special stuff anyways to prevent the two domains from attacking each other since they both can use  dns ports. Adding the following to F10 and Rawhide Policy.

/etc/unbound(/.*)?			gen_context(system_u:object_r:named_conf_t,s0)
/etc/rc\.d/init\.d/unbound	--	gen_context(system_u:object_r:named_initrc_exec_t,s0)

/usr/sbin/unbound		--	gen_context(system_u:object_r:named_exec_t,s0)
/var/run/unbound(/.*)?			gen_context(system_u:object_r:named_var_run_t,s0)
Comment 10 Daniel Walsh 2008-12-08 15:16:50 EST
Fixed in selinux-policy-3.5.13-33.fc10
Comment 11 Bug Zapper 2009-06-09 05:58:25 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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