Re: [tor-bugs] #13805 [Tor]: Improve hardening in tor.service

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#13805: Improve hardening in tor.service
--------------------------+--------------------------------
     Reporter:  candrews  |      Owner:  candrews
         Type:  defect    |     Status:  assigned
     Priority:  normal    |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor       |    Version:
   Resolution:            |   Keywords:  systemd
Actual Points:            |  Parent ID:
       Points:            |
--------------------------+--------------------------------
Changes (by intrigeri):

 * owner:  intrigeri => candrews


Comment:

 Replying to [ticket:13805 candrews]:

 Thanks for taking this upstream!

 > Using PrivateDevices instead of DeviceAllow's is more secure as it
 create a totally separate /dev as well as removing the CAP_MKNOD
 capability.

 ACK. Now that Debian testing/sid have a systemd that supports this
 directive (introduced in v209), let's do that. Do you want to prepare a
 branch that implements this specific change?

 > ProtectHome makes /home inaccessible, equivalent to
 "InaccessibleDirectories = /home" but (arguably) more comprehensible.

 ACK. Now that Debian testing/sid have a systemd that supports this
 directive (introduced in v214), let's do that. This will break on distros
 that ship an older systemd, but well, they can still ship a drop-in to
 revert this change if they wish. Still, this can be undone if the process
 has CAP_SYS_ADMIN, so this is blocked by the CapabilityBoundingSet change
 (see below).

 > ProtectSystem=full make /usr and /etc read only.

 I'm unsure about this one.

 This looks slightly weaker than what we already have:

 * we currently make all the filesystem read-only, except the few
 directories we need write access to. The only justification I've found on
 https://bugs.gentoo.org/show_bug.cgi?id=529212#c16 for this change is that
 ReadWriteDirectories "will fail with a cryptic error message in case one
 of one those directories not being available", which sounds like something
 that should be improved in systemd itself, instead of discouraging us from
 using this directive, no?
 * AFAICT after reading systemd.exec(5), contrary to ReadOnlyDirectories
 and ReadWriteDirectories, ProtectSystem can be undone if the process has
 CAP_SYS_ADMIN, so this is blocked by the CapabilityBoundingSet change (see
 below).

 OTOH, our current combination of ReadOnlyDirectories and
 ReadWriteDirectories are not compatible with the AppArmorProfile directive
 we'll add in Debian, so there, I think we'll do want to replace them with
 ProtectSystem=full... and then it may make sense to do the same upstream,
 as suggested here, once we get the CapabilityBoundingSet right.

 > CapabilityBoundingSet reduces the process capability to just what it
 needs.

 This breaks things for me. I get:

 {{{
 [warn] Could not open "/etc/tor/torrc": Permission denied
 [warn] Could not unlink /var/run/tor/control: Permission denied
 }}}

 That's with tor 0.2.5.10-1 on Debian sid. Any idea what goes wrong?
 Perhaps a missing capability in the list?

 Also, has this been tested with pluggable transports, such as obfsproxy?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13805#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs