Bug 1357395
| Summary: | Couple of SELinux alerts for Tor | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | srakitnican <samuel.rakitnican> |
| Component: | selinux-policy-targeted | Assignee: | Lukas Vrabec <lvrabec> |
| Status: | CLOSED EOL | QA Contact: | Ben Levenson <benl> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 24 | CC: | blaffablaffa, dominik, dwalsh, error, esm, fedora.243908, fedora, fukidid, ga25day, guillaumepoiriermorency, gwync, jamielinux, jayabharat, jeff.raber, jfrieben, joe, jorti, lewk, lmacken, lsm5, mariofutire, mephi42, mgrepl, misc, mscherer, prd-fedora, pwouters, saurabhpysharma, somlo, s, vedran, xzj8b3 |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-08 15:39:53 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
$ rpm -q tor selinux-policy tor-0.2.7.6-6.fc24.x86_64 selinux-policy-3.13.1-202.fc25.noarch 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. 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. (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 This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'. 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
There are more than 1 directories with this problem I got alerts for /run/tor /var/lib/tor /var/log/tor 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
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 *:* 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> 3.13.1-162 [...] - init_t domain should be running without unconfined_domain attribute. 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
Also, I can confirm that Tor works as expected after installing the module created by audit2allow from the logs in comment #11 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 *** Bug 1369510 has been marked as a duplicate of this bug. *** selinux-policy-3.13.1-191.13.fc24 also doesn't work for Tor 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
(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 See also bug 1369584; this is definitely affecting Fedora 24 as well. (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. *** Bug 1374668 has been marked as a duplicate of this bug. *** *** Bug 1369584 has been marked as a duplicate of this bug. *** *** Bug 1370967 has been marked as a duplicate of this bug. *** 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 *** Bug 1366967 has been marked as a duplicate of this bug. *** *** Bug 1333969 has been marked as a duplicate of this bug. *** *** Bug 1375979 has been marked as a duplicate of this bug. *** Reassigning to lvrabec, since he is now the selinux czar according to pkgdb *** Bug 1379792 has been marked as a duplicate of this bug. *** 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 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 (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. 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 This issue is fixed in our github repo. Will be fixed in next Fedora Update. Thanks! Please make sure this gets to f24, and f23 if it's broken there. 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 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 *** Bug 1393315 has been marked as a duplicate of this bug. *** 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. 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
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. 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. 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 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 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. Fixed in f25+ https://bugzilla.redhat.com/show_bug.cgi?id=1375369#c32 I do see this is fixed indeed on my server, so closing. 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. |
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).