Bug 455143 - SELinux is preventing nm-system-setti (NetworkManager_t) "read write" to socket (system_dbusd_t).
SELinux is preventing nm-system-setti (NetworkManager_t) "read write" to sock...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
8
i386 Linux
low Severity low
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-12 14:26 EDT by pete johnson
Modified: 2008-11-26 12:37 EST (History)
5 users (show)

See Also:
Fixed In Version: F8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-26 12:37:43 EST
Type: ---
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 pete johnson 2008-07-12 14:26:07 EDT
Description of problem:
SELinux denied access requested by nm-system-setti. It is not expected that this
access is required by nm-system-setti and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration of the
application is causing it to require additional access. 

host=hasina type=AVC msg=audit(1215869093.513:14): avc: denied { read write }
for pid=2290 comm="nm-system-setti" path="socket:[6550]" dev=sockfs ino=6550
scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023
tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=tcp_socket 

host=hasina type=SYSCALL msg=audit(1215869093.513:14): arch=40000003 syscall=11
success=yes exit=0 a0=897ccb0 a1=8974208 a2=896f008 a3=5c197c items=0 ppid=2289
pid=2290 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="nm-system-setti"
exe="/usr/sbin/nm-system-settings"
subj=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 key=(null) 

Version-Release number of selected component (if applicable):
NetworkManager-0.7.0-0.6.9.svn3675.fc8
selinux-policy-3.0.8-109.fc8

How reproducible: Error is not due to user action, but occurs after KDE has
initialized the desktop, and before I have a chance to explicitly start an
application.


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Orion Poplawski 2008-09-18 10:22:03 EDT
Still seen with NetworkManager-0.7.0-0.11.svn4022.fc8.  In permissive mode I see:

type=1400 audit(1221692156.699:5): avc:  denied  { read write } for  pid=2587 comm="nm-system-setti" path="socket:[9992]" dev=sockfs ino=9992 scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=tcp_socket
type=1400 audit(1221692227.217:6): avc:  denied  { read } for  pid=2583 comm="NetworkManager" name="dhclient-eth1.conf" dev=sda5 ino=982193 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:dhcp_etc_t:s0 tclass=file
type=1400 audit(1221692262.366:9): avc:  denied  { getattr } for  pid=3801 comm="NetworkManager" path="/etc/dhclient-eth1.conf" dev=sda5 ino=982193 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:dhcp_etc_t:s0 tclass=file
Comment 2 Daniel Walsh 2008-09-18 16:24:57 EDT
These are leaked file descriptors.

allow NetworkManager_t system_dbusd_t:tcp_socket { read write };

This is caused by a leak in pam_nssldap, I beleive.


allow NetworkManager_t dhcp_etc_t:file { read getattr };

This is caused by a leak in dhclient?
Comment 3 Orion Poplawski 2008-09-18 16:41:17 EDT
The first denial definitely causes problems though and NM will not bring up the default network - needed for nm-system-settings to communicate with NM over dbus?  I see:

Sep 18 14:39:18 cynosure NetworkManager: <WARN>  system_settings_get_unmanaged_devices_cb(): system_settings_get_unmanaged_devices_cb: Error getting unmanaged devices from the system settings service: (4) Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Sep 18 14:39:18 cynosure NetworkManager: <WARN>  list_connections_cb(): Couldn't retrieve connections: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken..


More context for the other two:

Sep 17 16:57:42 cynosure NetworkManager: <info>  (eth1): device state change: 5 -> 7
Sep 17 16:57:42 cynosure NetworkManager: <info>  Activation (eth1) Beginning DHCP transaction.
Sep 17 16:57:42 cynosure kernel: type=1400 audit(1221692262.362:8): avc:  denied  { read } for  pid=3801 comm="NetworkManager" name="dhclient-eth1.conf" dev=sda5 ino=982193 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:dhcp_etc_t:s0 tclass=file
Sep 17 16:57:42 cynosure kernel: type=1400 audit(1221692262.366:9): avc:  denied  { getattr } for  pid=3801 comm="NetworkManager" path="/etc/dhclient-eth1.conf" dev=sda5 ino=982193 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:dhcp_etc_t:s0 tclass=file
Sep 17 16:57:42 cynosure dhclient: Internet Systems Consortium DHCP Client V3.0.6-Fedora
Sep 17 16:57:42 cynosure dhclient: Copyright 2004-2007 Internet Systems Consortium.
Sep 17 16:57:42 cynosure dhclient: All rights reserved.
Sep 17 16:57:42 cynosure dhclient: For info, please visit http://www.isc.org/sw/dhcp/
Sep 17 16:57:42 cynosure dhclient:
Sep 17 16:57:42 cynosure dhclient: Listening on LPF/eth1/00:b0:d0:0d:f2:a3
Sep 17 16:57:42 cynosure dhclient: Sending on   LPF/eth1/00:b0:d0:0d:f2:a3
Sep 17 16:57:42 cynosure dhclient: Sending on   Socket/fallback
Sep 17 16:57:42 cynosure dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3
Sep 17 16:57:42 cynosure dhclient: DHCPOFFER from 192.168.0.8
Sep 17 16:57:42 cynosure dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Sep 17 16:57:42 cynosure dhclient: DHCPACK from 192.168.0.8
Sep 17 16:57:42 cynosure dhclient: bound to 192.168.0.72 -- renewal in 7160 seconds.
Sep 17 16:57:42 cynosure NetworkManager: <info>  dhclient started with pid 3852
Comment 4 Dan Williams 2008-09-25 09:55:59 EDT
Dan:

allow NetworkManager_t dhcp_etc_t:file { read getattr };

should be allowed since NM now reads/writes some dhcp-related files in /etc, specifically it will read /etc/dhclient-<iface>.conf and merge those options into /var/run/nm-dhclient-<iface>.conf.  Could we get that added to the policy since it seems correct to me?

I'm not sure about the pam_nssldap thing; is there anything I can do about that in NM?

Thanks!
Comment 5 Daniel Walsh 2008-09-25 15:22:02 EDT
Added to F8,F9, F10 and RHEL5 policy.

There is nothing networkmanager can do about

allow NetworkManager_t system_dbusd_t:tcp_socket { read write };

Fixed in selinux-policy-3.0.8-117.fc8.src.rpm
Comment 6 Bug Zapper 2008-11-26 05:59:48 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 WONTFIX if it remains open with a Fedora 
'version' of '8'.

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 prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Jon Stanley 2008-11-26 12:37:43 EST
As this bug is in MODIFIED, Fedora believes that a fix has been committed that resolves the problem listed in this bug report.

If this is not the case, please re-open this report, noting the version of the package that you reproduced the bug against.

Thanks for the report!

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