Bug 1357395 - Couple of SELinux alerts for Tor
Couple of SELinux alerts for Tor
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
24
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Lukas Vrabec
Ben Levenson
: Reopened
: 1366967 1369510 1369584 1370967 1374668 1375979 1379792 1393315 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-07-18 02:39 EDT by srakitnican
Modified: 2017-08-08 11:39 EDT (History)
32 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 11:39:53 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 srakitnican 2016-07-18 02:39:19 EDT
Just installed and tried to start the tor service.

Srp 18 08:21:27 rawhide Tor[30252]: Bootstrapped 85%: Finishing handshake with first hop
Srp 18 08:21:28 rawhide Tor[30252]: Opening Control listener on /run/tor/control
Srp 18 08:21:28 rawhide Tor[30252]: Bootstrapped 90%: Establishing a Tor circuit
Srp 18 08:21:29 rawhide Tor[30252]: Tor has successfully opened a circuit. Looks like client functionality is working.
Srp 18 08:21:29 rawhide Tor[30252]: Bootstrapped 100%: Done
Srp 18 08:21:30 rawhide setroubleshoot[20050]: SELinux is preventing (tor) from mounton access on the directory /etc. For complete SELinux messages. run sealert -l dd4c8d57-4e91-4542-b974-3650f76f7430
Srp 18 08:21:30 rawhide python3[20050]: SELinux is preventing (tor) from mounton access on the directory /etc.
                                        
                                        *****  Plugin catchall_labels (83.8 confidence) suggests   *******************
                                        
                                        If you want to allow (tor) to have mounton access on the etc directory
                                        Then you need to change the label on /etc
                                        Do
                                        # semanage fcontext -a -t FILE_TYPE '/etc'
                                        where FILE_TYPE is one of the following: admin_home_t, anon_inodefs_t, audit_spool_t, auditd_log_t, autofs_t, automount_tmp_t, bacula_store_t, binfmt_misc_fs_t, boot_t, capifs_t, cephfs_t, cgroup_t, cifs_t, container_image_t, debugfs_t, default_t, device_t, devpts_t, dnssec_t, dosfs_t, ecryptfs_t, efivarfs_t, fusefs_t, home_root_t, hugetlbfs_t, ifconfig_var_run_t, init_var_run_t, initrc_tmp_t, iso9660_t, kdbusfs_t, mail_spool_t, mnt_t, mqueue_spool_t, named_conf_t, news_spool_t, nfs_t, nfsd_fs_t, onload_fs_t, openshift_tmp_t, openshift_var_lib_t, oracleasmfs_t, proc_t, proc_xen_t, pstore_t, public_content_rw_t, public_content_t, ramfs_t, random_seed_t, removable_t, root_t, rpc_pipefs_t, security_t, spufs_t, src_t, svirt_sandbox_file_t, sysctl_fs_t, sysctl_t, sysfs_t, sysv_t, tmp_t, tmpfs_t, usbfs_t, user_home_dir_t, user_home_t, user_tmp_t, usr_t, var_lib_nfs_t, var_lib_t, var_lock_t, var_log_t, var_run_t, var_t, virt_image_t, virt_var_lib_t, vmblock_t, vxfs_t, xend_var_lib_t, xend_var_run_t, xenfs_t, xenstored_var_lib_t.
                                        Then execute:
                                        restorecon -v '/etc'
                                        
                                        
                                        *****  Plugin catchall (17.1 confidence) suggests   **************************
                                        
                                        If you believe that (tor) should be allowed mounton access on the etc directory by default.
                                        Then you should report this as a bug.
                                        You can generate a local policy module to allow this access.
                                        Do
                                        allow this access for now by executing:
                                        # ausearch -c '(tor)' --raw | audit2allow -M my-tor
                                        # semodule -X 300 -i my-tor.pp
                                        
