Bug 1054337 (net_admin)
| Summary: | SELinux is preventing lots of random domains the 'net_admin' capabilities. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dario Castellarin <req1348> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | aj12gamer, akurtako, alexey.kurinnij, alok96, awilliam, boltunov.artyom, bugzilla, claudius.ellsel, codonell, costan, dario.cangialosi, djboygame, dominick.grift, drewwalton19216801, dwalsh, edosurina, eparis, fidelleon, foglets, gansalmon, ignatenko, itamar, jakub, jfrieben, johannbg, jonathan, keramidasceid, kernel-maint, law, lnykryn, luisgandrade1, luya, lvrabec, madhu.chinakonda, metherid, mgrepl, mikhail.v.gavrilov, moez.roy, msekleta, nadersalehi1, nicolas.mailhot, nonamedotc, omkar.patekar, paul, pfrankli, plautrba, pmoore, raf64flo, rafiee11, rrrcoo, sangu.fedora, sanjay.ankur, sdsmall, spoyarek, systemd-maint, thomas.mey, tmokros, verkhovin13, vpavlin, wes, wmorri, xinspacex, zbyszek |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | abrt_hash:6c71b6ffe50b9cedb1ef3ac8c69a44c1a0af7dac71d64db9c2a5d7ac4a14d96d | ||
| Fixed In Version: | selinux-policy-3.12.1-122.fc20 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-05-05 18:20:50 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1054468 | ||
*** Bug 1054358 has been marked as a duplicate of this bug. *** Description of problem: Not sure what happened here, but abrt should be able to do whatever it needs to do, right? Additional info: reporter: libreport-2.1.11 hashmarkername: setroubleshoot kernel: 3.12.7-300.fc20.x86_64 type: libreport *** Bug 1055897 has been marked as a duplicate of this bug. *** No abrt should not require net_admin privs, this priv allows apps to change the network stack, IP info, routing table ... This is a bug in the kernel or glibc on the setsockopt call *** Bug 1054468 has been marked as a duplicate of this bug. *** *** Bug 1054828 has been marked as a duplicate of this bug. *** While SELinux itself does not perform any CAP_NET_ADMIN checks on the setsockopt(2) syscall, or any other LSM hook for that matter, there are a number of setsockopt(2) options that could cause the standard network stack to perform a capability check which would of course filter down to SELinux to authorize the use of the capability. The source of the problem is likely a change in systemd and/or glibc which is now attempting to use a socket option which requires CAP_NET_ADMIN. Quick list of socket options requiring CAP_NET_ADMIN: * SOL_SOCKET / SO_DEBUG * SOL_SOCKET / SO_SNDBUFFORCE * SOL_SOCKET / SO_RCVBFFORCE * SOL_SOCKET / SO_PRIORITY * SOL_SOCKET / SO_MARK * SOL_SOCKET / SO_BUSY_POLL * IPPROTO_IP / IP_XFRM_POLICY * IPPROTO_IP / IP_TRANSPARENT * IPPROTO_IPV6 / IPV6_XFRM_POLICY * IPPROTO_IPV6 / IPV6_TRANSPARENT Looking quickly at the upstream systemd sources I see the following socket options are used, although I'm not sure what ends up being used by systemd-tmpfiles (the codebase is a bit complex): * SOL_SOCKET / SO_SNDBUFFORCE * SOL_SOCKET / SO_RCVBFFORCE * SOL_SOCKET / SO_PRIORITY * SOL_SOCKET / SO_MARK * IPPROTO_IP / IP_TRANSPARENT According to the AVC/SYSCALL audit record above, the offending setsockopt(2) call is the following: setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, ...); ... which doesn't make much sense given that it doesn't require CAP_NET_ADMIN and doesn't appear in the upstream systemd sources as far as I can tell (glibc?). It is very possible I'm misinterpreting the audit record. I am seeing similar issues with setroubleshootd and abrt, so I believe this is related to glibc and not systemd at all.
type=SYSCALL msg=audit(01/20/2014 12:49:25.085:6447) : arch=x86_64 syscall=sets
ockopt success=yes exit=0 a0=0x4 a1=SOL_SOCKET a2=SO_SNDBUFFORCE a3=0x7fff0c9ae
f90 items=0 ppid=706 pid=4645 auid=unset uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=abrt-server
exe=/usr/sbin/abrt-server subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(nu
ll)
type=AVC msg=audit(01/20/2014 12:49:25.085:6447) : avc: denied { net_admin } for pid=4645 comm=abrt-server capability=net_admin scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tclass=capability
(In reply to Daniel Walsh from comment #10) > I am seeing similar issues with setroubleshootd and abrt, so I believe this > is related to glibc and not systemd at all. Reassigning to glibc as they are likely best suited to investigate this further. If this does end up as a kernel/SELinux issue please go ahead and assign it back to me. This looks like 2 different bugs... comment #1: setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, ...); Paul claims (in comment #9) that this shouldn't require CAP_NET_ADMIN. However it is clear this was checked. This is a kernel bug. comment #10: setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, ...); Here it is expected that SO_SNDBUFFORCE would require CAP_NET_ADMIN. My guess, the abrt server was changed to use this. We'd need more bugs to better pin it down, but to me, we have a kernel bug and an abrt bug/selinux-policy bug... (In reply to Paul Moore from comment #9) > According to the AVC/SYSCALL audit record above, the offending setsockopt(2) > call is the following: > > setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, ...); > > ... which doesn't make much sense given that it doesn't require > CAP_NET_ADMIN and doesn't appear in the upstream systemd sources as far as I > can tell (glibc?). > > It is very possible I'm misinterpreting the audit record. I believe I may have misinterpreted the audit record, the original syscall audit record is shown as: type=SYSCALL msg=audit(1389888905.76:504): arch=x86_64 syscall=setsockopt success=yes exit=0 a0=3 a1=1 a2=20 a3=7fff58152df0 items=0 ppid=1 pid=2474 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=systemd-tmpfile exe=/usr/bin/systemd-tmpfiles subj=system_u:system_r:systemd_tmpfiles_t:s0 key=(null) ... which has "a0=3 a1=1 a2=20 a3=7fff58152df0"; I had assumed that "a2", the socket option name was in decimal when in reality it is listed in hexadecimal. With that in mind the offending setsockopt(2) call is the following: setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, ...); This matches up with the comment Dan posted in comment #10. Perhaps a glibc change? (In reply to Paul Moore from comment #13) > (In reply to Paul Moore from comment #9) > > According to the AVC/SYSCALL audit record above, the offending setsockopt(2) > > call is the following: > > > > setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, ...); > > > > ... which doesn't make much sense given that it doesn't require > > CAP_NET_ADMIN and doesn't appear in the upstream systemd sources as far as I > > can tell (glibc?). > > > > It is very possible I'm misinterpreting the audit record. > > I believe I may have misinterpreted the audit record, the original syscall > audit record is shown as: > > type=SYSCALL msg=audit(1389888905.76:504): arch=x86_64 syscall=setsockopt > success=yes exit=0 a0=3 a1=1 a2=20 a3=7fff58152df0 items=0 ppid=1 pid=2474 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > ses=4294967295 tty=(none) comm=systemd-tmpfile > exe=/usr/bin/systemd-tmpfiles > subj=system_u:system_r:systemd_tmpfiles_t:s0 key=(null) > > ... which has "a0=3 a1=1 a2=20 a3=7fff58152df0"; I had assumed that "a2", > the socket option name was in decimal when in reality it is listed in > hexadecimal. With that in mind the offending setsockopt(2) call is the > following: > > setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, ...); > > This matches up with the comment Dan posted in comment #10. Perhaps a glibc > change? We make no such call in glibc proper. The glibc setsockopt implementation on Linux is a direct pass through to the kernel. We have some setsockopt calls in the legacy RPC functions we provide aka. Sun RPC. However, none of that code has changed in a long time. We are actively migrating users away to other TI RPC infrastructures. If there is anything I can do to help, just ask, but I don't see this as being something new in glibc. Back to Paul. most of these are the result of an explicit change in systemd: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg15347.html doesn't answer abrt... (In reply to Eric Paris from comment #15) > most of these are the result of an explicit change in systemd: > > https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg15347. > html > > doesn't answer abrt... Agreed, I posted that link on IRC yesterday, but still wasn't convinced that was the source of the problem. However, considering the Carlos' comment #14 it sounds like this is likely a systemd problem. The reassigning continues ... Hmm, so what's the problem here? SO_SNDBUFFORCE is somethign we try, and we it succeeds we are happy. If it doesn't work we don't mind. The SELinux policy should probably allow this to go though. So we can dontaudit this for all domains that call journald directly? net_admin priv would allow these domains to mess around with the network/iptables. 741013dc97c6030dbe8da64475de22f22b401175 allows systemd_tmpfiles_t to net_admin in git. 24e035f076e0b59e825194448a889ea812a1c12f adds dontaudit for this on setroubleshoot and abrt. *** Bug 1054444 has been marked as a duplicate of this bug. *** selinux-policy-3.12.1-121.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-121.fc20 Description of problem: This problem still seems to persist with -121 on my system. Additional info: reporter: libreport-2.1.11 hashmarkername: setroubleshoot kernel: 3.12.9-300.fc20.x86_64 type: libreport I'm seeing this on Rawhide, and there hasn't been an updated Rawhide build AFAICS. Got two from my latest Rawhide build, with selinux-policy-targeted-3.13.1-18.fc21.noarch , one for abrtd, one for systemd-tmpfiles. Package selinux-policy-3.12.1-121.fc20: * should fix your issue, * was pushed to the Fedora 20 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-121.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-1700/selinux-policy-3.12.1-121.fc20 then log in and leave karma (feedback). Package selinux-policy-3.12.1-122.fc20: * should fix your issue, * was pushed to the Fedora 20 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-122.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-1700/selinux-policy-3.12.1-122.fc20 then log in and leave karma (feedback). selinux-policy-3.12.1-122.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. re-opening:
SELinux is preventing /usr/bin/systemd-tty-ask-password-agent from using the 'net_admin' capabilities.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that systemd-tty-ask-password-agent should have the net_admin 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 systemd-tty-ask /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:systemd_passwd_agent_t:s0
Target Context system_u:system_r:systemd_passwd_agent_t:s0
Target Objects [ capability ]
Source systemd-tty-ask
Source Path /usr/bin/systemd-tty-ask-password-agent
Port <Unknown>
Host (removed)
Source RPM Packages systemd-208-14.fc20.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.12.1-122.fc20.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name (removed)
Platform Linux (removed) 3.13.5-200.fc20.x86_64 #1 SMP Mon
Feb 24 16:51:35 UTC 2014 x86_64 x86_64
Alert Count 1
First Seen 2014-03-03 03:41:21 PST
Last Seen 2014-03-03 03:41:21 PST
Local ID ea25d032-c502-45a4-b617-c7847b4c5ff8
Raw Audit Messages
type=AVC msg=audit(1393846881.547:21): avc: denied { net_admin } for pid=776 comm="systemd-tty-ask" capability=12 scontext=system_u:system_r:systemd_passwd_agent_t:s0 tcontext=system_u:system_r:systemd_passwd_agent_t:s0 tclass=capability
type=SYSCALL msg=audit(1393846881.547:21): arch=x86_64 syscall=setsockopt success=no exit=EPERM a0=3 a1=1 a2=20 a3=7fffb703ee50 items=0 ppid=1 pid=776 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=systemd-tty-ask exe=/usr/bin/systemd-tty-ask-password-agent subj=system_u:system_r:systemd_passwd_agent_t:s0 key=(null)
Hash: systemd-tty-ask,systemd_passwd_agent_t,systemd_passwd_agent_t,capability,net_admin
(In reply to Daniel Walsh from comment #19) > 741013dc97c6030dbe8da64475de22f22b401175 allows systemd_tmpfiles_t to > net_admin in git. This seems wrong. systemd-tmpfiles should be treated the same as setroubleshoot and others. > 24e035f076e0b59e825194448a889ea812a1c12f adds dontaudit for this on > setroubleshoot and abrt. The problem is that pretty much any systemd binary will call this. If I'm reading the code correctly, this denial will also be triggered by code available as part of libsystemd-bus. It is not available yet (only with a special configure option), but once it's considered stable, it will be. So this issue could become common... Just checked into git dontaudits for all systemd domains and for dbus domains. Description of problem: This happened while running 'yum update' after a fresh F20 installation, though I have no way to know if they are related. Additional info: reporter: libreport-2.2.0 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport Description of problem: After I installed from DVD I ran #yum update Additional info: reporter: libreport-2.2.0 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport Description of problem: Empathy. Right click on jabber buddy in list and click to information - error Additional info: reporter: libreport-2.1.9 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport Description of problem: System crashed during by itself and rebooted. No specific instructions on how to reproduce the bug. Additional info: reporter: libreport-2.1.9 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport Description of problem: No instruction on how to reproduce the bug. Additional info: reporter: libreport-2.1.9 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport Description of problem: fresh install of fedora 20 from usb flash drive, using yumex to download and install all updates and SElinux msg came up... Additional info: reporter: libreport-2.2.1 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport Description of problem: Was upgrading distro from Fedora 19 to 20. Additional info: reporter: libreport-2.2.1 hashmarkername: setroubleshoot kernel: 3.13.9-100.fc19.x86_64 type: libreport Does this happen any longer, it it probably just an upgrade problem where systemd gets updated before the selinux-policy. Right. Happen only once during the upgrade, not reproducible thought. Description of problem: I tried to connect to my secured wifi, after several attempts, all the wifi networks gone. I can't conncet to any wifi network anymore ! Additional info: reporter: libreport-2.2.1 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport Majid I don't think this is related to this bug. Description of problem: I just "sudo yum update" then it gave me this bug report. Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport Did you update to the latest policy? Might just be an update problem. I don't see this issue now, it's an update problem. |
Description of problem: It happened when I restarted my home router, not sure if related. SELinux is preventing /usr/bin/systemd-tmpfiles from using the 'net_admin' capabilities. ***** Plugin catchall (100. confidence) suggests ************************** If si pensa che systemd-tmpfiles dovrebbe avere funzionalità net_admin in modo predefinito. Then si dovrebbe riportare il problema come bug. E' possibile generare un modulo di politica locale per consentire questo accesso. Do consentire questo accesso per il momento eseguendo: # grep systemd-tmpfile /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:systemd_tmpfiles_t:s0 Target Context system_u:system_r:systemd_tmpfiles_t:s0 Target Objects [ capability ] Source systemd-tmpfile Source Path /usr/bin/systemd-tmpfiles Port <Unknown> Host (removed) Source RPM Packages systemd-208-11.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-117.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 3.12.7-300.fc20.x86_64 #1 SMP Fri Jan 10 15:35:31 UTC 2014 x86_64 x86_64 Alert Count 1 First Seen 2014-01-16 17:15:05 CET Last Seen 2014-01-16 17:15:05 CET Local ID 2d950ac3-74f5-4b3a-9668-ab7a6ee1836d Raw Audit Messages type=AVC msg=audit(1389888905.76:504): avc: denied { net_admin } for pid=2474 comm="systemd-tmpfile" capability=12 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:system_r:systemd_tmpfiles_t:s0 tclass=capability type=SYSCALL msg=audit(1389888905.76:504): arch=x86_64 syscall=setsockopt success=yes exit=0 a0=3 a1=1 a2=20 a3=7fff58152df0 items=0 ppid=1 pid=2474 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=systemd-tmpfile exe=/usr/bin/systemd-tmpfiles subj=system_u:system_r:systemd_tmpfiles_t:s0 key=(null) Hash: systemd-tmpfile,systemd_tmpfiles_t,systemd_tmpfiles_t,capability,net_admin Additional info: reporter: libreport-2.1.11 hashmarkername: setroubleshoot kernel: 3.12.7-300.fc20.x86_64 type: libreport