Bug 1268610

Summary:	Can we please get rid of the NoNewPrivs=yes
Product:	[Fedora] Fedora	Reporter:	dac.override
Component:	tor	Assignee:	Nobody's working on this, feel free to take it <nobody>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	lmacken, pwouters, s, tomek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-03 17:24:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description dac.override 2015-10-03 15:49:48 UTC

Description of problem:
Since recently tor.service added some new systemd "security" features. One of which is "NoNewPrivs". This "security" feature actually adds more insecurity than security.

This is because by using NoNewPrivs, systemd effectivly needs all the privileges that the bounded child has. So in other words everything tor must be able to do, systemd must be able to do as well.

This degrades systemds' integrity and is uncontrolable

Please removed it, as it sets a bad precedent.

Side note: Is PrivateTmp= really needed? In which scenario does tor use /tmp?

Similar to that, Why is PrivateDevices= used. The only object tor has any business with in /dev is the /dev/log symlink.

Fedora has far superior security with SELinux than these systemd "security" features. In effect using these features make things less security because extra permission must be granted...

Comment 1 Tomasz Torcz 2015-10-03 16:03:49 UTC

Could you please take it to the Tor upstream?

Comment 2 dac.override 2015-10-03 16:05:23 UTC

Why? This is Fedora specific. It is fedoras' tor.service unit and Fedora has superior security feature with which these features interfere

Comment 3 Tomasz Torcz 2015-10-03 16:44:12 UTC

No, Fedora's package use upstream unit; see this: https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in

Comment 4 Jamie Nguyen 2015-10-03 16:57:21 UTC

With NoNewPrivileges=yes, SELinux does not perform the appropriate transition. Note that this is a Linux kernel feature, not a systemd feature.

https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt :
> Be careful, though: LSMs might also not tighten constraints on exec
> in no_new_privs mode.  (This means that setting up a general-purpose
> service launcher to set no_new_privs before execing daemons may
> interfere with LSM-based sandboxing.)

I was unfortunately unaware of this limitation, and it does appear that tor runs as init_t instead of tor_t when NoNewPrivileges=yes is set. Thus, I'll remove NoNewPrivileges, but not for the reasons you stated.

Comment 5 dac.override 2015-10-03 19:00:20 UTC

Whatever... that transition issue is a symptom of what i described.. its not transitioning because systemd does not have all the permissions, that tor has

Comment 6 Jamie Nguyen 2015-10-03 19:04:48 UTC

NoNewPrivileges doesn't work the way you think it does.