Srp 18 08:21:30 rawhide org.fedoraproject.Setroubleshootd[1152]: (setroubleshoot:30209): Gtk-CRITICAL **: gtk_grid_attach: assertion '_gtk_widget_get_parent (child) == NULL' failed
Srp 18 08:21:30 rawhide setroubleshoot[20050]: SELinux is preventing (tor) from mounton access on the directory /run/tor. For complete SELinux messages. run sealert -l 619e7318-cf85-4079-8e1a-7d4496501aca
Srp 18 08:21:30 rawhide python3[20050]: SELinux is preventing (tor) from mounton access on the directory /run/tor.
                                        
                                        *****  Plugin catchall (100. confidence) suggests   **************************
                                        
                                        If you believe that (tor) should be allowed mounton access on the tor directory by default.
                                        Then you should report this as a bug.
                                        You can generate a local policy module to allow this access.
                                        Do
                                        allow this access for now by executing:
                                        # ausearch -c '(tor)' --raw | audit2allow -M my-tor
                                        # semodule -X 300 -i my-tor.pp
                                        
Srp 18 08:21:30 rawhide org.fedoraproject.Setroubleshootd[1152]: (setroubleshoot:30209): Gtk-CRITICAL **: gtk_grid_attach: assertion '_gtk_widget_get_parent (child) == NULL' failed
Srp 18 08:21:30 rawhide setroubleshoot[20050]: SELinux is preventing (tor) from mounton access on the directory /var/lib/tor. For complete SELinux messages. run sealert -l 120ee172-5df7-4b15-97a5-dcc49e0638ea
Srp 18 08:21:30 rawhide python3[20050]: SELinux is preventing (tor) from mounton access on the directory /var/lib/tor.
                                        
                                        *****  Plugin catchall (100. confidence) suggests   **************************
                                        
                                        If you believe that (tor) should be allowed mounton access on the tor directory by default.
                                        Then you should report this as a bug.
                                        You can generate a local policy module to allow this access.
                                        Do
                                        allow this access for now by executing:
                                        # ausearch -c '(tor)' --raw | audit2allow -M my-tor
                                        # semodule -X 300 -i my-tor.pp
                                        
Srp 18 08:21:30 rawhide org.fedoraproject.Setroubleshootd[1152]: (setroubleshoot:30209): Gtk-CRITICAL **: gtk_grid_attach: assertion '_gtk_widget_get_parent (child) == NULL' failed
Srp 18 08:21:30 rawhide setroubleshoot[20050]: SELinux is preventing (tor) from mounton access on the directory /var/log/tor. For complete SELinux messages. run sealert -l d26fabf0-b950-467a-80d9-ce7ac5930a26
Srp 18 08:21:30 rawhide python3[20050]: SELinux is preventing (tor) from mounton access on the directory /var/log/tor.
                                        
                                        *****  Plugin catchall (100. confidence) suggests   **************************
                                        
                                        If you believe that (tor) should be allowed mounton access on the tor directory by default.
                                        Then you should report this as a bug.
                                        You can generate a local policy module to allow this access.
                                        Do
                                        allow this access for now by executing:
                                        # ausearch -c '(tor)' --raw | audit2allow -M my-tor
                                        # semodule -X 300 -i my-tor.pp
                                        


