Debian Bug report logs - #847477
more systemd protection stuff

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Peter Palfrader <weasel@debian.org>

To: submit@bugs.debian.org

Subject: more systemd protection stuff

Date: Thu, 8 Dec 2016 15:19:50 +0000

Package: tor
Version: 0.2.8.9-1

https://bugs.torproject.org/20930 lists a few more items we might
consider adding to our systemd service file.  Things like PrivateUsers
etc.

Evaluate.
-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Message #10 received at 847477@bugs.debian.org (full text, mbox, reply):

From: Peter Palfrader <weasel@debian.org>

To: Laurent Bigonville <bigon@debian.org>

Cc: 800385-done@bugs.debian.org, 847477@bugs.debian.org

Subject: Re: Bug#800385: tor: systemd .service granting too much capabilities?

Date: Wed, 4 Jan 2017 09:13:04 +0000

On Wed, 04 Jan 2017, Laurent Bigonville wrote:

> reopen 800385

Don't, let's take it to #847477.

> >># Hardening
> >>AppArmorProfile=system_tor
> >>NoNewPrivileges=yes
> >>PrivateTmp=yes
> >>PrivateDevices=yes
> >>ProtectHome=yes
> >>ProtectControlGroups=yes #added
> >>ProtectKernelTunables=yes #added
> >Maybe.
> >
> >>#ProtectSystem=full
> >>ProtectSystem=strict
> >Maybe.  That's new in sid/testing.
> >
> >>#ReadOnlyDirectories=/
> 
> I understand better why you choose the ReadOnlyDirectories=/ instead of
> ProtectSystem=strict now
> 
> >>#ReadWriteDirectories=-/proc
> >Maybe.
> >
> >>ReadWriteDirectories=-/var/lib/tor
> >>ReadWriteDirectories=-/var/log/tor
> >>#ReadWriteDirectories=-/var/run
> >>ReadWriteDirectories=-/var/run/tor
> >Can we still create the directory if it isn't there yet?
> 
> Yes it's working, if I'm commenting it out completely the daemon fails. I
> think that it only apply to the main process and not the Pre one (maybe?)

Does it also work if /var/run/tor is *not* there yet when you try to
start the service?  At least at some point in history the Pre commands
were subject to the same restrictions.

> >>#CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE
> >>CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
> >No, that breaks hidden services.  See https://bugs.debian.org/847598
> 
> I see. Do you know what were the owner/group of /var/lib/tor/hidden_service/
> in that bug?

They were debian-tor:, go-rwx, but the check is run when tor is still
root, thus DAC_OVERRIDE is required.

> >>torify wget http://www.perdu.com returns the expected content
> >I think other useful tests would be
> >  - can Tor start when a hidden service is configured?
> >  - can Hidden services read/write to backend sockets in
> >    /var/lib/tor-onion-sockets/?
> >  - does transparent proxying still work (TransPort)?
> >  - can we log to syslog?
> 
> I'll try to see when I can test that. Don't expect a reply tomorrow though.
> 
> For the syslog part, I see stuffs being logged in journald, so it's OK I
> guess.

Don't guess, test :)

-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Message #15 received at 847477@bugs.debian.org (full text, mbox, reply):

From: Laurent Bigonville <bigon@debian.org>

To: Peter Palfrader <weasel@debian.org>

Cc: 800385-done@bugs.debian.org, 847477@bugs.debian.org

Subject: Re: Bug#800385: tor: systemd .service granting too much capabilities?

Date: Wed, 4 Jan 2017 10:29:15 +0100

Le 04/01/17 à 10:13, Peter Palfrader a écrit :
> On Wed, 04 Jan 2017, Laurent Bigonville wrote:
>
>>
>>>> ReadWriteDirectories=-/var/lib/tor
>>>> ReadWriteDirectories=-/var/log/tor
>>>> #ReadWriteDirectories=-/var/run
>>>> ReadWriteDirectories=-/var/run/tor
>>> Can we still create the directory if it isn't there yet?
>> Yes it's working, if I'm commenting it out completely the daemon fails. I
>> think that it only apply to the main process and not the Pre one (maybe?)
> Does it also work if /var/run/tor is *not* there yet when you try to
> start the service?  At least at some point in history the Pre commands
> were subject to the same restrictions.

Yes I tried that, deleting the /var/run/tor directory completely and 
then restarting the service and the directory is created. A side note is 
that we should maybe use a tmpfiles config here, that way is more 
"systemd'ish" and then we are sure the directory is created at boot.
>>>> #CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE
>>>> CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
>>> No, that breaks hidden services.  See https://bugs.debian.org/847598
>> I see. Do you know what were the owner/group of /var/lib/tor/hidden_service/
>> in that bug?
> They were debian-tor:, go-rwx, but the check is run when tor is still
> root, thus DAC_OVERRIDE is required.

OK

>
>>>> torify wget http://www.perdu.com returns the expected content
>>> I think other useful tests would be
>>>   - can Tor start when a hidden service is configured?
>>>   - can Hidden services read/write to backend sockets in
>>>     /var/lib/tor-onion-sockets/?
>>>   - does transparent proxying still work (TransPort)?
>>>   - can we log to syslog?
>> I'll try to see when I can test that. Don't expect a reply tomorrow though.
>>
>> For the syslog part, I see stuffs being logged in journald, so it's OK I
>> guess.
> Don't guess, test :)
>

Message #20 received at 847477@bugs.debian.org (full text, mbox, reply):

From: Peter Palfrader <weasel@debian.org>

To: Laurent Bigonville <bigon@debian.org>, 847477@bugs.debian.org

Subject: Re: Bug#847477: Bug#800385: tor: systemd .service granting too much capabilities?

Date: Wed, 4 Jan 2017 09:39:01 +0000

On Wed, 04 Jan 2017, Laurent Bigonville wrote:

> Yes I tried that, deleting the /var/run/tor directory completely and then
> restarting the service and the directory is created. A side note is that we
> should maybe use a tmpfiles config here, that way is more "systemd'ish" and
> then we are sure the directory is created at boot.

Works for me.


-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Send a report that this bug log contains spam.