Bug 1268610 - Can we please get rid of the NoNewPrivs=yes
Can we please get rid of the NoNewPrivs=yes
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: tor (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jamie Nguyen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-03 11:49 EDT by dac.override
Modified: 2015-10-03 15:04 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-03 13:24:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dac.override 2015-10-03 11:49:48 EDT
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 12:03:49 EDT
Could you please take it to the Tor upstream?
Comment 2 dac.override 2015-10-03 12:05:23 EDT
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 12:44:12 EDT
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 12:57:21 EDT
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 15:00:20 EDT
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 15:04:48 EDT
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.