Bug 1268610 - Can we please get rid of the NoNewPrivs=yes
Summary: Can we please get rid of the NoNewPrivs=yes
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: tor
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-03 15:49 UTC by dac.override
Modified: 2020-11-05 09:38 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-03 17:24:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


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