Bug 975817
Summary: | SELinux is preventing /usr/sbin/ntop from 'read' accesses on the chr_file usbmon11. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | W Agtail <crash70> |
Component: | ntop | Assignee: | Marcelo Barbosa "firemanxbr" <marcelo.barbosa> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | dominick.grift, dwalsh, lvrabec, martin, mgrepl, sven |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Unspecified | ||
Whiteboard: | abrt_hash:ce0ef0d6168155e7b6f656ccae36ac02d5abade1f7665fe8396cc7db426fa21a | ||
Fixed In Version: | selinux-policy-3.12.1-57.fc19 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-02-18 13:57:07 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
W Agtail
2013-06-19 12:10:54 UTC
Should ntop be allowed to read usbmon_devices? /dev/usbmod* c76edd7b70fc4f585db0cafb45673a61fc1b65e5 allows this in git. selinux-policy-3.12.1-54.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-54.fc19 Package selinux-policy-3.12.1-54.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-54.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11355/selinux-policy-3.12.1-54.fc19 then log in and leave karma (feedback). Hi and thanks you. The new version of selinux-policy has cleared the previous errors. ntop now fails with the following AVC: SELinux is preventing /usr/sbin/ntop from create access on the netlink_socket . ***** Plugin catchall (100. confidence) suggests *************************** If you believe that ntop should be allowed create access on the netlink_socket 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: # grep ntop /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:ntop_t:s0 Target Context system_u:system_r:ntop_t:s0 Target Objects [ netlink_socket ] Source ntop Source Path /usr/sbin/ntop Port <Unknown> Host f19 Source RPM Packages ntop-5.0-6.fc19.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-54.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name f19 Platform Linux eagle.home.com 3.9.6-301.fc19.x86_64 #1 SMP Mon Jun 17 14:26:26 UTC 2013 x86_64 x86_64 Alert Count 2 First Seen 2013-06-19 12:55:14 BST Last Seen 2013-06-21 10:22:20 BST Local ID a5a3849d-4dc6-4e45-859c-e65395c6ea03 Raw Audit Messages type=AVC msg=audit(1371806540.180:11874): avc: denied { create } for pid=2394 comm="ntop" scontext=system_u:system_r:ntop_t:s0 tcontext=system_u:system_r:ntop_t:s0 tclass=netlink_socket type=SYSCALL msg=audit(1371806540.180:11874): arch=x86_64 syscall=socket success=no exit=EACCES a0=10 a1=3 a2=c a3=a items=0 ppid=1 pid=2394 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=ntop exe=/usr/sbin/ntop subj=system_u:system_r:ntop_t:s0 key=(null) Hash: ntop,ntop_t,ntop_t,netlink_socket,create selinux-policy-3.12.1-54.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. Hi, re: comment 5. I have installed selinux-policy-3.12.1-54.fc19 and ntop still fails to start. selinux-policy-3.12.1-57.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-57.fc19 Package selinux-policy-3.12.1-57.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-57.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 then log in and leave karma (feedback). I have applied selinux-policy-3.12.1-57.fc19 and ntop fails to start with the following. SELinux is preventing /usr/sbin/ntop from using the dac_override capability. ***** Plugin dac_override (91.4 confidence) suggests *********************** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. ***** Plugin catchall (9.59 confidence) suggests *************************** If you believe that ntop should have the dac_override capability 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: # grep ntop /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:ntop_t:s0 Target Context system_u:system_r:ntop_t:s0 Target Objects [ capability ] Source ntop Source Path /usr/sbin/ntop Port <Unknown> Host f19 Source RPM Packages ntop-5.0-6.fc19.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-57.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name f19 Platform Linux f19 3.9.6-301.fc19.x86_64 #1 SMP Mon Jun 17 14:26:26 UTC 2013 x86_64 x86_64 Alert Count 9 First Seen 2013-06-19 12:55:14 BST Last Seen 2013-06-30 19:51:20 BST Local ID 51a9ef80-3148-4a65-bdbb-ad3d4b65f7d7 Raw Audit Messages type=AVC msg=audit(1372618280.1:45482): avc: denied { dac_override } for pid=17976 comm="ntop" capability=1 scontext=system_u:system_r:ntop_t:s0 tcontext=system_u:system_r:ntop_t:s0 tclass=capability type=SYSCALL msg=audit(1372618280.1:45482): arch=x86_64 syscall=open success=no exit=EACCES a0=7f2ebd367320 a1=42 a2=1a0 a3=1 items=0 ppid=1 pid=17976 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=ntop exe=/usr/sbin/ntop subj=system_u:system_r:ntop_t:s0 key=(null) Hash: ntop,ntop_t,ntop_t,capability,dac_override Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. ausearch shows the following.
> ausearch -m avc -ts recent
----
time->Mon Jul 1 12:41:13 2013
type=PATH msg=audit(1372678873.489:52695): item=0 name="/var/lib/ntop/" inode=521098 dev=fd:08 mode=040755 ouid=394 ogid=393 rdev=00:00 obj=system_u:object_r:ntop_var_lib_t:s0
type=CWD msg=audit(1372678873.489:52695): cwd="/"
type=SYSCALL msg=audit(1372678873.489:52695): arch=c000003e syscall=2 success=no exit=-13 a0=7f585ba94c10 a1=42 a2=1a0 a3=1 items=1 ppid=1 pid=17211 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="ntop" exe="/usr/sbin/ntop" subj=system_u:system_r:ntop_t:s0 key=(null)
type=AVC msg=audit(1372678873.489:52695): avc: denied { dac_override } for pid=17211 comm="ntop" capability=1 scontext=system_u:system_r:ntop_t:s0 tcontext=system_u:system_r:ntop_t:s0 tclass=capability
This means ntop is running as UID0 and trying to read content inside of /var/lib/ntop directory, which is not allowed for the UID=0 user using standard permission flags. I take it ntop is trying to write to this directory. The problem might be that ntop is not running as the ntop user? Yes, I am using the default ntop.conf file which includes: more /etc/ntop.conf # tells ntop the user id to run as --user ntop So this avc indicates that ntop is running as root and trying to access /var/lib/ntop? Could the ntop packages tell me if this is just a case of ntop not changing it UID before trying to access the directory? selinux-policy-3.12.1-57.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. Re comments 13,14 & 15. I have installed selinux-policy as shown: > rpm -q selinux-policy selinux-policy-3.12.1-57.fc19.noarch ntop does not start due to selinux: ELinux is preventing /usr/sbin/ntop from using the dac_override capability. ***** Plugin dac_override (91.4 confidence) suggests *********************** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. ***** Plugin catchall (9.59 confidence) suggests *************************** If you believe that ntop should have the dac_override capability 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: # grep ntop /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:ntop_t:s0 Target Context system_u:system_r:ntop_t:s0 Target Objects /var/lib/ntop/ [ capability ] Source ntop Source Path /usr/sbin/ntop Port <Unknown> Host f19 Source RPM Packages ntop-5.0-6.fc19.x86_64 Target RPM Packages ntop-5.0-6.fc19.x86_64 Policy RPM selinux-policy-3.12.1-57.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name f19 Platform Linux f19 3.9.6-301.fc19.x86_64 #1 SMP Mon Jun 17 14:26:26 UTC 2013 x86_64 x86_64 Alert Count 19 First Seen 2013-06-19 12:55:14 BST Last Seen 2013-07-04 13:24:31 BST Local ID 51a9ef80-3148-4a65-bdbb-ad3d4b65f7d7 Raw Audit Messages type=AVC msg=audit(1372940671.958:73568): avc: denied { dac_override } for pid=10518 comm="ntop" capability=1 scontext=system_u:system_r:ntop_t:s0 tcontext=system_u:system_r:ntop_t:s0 tclass=capability type=SYSCALL msg=audit(1372940671.958:73568): arch=x86_64 syscall=open success=no exit=EACCES a0=7f9aabcca320 a1=42 a2=1a0 a3=1 items=1 ppid=1 pid=10518 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=ntop exe=/usr/sbin/ntop subj=system_u:system_r:ntop_t:s0 key=(null) type=CWD msg=audit(1372940671.958:73568): cwd=/ type=PATH msg=audit(1372940671.958:73568): item=0 name=/var/lib/ntop/ inode=521098 dev=fd:08 mode=040755 ouid=394 ogid=393 rdev=00:00 obj=system_u:object_r:ntop_var_lib_t:s0 Hash: ntop,ntop_t,ntop_t,capability,dac_override This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. I'm not sure when this selinux prevention started to happen: SELinux is preventing /usr/sbin/ntop from using the execmem access on a process. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that ntop should be allowed execmem access on processes labeled ntop_t 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: # grep ntop /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:ntop_t:s0 Target Context system_u:system_r:ntop_t:s0 Target Objects [ process ] Source ntop Source Path /usr/sbin/ntop Port <Unknown> Host f19 Source RPM Packages ntop-5.0-6.fc19.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-74.17.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name f19 Platform Linux f19 3.12.8-200.fc19.x86_64 #1 SMP Thu Jan 16 04:18:11 UTC 2014 x86_64 x86_64 Alert Count 47 First Seen 2014-01-19 13:20:23 GMT Last Seen 2014-02-01 18:58:38 GMT Local ID e1559e6d-5a45-4bcb-b090-d6ddfc963929 Raw Audit Messages type=AVC msg=audit(1391281118.625:19738): avc: denied { execmem } for pid=3000 comm="ntop" scontext=system_u:system_r:ntop_t:s0 tcontext=system_u:system_r:ntop_t:s0 tclass=process type=SYSCALL msg=audit(1391281118.625:19738): arch=x86_64 syscall=mmap success=no exit=EACCES a0=7f3f5b639000 a1=28000 a2=7 a3=812 items=0 ppid=1 pid=3000 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=ntop exe=/usr/sbin/ntop subj=system_u:system_r:ntop_t:s0 key=(null) Hash: ntop,ntop_t,ntop_t,process,execmem hi, any update on this one? many thanks I just tried to start ntop service and I get the following SElinux alert: SELinux is preventing /usr/sbin/ntop from read access on the chr_file random. ***** Plugin catchall_boolean (89.3 confidence) suggests ******************* If you want to allow users to resolve user passwd entries directly from ldap rather then using a sssd server Then you must tell SELinux about this by enabling the 'authlogin_nsswitch_use_ldap' boolean. You can read 'None' man page for more details. Do setsebool -P authlogin_nsswitch_use_ldap 1 ***** Plugin catchall (11.6 confidence) suggests *************************** If you believe that ntop should be allowed read access on the random chr_file 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: # grep ntop /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:ntop_t:s0 Target Context system_u:object_r:random_device_t:s0 Target Objects random [ chr_file ] Source ntop Source Path /usr/sbin/ntop Port <Unknown> Host jackstraw.homenet192-10.com Source RPM Packages ntop-5.0-6.fc19.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-74.19.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name jackstraw.homenet192-10.com Platform Linux jackstraw.homenet192-10.com 3.14.4-100.fc19.x86_64 #1 SMP Tue May 13 15:00:26 UTC 2014 x86_64 x86_64 Alert Count 1 First Seen 2014-06-10 10:44:12 PDT Last Seen 2014-06-10 10:44:12 PDT Local ID 6cb904b6-bdcf-4241-9581-2c350e863bc5 Raw Audit Messages type=AVC msg=audit(1402422252.498:29449): avc: denied { read } for pid=31892 comm="ntop" name="random" dev="devtmpfs" ino=1032 scontext=system_u:system_r:ntop_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1402422252.498:29449): arch=x86_64 syscall=open success=no exit=EACCES a0=7f85af1e765b a1=900 a2=fffffffffffffff3 a3=7fffd17eed80 items=0 ppid=1 pid=31892 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=ntop exe=/usr/sbin/ntop subj=system_u:system_r:ntop_t:s0 key=(null) Hash: ntop,ntop_t,random_device_t,chr_file,read I do not use ldap. I'm running F19 with latest updates Note also the following in the above alert: You can read 'None' man page for more details. There are no details in the 'None' man page. According to the 'None' manpage: This man page mentions those library functions which are implemented in the standard libraries but not yet documented in man pages. I assume the 'None' man page in the alert should refer to some real man page? Paolo (In reply to pgaltieri from comment #21) > I just tried to start ntop service and I get the following SElinux alert I get the same behaviour. # uname -a Linux XXX 3.14.2-200.fc20.x86_64 #1 SMP Mon Apr 28 14:40:57 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # rpm -q ntop selinux-policy ntop-5.0-7.fc20.x86_64 selinux-policy-3.12.1-177.fc20.noarch (In reply to Martin Dengler from comment #22) > (In reply to pgaltieri from comment #21) > > I just tried to start ntop service and I get the following SElinux alert > > I get the same behaviour. ...iff I add a non-localhost https listening port to /etc/ntop.conf: # limit ntop to listening on a specific interface and port --https-server my.ip.address:3001 ...and then try to connect to it. Incidentally, the connection doesn't work -- the connection succeeds but is dropped quickly: $ echo "GET / HTTP/1.0" | nc -v my.ip.address 3001 Ncat: Version 6.45 ( http://nmap.org/ncat ) Ncat: Connected to my.ip.address:3001. Ncat: Connection reset by peer. An http server endpoint seems to work alright: --http-server my.ip.address:3000 [Apologies for the double-update. I only noticed this after I had replied] You are just attaching randomother bugs to an exising bugs, if the signature of the problem is not the same please open other bugs. This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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. Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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. |