Tried the command restorecon -v '/etc' that first alert suggests with no effect (nothing was changed).
Comment 1 srakitnican 2016-07-18 02:40:26 EDT
$ rpm -q tor selinux-policy
tor-0.2.7.6-6.fc24.x86_64
selinux-policy-3.13.1-202.fc25.noarch
Comment 2 Christian Stadelmann 2016-07-19 03:20:58 EDT
I only see alerts for mounton on /etc (first 2 in comment #0), not for mounton on the "tor" directory, this might be configuration dependent.

These alerts happen on every boot or after waking up from suspend.
Comment 3 srakitnican 2016-07-19 04:16:40 EDT
It is. The difference is that I have put SELinux into Permissive mode. I have seen only first alert when SELinux was in Enforcing mode.
Comment 4 Christian Stadelmann 2016-07-19 05:17:31 EDT
(In reply to srakitnican from comment #3)
> It is. The difference is that I have put SELinux into Permissive mode. I
> have seen only first alert when SELinux was in Enforcing mode.

I meant this is depending on tor config, not selinux config. I'm in permissive mode too and only see the first 2 alerts. But I'm on F24, not rawhide:
tor-0.2.7.6-6.fc24.x86_64
selinux-policy-3.13.1-191.5.fc24.noarch
Comment 5 Jan Kurik 2016-07-26 00:22:19 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.
Comment 6 Andrea 2016-08-14 10:04:33 EDT
I've got the same problem.

Fedora 24 fully updated

This is the output from 

sudo journalctl -xe
                                                     
                                                     *****  Plugin catchall (100. confidence) suggests   **************************
                                                     
                                                     If you believe that (tor) should be allowed mounton access on the tor directory by default.
                                                     Then you should report this as a bug.
                                                     You can generate a local policy module to allow this access.
                                                     Do
                                                     allow this access for now by executing:
                                                     # ausearch -c '(tor)' --raw | audit2allow -M my-tor
                                                     # semodule -X 300 -i my-tor.pp
                                                     
Aug 14 15:00:13 localhost.localdomain setroubleshoot[9002]: SELinux is preventing (tor) from mounton access on the directory /run/tor. For complete SELinux messages. run sealert -l b04a07
Aug 14 15:00:13 localhost.localdomain python3[9002]: SELinux is preventing (tor) from mounton access on the directory /run/tor.
                                                     
                                                     *****  Plugin catchall (100. confidence) suggests   **************************
                                                     
                                                     If you believe that (tor) should be allowed mounton access on the tor directory by default.
                                                     Then you should report this as a bug.
                                                     You can generate a local policy module to allow this access.
                                                     Do
                                                     allow this access for now by executing:
                                                     # ausearch -c '(tor)' --raw | audit2allow -M my-tor
                                                     # semodule -X 300 -i my-tor.pp
                                                     
Aug 14 15:00:21 localhost.localdomain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/sys
Comment 7 Andrea 2016-08-14 11:17:58 EDT
There are more than 1 directories with this problem

I got alerts for

/run/tor
/var/lib/tor
/var/log/tor
Comment 8 Dominik 'Rathann' Mierzejewski 2016-08-19 18:35:32 EDT
Same here. This prevents tor.service from starting when SELinux is in enforcing mode.

# rpm -q tor selinux-policy
tor-0.2.7.6-6.fc24.x86_64
selinux-policy-3.13.1-191.10.fc24.noarch

# ausearch -c '(tor)'
[...]
time->Sat Aug 20 00:32:10 2016
type=AVC msg=audit(1471645930.565:992): avc:  denied  { mounton } for  pid=11745 comm="(tor)" path="/run/tor" dev="tmpfs" ino=114795 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:tor_var_run_t:s0 tclass=dir permissive=1
----
time->Sat Aug 20 00:32:10 2016
type=AVC msg=audit(1471645930.567:993): avc:  denied  { mounton } for  pid=11745 comm="(tor)" path="/var/lib/tor" dev="dm-1" ino=1312890 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:tor_var_lib_t:s0 tclass=dir permissive=1
----
time->Sat Aug 20 00:32:10 2016
type=AVC msg=audit(1471645930.567:994): avc:  denied  { mounton } for  pid=11745 comm="(tor)" path="/var/log/tor" dev="dm-1" ino=1312891 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:tor_var_log_t:s0 tclass=dir permissive=1
Comment 9 Dominik 'Rathann' Mierzejewski 2016-08-19 19:09:45 EDT
Almost the same relay-only configuration (except for IP address) works on F23 with:
selinux-policy-3.13.1-158.21.fc23.noarch
tor-0.2.7.6-5.fc23.x86_64

# egrep -v '^($|#)' /etc/tor/torrc 
ControlSocket /run/tor/control
ControlSocketsGroupWritable 1
CookieAuthentication 1
CookieAuthFile /run/tor/control.authcookie
CookieAuthFileGroupReadable 1
SOCKSPort myextip:9050
SOCKSPolicy accept mylan
SOCKSPolicy reject *
ORPort 9001
OutboundBindAddress myextip
Nickname doumeki
RelayBandwidthRate 1024 KB
RelayBandwidthBurst 2048 KB
ContactInfo tor * mydomain
DirPort 9030
ExitPolicy reject *:*
Comment 10 Dominik 'Rathann' Mierzejewski 2016-08-19 19:15:53 EDT
This might be caused by this change in selinux-policy in F24 which was not backported to F23:

* Mon Dec 07 2015 Miroslav Grepl <mgrepl@redhat.com> 3.13.1-162
[...]
- init_t domain should be running without unconfined_domain attribute.
Comment 11 Jamie Nguyen 2016-08-21 14:37:07 EDT
On F24 with default Tor package, I get these denials:


type=AVC msg=audit(1471804274.144:288): avc:  denied  { mounton } for  pid=15785 comm="(tor)" path="/run/tor" dev="tmpfs" ino=20803 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:tor_var_run_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1471804274.145:289): avc:  denied  { mounton } for  pid=15785 comm="(tor)" path="/var/lib/tor" dev="dm-0" ino=1574597 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:tor_var_lib_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1471804274.145:290): avc:  denied  { mounton } for  pid=15785 comm="(tor)" path="/var/log/tor" dev="dm-0" ino=68992409 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:tor_var_log_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1471804335.896:301): avc:  denied  { mounton } for  pid=17490 comm="(tor)" path="/run/tor" dev="tmpfs" ino=20803 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:tor_var_run_t:s0 tclass=dir permissive=1
Comment 12 Jamie Nguyen 2016-08-22 02:08:31 EDT
Also, I can confirm that Tor works as expected after installing the module created by audit2allow from the logs in comment #11
Comment 13 Paul DeStefano 2016-08-22 04:03:20 EDT
This bug is affecting the current version, not just rawhide.  Maybe this should be filed against F24.  Service has been down for a week due to this unsuspected bug in current version.

