Bug 1054337 (net_admin) - SELinux is preventing lots of random domains the 'net_admin' capabilities.
Summary: SELinux is preventing lots of random domains the 'net_admin' capabilities.
Keywords:
Status: CLOSED CANTFIX
Alias: net_admin
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:6c71b6ffe50b9cedb1ef3ac8c69...
: 1054358 1054444 1054468 1054828 1055897 (view as bug list)
Depends On:
Blocks: 1054468
TreeView+ depends on / blocked
 
Reported: 2014-01-16 16:20 UTC by Dario Castellarin
Modified: 2014-09-13 18:58 UTC (History)
63 users (show)

Fixed In Version: selinux-policy-3.12.1-122.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-05 18:20:50 UTC
Type: ---


Attachments (Terms of Use)

Description Dario Castellarin 2014-01-16 16:20:35 UTC
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

Comment 1 Daniel Walsh 2014-01-16 20:16:45 UTC
*** Bug 1054358 has been marked as a duplicate of this bug. ***

Comment 2 Victor Costan 2014-01-19 06:01:09 UTC
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

Comment 3 Miroslav Grepl 2014-01-21 14:31:14 UTC
*** Bug 1055897 has been marked as a duplicate of this bug. ***

Comment 4 Daniel Walsh 2014-01-21 15:26:02 UTC
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

Comment 5 Daniel Walsh 2014-01-21 15:29:52 UTC
*** Bug 1054468 has been marked as a duplicate of this bug. ***

Comment 6 Daniel Walsh 2014-01-21 15:30:53 UTC
*** Bug 1054828 has been marked as a duplicate of this bug. ***

Comment 7 Paul Moore 2014-01-21 16:00:59 UTC
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.

Comment 8 Paul Moore 2014-01-21 16:17:22 UTC
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

Comment 9 Paul Moore 2014-01-21 16:31:47 UTC
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.

Comment 10 Daniel Walsh 2014-01-21 16:59:35 UTC
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

Comment 11 Paul Moore 2014-01-21 17:34:14 UTC
(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.

Comment 12 Eric Paris 2014-01-21 17:57:10 UTC
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...

Comment 13 Paul Moore 2014-01-21 18:20:50 UTC
(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?

Comment 14 Carlos O'Donell 2014-01-22 03:46:22 UTC
(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.

Comment 15 Eric Paris 2014-01-22 03:53:22 UTC
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...

Comment 16 Paul Moore 2014-01-22 14:10:00 UTC
(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 ...

Comment 17 Lennart Poettering 2014-01-23 13:11:15 UTC
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.

Comment 18 Daniel Walsh 2014-01-24 17:01:40 UTC
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.

Comment 19 Daniel Walsh 2014-01-24 17:05:27 UTC
741013dc97c6030dbe8da64475de22f22b401175 allows systemd_tmpfiles_t to net_admin in git.

24e035f076e0b59e825194448a889ea812a1c12f adds dontaudit for this on setroubleshoot and abrt.

Comment 20 Jakub Filak 2014-01-26 12:31:48 UTC
*** Bug 1054444 has been marked as a duplicate of this bug. ***

Comment 21 Fedora Update System 2014-01-27 19:16:22 UTC
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

Comment 22 Mukundan Ragavan 2014-01-28 14:17:54 UTC
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

Comment 23 Adam Williamson 2014-01-28 20:04:36 UTC
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.

Comment 24 Fedora Update System 2014-01-29 03:06:32 UTC
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).

Comment 25 Fedora Update System 2014-01-30 03:32:35 UTC
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).

Comment 26 Fedora Update System 2014-02-12 14:44:26 UTC
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.

Comment 27 Moez Roy 2014-03-03 13:37:47 UTC
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

Comment 28 Zbigniew Jędrzejewski-Szmek 2014-03-03 13:53:06 UTC
(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...

Comment 29 Daniel Walsh 2014-03-03 16:22:09 UTC
Just checked into git dontaudits for all systemd domains and for dbus domains.

Comment 30 drewwalton19216801 2014-03-18 18:21:36 UTC
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

Comment 31 foglets 2014-03-25 18:37:25 UTC
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

Comment 32 alexey.kurinnij 2014-03-25 21:36:10 UTC
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

Comment 33 nadersalehi1 2014-03-30 23:22:59 UTC
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

Comment 34 nadersalehi1 2014-03-30 23:23:57 UTC
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

Comment 35 wes 2014-04-10 14:34:47 UTC
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

Comment 36 Raphaël Flores 2014-04-14 13:46:13 UTC
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

Comment 37 Daniel Walsh 2014-04-14 16:04:27 UTC
Does this happen any longer, it it probably just an upgrade problem where systemd gets updated before the selinux-policy.

Comment 38 Raphaël Flores 2014-04-14 20:49:26 UTC
Right. Happen only once during the upgrade, not reproducible thought.

Comment 39 Majid 2014-04-16 02:20:15 UTC
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

Comment 40 Daniel Walsh 2014-04-24 01:40:29 UTC
Majid I don't think this is related to this bug.

Comment 41 aj12gamer 2014-05-02 20:18:49 UTC
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

Comment 42 Daniel Walsh 2014-05-03 10:28:09 UTC
Did you update to the latest policy?  Might just be an update problem.

Comment 43 Christopher Meng 2014-05-05 10:04:52 UTC
I don't see this issue now, it's an update problem.


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