(This is very confusing for me since sealert didn't notify me of these AVCs, but that maybe a separate thing.)

Just wanted to add my specific data points: 
1) selinux-policy 3.13.1-191.8.fc24 works for Tor
2) selinux-policy 3.13.1-191.10.fc24 doesn't work for Tor
3) selinux-policy 3.13.1-191.12.fc24 doesn't work for Tor
Comment 14 Michael Scherer 2016-08-24 10:43:16 EDT
*** Bug 1369510 has been marked as a duplicate of this bug. ***
Comment 15 Paul DeStefano 2016-08-27 19:04:16 EDT
selinux-policy-3.13.1-191.13.fc24 also doesn't work for Tor
Comment 16 Andrea 2016-08-29 16:42:47 EDT
Not sure.

I still get the selinux notice, but tor works now.

Quick question? I generated (only once) a local policy module as suggested.
Is this permanent or temporary?
Is this the reason why it works now?


Linux is preventing (tor) from mounton access on the directory /var/log/tor.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that (tor) should be allowed mounton access on the tor directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c '(tor)' --raw | audit2allow -M my-tor
# semodule -X 300 -i my-tor.pp

Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:tor_var_log_t:s0
Target Objects                /var/log/tor [ dir ]
Source                        (tor)
Source Path                   (tor)
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           
Target RPM Packages           tor-0.2.7.6-6.fc24.x86_64
Policy RPM                    selinux-policy-3.13.1-191.13.fc24.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 4.6.7-300.fc24.x86_64
                              #1 SMP Wed Aug 17 18:48:43 UTC 2016 x86_64 x86_64
Alert Count                   8
First Seen                    2016-08-14 15:09:28 BST
Last Seen                     2016-08-29 21:39:39 BST
Local ID                      615b50d9-29ec-49ba-bfa9-5df86f0ae91b

Raw Audit Messages
type=AVC msg=audit(1472503179.501:426): avc:  denied  { mounton } for  pid=7843 comm="(tor)" path="/var/log/tor" dev="dm-0" ino=786825 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:tor_var_log_t:s0 tclass=dir permissive=0


Hash: (tor),init_t,tor_var_log_t,dir,mounton
Comment 17 srakitnican 2016-08-30 10:07:22 EDT
(In reply to Andrea from comment #16)

> Quick question? I generated (only once) a local policy module as suggested.
> Is this permanent or temporary?
Not if you did not add it. By adding it makes it permanent. Also, messages should not be generated anymore since it is allowed.
> Is this the reason why it works now?
I don't know if it works or have worked before, I installed it once to try it and lost interest. All I know is that this messages should not appear. Either tor is trying to access something it shouldn't or default selinux-policy should allow it.

> # ausearch -c '(tor)' --raw | audit2allow -M my-tor
Generates selinux module named my-tor.pp in current directory
> # semodule -X 300 -i my-tor.pp
Adds module to system

To list all included modules use semodule -l, for example:
# semodule -l | grep my-tor
Comment 18 Ed Marshall 2016-09-01 19:51:31 EDT
See also bug 1369584; this is definitely affecting Fedora 24 as well.
Comment 19 Andrea 2016-09-02 10:07:13 EDT
(In reply to srakitnican from comment #17)
> (In reply to Andrea from comment #16)
> 
> > Quick question? I generated (only once) a local policy module as suggested.
> > Is this permanent or temporary?
> Not if you did not add it. By adding it makes it permanent. Also, messages
> should not be generated anymore since it is allowed.
> > Is this the reason why it works now?
> I don't know if it works or have worked before, I installed it once to try
> it and lost interest. All I know is that this messages should not appear.
> Either tor is trying to access something it shouldn't or default
> selinux-policy should allow it.
> 
> > # ausearch -c '(tor)' --raw | audit2allow -M my-tor
> Generates selinux module named my-tor.pp in current directory
> > # semodule -X 300 -i my-tor.pp
> Adds module to system
> 
> To list all included modules use semodule -l, for example:
> # semodule -l | grep my-tor

Ok, this explains why it works for me now.
I added and made it permanent.
Comment 20 Michael Scherer 2016-09-25 06:47:56 EDT
*** Bug 1374668 has been marked as a duplicate of this bug. ***
Comment 21 Michael Scherer 2016-09-25 06:48:00 EDT
*** Bug 1369584 has been marked as a duplicate of this bug. ***
Comment 22 Michael Scherer 2016-09-25 06:48:14 EDT
*** Bug 1370967 has been marked as a duplicate of this bug. ***
Comment 23 Michael Scherer 2016-09-25 07:01:23 EDT
So I proposed https://github.com/fedora-selinux/selinux-policy/pull/156 (for F24, but the same should be pushed to F25), after finding https://bugzilla.redhat.com/show_bug.cgi?id=1368621
Comment 24 Michael Scherer 2016-10-02 14:08:48 EDT
*** Bug 1366967 has been marked as a duplicate of this bug. ***
Comment 25 Paul DeStefano 2016-10-02 14:10:18 EDT
*** Bug 1333969 has been marked as a duplicate of this bug. ***
Comment 26 Michael Scherer 2016-10-02 15:16:26 EDT
*** Bug 1375979 has been marked as a duplicate of this bug. ***
Comment 27 Michael Scherer 2016-10-02 15:19:24 EDT
Reassigning to lvrabec, since he is now the selinux czar according to pkgdb
Comment 28 Michael Scherer 2016-10-04 03:19:26 EDT
*** Bug 1379792 has been marked as a duplicate of this bug. ***
Comment 29 xzj8b3 2016-10-27 16:24:16 EDT
Description of problem:
Tor does not connect, continuing problems encountered already from Fedora 23
 

Version-Release number of selected component:
selinux-policy-3.13.1-191.19.fc24.noarch

Additional info:
reporter:       libreport-2.7.2
hashmarkername: setroubleshoot
kernel:         4.7.9-200.fc24.x86_64
type:           libreport
Comment 30 Juan Orti 2016-10-27 17:01:59 EDT
Another workaround is to edit the service file with:

# systemctl edit --full tor.service

and remove all:

ReadOnlyDirectories=xxx
ReadWriteDirectories=xxx

Leaving only these directives:

ProtectHome=yes
ProtectSystem=full
Comment 31 Paul DeStefano 2016-10-29 19:36:42 EDT
(In reply to Juan Orti from comment #30)
> Another workaround is to edit the service file with:
> 
> # systemctl edit --full tor.service
> 
> and remove all:
> 
> ReadOnlyDirectories=xxx
> ReadWriteDirectories=xxx
> 
> Leaving only these directives:
> 
> ProtectHome=yes
> ProtectSystem=full

Hmm, is this sustainable?  I honestly don't know.  That sounds like something managed by fedora too.

If this is a good solution, then this should be considered for the tor package itself.

I don't understand how this was broken in stable versions.
Comment 32 Saurabh Sharma 2016-10-30 09:43:40 EDT
Description of problem:
I'm simply restarted the TOR service by,
sudo systemctl restart tor

I would appreciate if this could get fixed.

Version-Release number of selected component:
selinux-policy-3.13.1-191.19.fc24.noarch

Additional info:
reporter:       libreport-2.7.2
hashmarkername: setroubleshoot
kernel:         4.7.9-200.fc24.x86_64
type:           libreport
Comment 33 Lukas Vrabec 2016-10-30 10:42:59 EDT
This issue is fixed in our github repo. Will be fixed in next Fedora Update.
Comment 34 Saurabh Sharma 2016-10-30 17:46:51 EDT
Thanks!
Comment 35 Gwyn Ciesla 2016-11-03 11:48:29 EDT
Please make sure this gets to f24, and f23 if it's broken there.
Comment 36 Fedora Update System 2016-11-04 08:13:07 EDT
selinux-policy-3.13.1-191.20.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-7ce27629b3
Comment 37 Fedora Update System 2016-11-04 23:37:09 EDT
selinux-policy-3.13.1-191.20.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7ce27629b3
Comment 38 Lorenzo Pistone 2016-11-09 05:22:36 EST
*** Bug 1393315 has been marked as a duplicate of this bug. ***
Comment 39 Fedora Update System 2016-11-09 22:30:40 EST
selinux-policy-3.13.1-191.20.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
Comment 40 Gwyn Ciesla 2016-11-10 08:43:37 EST
selinux-policy-3.13.1-191.20.fc24 doesn't fix this for me:

Nov 10 07:41:34 bamboo kernel: audit: type=1400 audit(1478785294.195:3327746): avc:  denied  { dac_override } for  pid=15958 comm="tor" capability=1  scontext=system_u:
Nov 10 07:41:34 bamboo kernel: audit: type=1400 audit(1478785294.195:3327746): avc:  denied  { dac_read_search } for  pid=15958 comm="tor" capability=2  scontext=system
Nov 10 07:41:34 bamboo kernel: audit: type=1300 audit(1478785294.195:3327746): arch=c000003e syscall=2 success=no exit=-13 a0=55754a590790 a1=20000 a2=0 a3=20 items=0 p
N
Comment 41 Joseph D. Wagner 2016-11-11 12:47:11 EST
dac_override and dac_read_search errors were not reported anywhere in this bug, or in any of the related bugs.

I do not get those errors when I start tor, and neither did any of the other half dozen people who signed off on the fix in QA.

I recommend this bug report be closed, and the dac_override and dac_read_search issues be looked into on a separate ticket.
Comment 43 Joseph D. Wagner 2016-11-11 14:37:36 EST
That helps. From the bug description, it sounds like your issue impacts tor ONLY IF the user is offering tor services, not simply by using tor for browsing.

This ticket (and related) was about not being able to use tor at all, whereas yours is a more narrow use case. If you look closely at bodhi, this fix never claimed to solve bug 1392187 or the use case around it.  Hence, this fix actually fixed the problem is was claiming to fix, but nothing more.

I suggest closing this bug, since tor is working from a browsing use case, and you diagnose and fix tor services on bug 1392187.
Comment 44 deadrat 2016-11-21 19:54:27 EST
Description of problem:
unable to run tor service

Version-Release number of selected component:
selinux-policy-3.13.1-191.19.fc24.noarch

Additional info:
reporter:       libreport-2.7.2
hashmarkername: setroubleshoot
kernel:         4.8.4-200.fc24.x86_64
type:           libreport
Comment 45 deadrat 2016-11-21 19:55:56 EST
Description of problem:
unable to start tor service

Version-Release number of selected component:
selinux-policy-3.13.1-191.19.fc24.noarch

Additional info:
reporter:       libreport-2.7.2
hashmarkername: setroubleshoot
kernel:         4.8.4-200.fc24.x86_64
type:           libreport
Comment 46 Fedora End Of Life 2017-07-25 17:51:15 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 47 Gwyn Ciesla 2017-07-26 08:37:18 EDT
Fixed in f25+

https://bugzilla.redhat.com/show_bug.cgi?id=1375369#c32
Comment 48 M. Scherer 2017-08-08 11:00:47 EDT
I do see this is fixed indeed on my server, so closing.
Comment 49 Fedora End Of Life 2017-08-08 11:39:53 EDT
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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