Bug 588745 - SELinux is preventing /usr/sbin/NetworkManager "connectto" access on @/tmp/dbus-CtTWWUyXCq.
Summary: SELinux is preventing /usr/sbin/NetworkManager "connectto" access on @/t...
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 14
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
Whiteboard: setroubleshoot_trace_hash:ce05e842d0a...
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-04 12:38 UTC by Ritesh Khadgaray
Modified: 2011-02-24 05:09 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-02-24 05:09:43 UTC
Type: ---

Attachments (Terms of Use)

Description Ritesh Khadgaray 2010-05-04 12:38:30 UTC

SELinux is preventing /usr/sbin/NetworkManager "connectto" access on

Detailed Description:

[SELinux is in permissive mode. This access was not denied.]

SELinux denied access requested by NetworkManager. It is not expected that this
access is required by NetworkManager 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.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug

Additional Information:

Source Context                unconfined_u:system_r:NetworkManager_t:s0
Target Context                unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0
Target Objects                @/tmp/dbus-CtTWWUyXCq [ unix_stream_socket ]
Source                        NetworkManager
Source Path                   /usr/sbin/NetworkManager
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           NetworkManager-0.8.0-10.git20100502.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.19-6.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed)
                              2.6.34-0.38.rc5.git0.fc14.x86_64 #1 SMP Tue Apr 20
                              01:56:52 UTC 2010 x86_64 x86_64
Alert Count                   2
First Seen                    Tue 04 May 2010 05:51:07 PM IST
Last Seen                     Tue 04 May 2010 05:51:37 PM IST
Local ID                      63986b74-0b60-4b9d-b922-eb3534480d0d
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1272975697.301:23406): avc:  denied  { connectto } for  pid=27638 comm="NetworkManager" path=002F746D702F646275732D43745457575579584371 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tclass=unix_stream_socket

node=(removed) type=SYSCALL msg=audit(1272975697.301:23406): arch=c000003e syscall=42 success=yes exit=4294967424 a0=b a1=7fffbd9f4080 a2=17 a3=0 items=0 ppid=1 pid=27638 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="NetworkManager" exe="/usr/sbin/NetworkManager" subj=unconfined_u:system_r:NetworkManager_t:s0 key=(null)

Hash String generated from  catchall,NetworkManager,NetworkManager_t,unconfined_dbusd_t,unix_stream_socket,connectto
audit2allow suggests:

#============= NetworkManager_t ==============
allow NetworkManager_t unconfined_dbusd_t:unix_stream_socket connectto;

Comment 1 Michal Schmidt 2010-05-10 16:25:59 UTC
I can reproduce this by doing:
/etc/init.d/NetworkManager restart

but it's not reproducible reliably. It only happens in about 30 % of attempts.

Comment 2 Daniel Walsh 2010-05-10 17:28:20 UTC
Are you seeing this on a Konsole terminal?

Comment 3 Michal Schmidt 2010-05-11 08:37:42 UTC
It is reproducible in any terminal emulator within an X session (I tried gnome-terminal, xterm, konsole). It is not reproducible in plain Linux VT.


Alright, I found an important fact. It matters how I exactly I get root. It is reproducible if I use "su". It is not reproducible if I use "su -" or "sudo".

Only in the "su" case, the environment contains an item like this:

The name of the abstract socket corresponds to the name reported in the denial message.

Comment 4 Daniel Walsh 2010-05-11 14:48:40 UTC
Colin, Any idea why this would happen?

Comment 5 Colin Walters 2010-05-11 22:06:45 UTC
Clearly something in NetworkManager is trying to connect to the session bus.  Grepping the upstream source code for DBUS_BUS_SESSION, I only see hits for tests.


Comment 6 Dan Williams 2010-05-11 22:30:44 UTC
(In reply to comment #5)
> Clearly something in NetworkManager is trying to connect to the session bus. 
> Grepping the upstream source code for DBUS_BUS_SESSION, I only see hits for
> tests.
> Dan?    

Nothing in NM should be attempting to connect to the session bus at all...  so I'm not quite sure how this could be happening.  I suppose I could put some debug tracing in libdbus to break NM when a connection to the session bus is requested?

Comment 7 Michal Schmidt 2010-05-13 12:03:38 UTC
The same thing happens in RHEL-6 (NetworkManager-0.8.0-12.git20100504.el6.x86_64).

In gdb I got a backtrace from NM attempting to connect to the session bus:

Breakpoint 1, connect () at ../sysdeps/unix/syscall-template.S:82
Missing separate debuginfos, use: debuginfo-install GConf2-2.28.0-6.el6.x86_64 ORBit2-2.14.17-3.1.el6.x86_64 gamin-0.1.10-9.el6.x86_64 gvfs-1.4.3-7.el6.x86_64
(gdb) bt
#0  connect () at ../sysdeps/unix/syscall-template.S:82
#1  0x000000321622d510 in _dbus_connect_unix_socket (path=0x6e63a0 "/tmp/dbus-5BNaDSui52", abstract=1, error=0x7fffffffd590)
    at dbus-sysdeps-unix.c:544
#2  0x0000003216224777 in _dbus_transport_new_for_domain_socket (path=0x6e63a0 "/tmp/dbus-5BNaDSui52", abstract=1, 
    error=0x7fffffffd590) at dbus-transport-unix.c:81
#3  0x0000003216224934 in _dbus_transport_open_platform_specific (entry=0x6e5310, transport_p=0x7fffffffd5b8, 
    error=0x7fffffffd590) at dbus-transport-unix.c:161
#4  0x0000003216223031 in _dbus_transport_open (entry=0x6e5310, error=0x7fffffffd640) at dbus-transport.c:376
#5  0x000000321620f931 in connection_try_from_address_entry (address=<value optimized out>, shared=0, error=0x0)
    at dbus-connection.c:1733
#6  _dbus_connection_open_internal (address=<value optimized out>, shared=0, error=0x0) at dbus-connection.c:1802
#7  0x000000321620b693 in internal_bus_get (type=DBUS_BUS_SESSION, private=1, error=0x0) at dbus-bus.c:480
#8  0x00007ffff67540c1 in ?? () from /usr/lib64/gio/modules/libgvfsdbus.so
#9  0x0000003212e2c017 in IA__g_type_create_instance (type=<value optimized out>) at gtype.c:1674
#10 0x0000003212e10d9c in g_object_constructor (type=<value optimized out>, n_construct_properties=0, construct_params=0x0)
    at gobject.c:1383
#11 0x0000003212e121fa in IA__g_object_newv (object_type=7243776, n_parameters=0, parameters=0x0) at gobject.c:1171
#12 0x0000003212e128ed in IA__g_object_new_valist (object_type=7243776, first_property_name=0x0, var_args=0x7fffffffdb70)
    at gobject.c:1323
#13 0x0000003212e12a4c in IA__g_object_new (object_type=7243776, first_property_name=0x0) at gobject.c:1086
#14 0x0000003214259165 in get_default_vfs (arg=<value optimized out>) at gvfs.c:209
#15 0x00000032126604fb in IA__g_once_impl (once=0x32144aa170, func=0x32142590b0 <get_default_vfs>, arg=0x0) at gthread.c:190
#16 0x0000003214226d3e in IA__g_file_new_for_path (path=0x7ffff6d92800 "/etc/sysconfig/network-scripts/") at gfile.c:5743
#17 0x00007ffff6d83989 in setup_ifcfg_monitoring (plugin=0x6bcd80) at plugin.c:369
#18 0x00007ffff6d8451d in get_unmanaged_specs (config=0x6bcd80) at plugin.c:433
#19 0x0000000000470594 in unmanaged_specs_changed (config=<value optimized out>, user_data=<value optimized out>)
    at nm-sysconfig-settings.c:322
#20 0x000000000047085b in nm_sysconfig_settings_new (config_file=<value optimized out>, plugins=<value optimized out>, 
    bus=<value optimized out>, error=0x7fffffffe1a0) at nm-sysconfig-settings.c:1332
#21 0x00000000004450b0 in nm_manager_get (config_file=0x6b1be0 "/etc/NetworkManager/nm-system-settings.conf", 
    plugins=0x6b4e70 "ifcfg-rh", state_file=0x6b1a30 "/var/lib/NetworkManager/NetworkManager.state", initial_net_enabled=1, 
    initial_wifi_enabled=1, initial_wwan_enabled=1, error=0x7fffffffe1a0) at nm-manager.c:2956
#22 0x000000000043d915 in main (argc=1, argv=0x7fffffffe328) at main.c:650

Comment 8 Colin Walters 2010-05-13 13:15:44 UTC
Ah hah, it's gvfs.  I suppose NM could work around this by doing g_unsetenv("DBUS_SESSION_BUS_ADDRESS"), but...

Anyways, I think the real bug here is that we're still using this broken legacy Unix model where typing "/etc/init.d/NetworkManager restart" is run directly from the admin shell instead of sending a message to Upstart, and thus not inheriting the random environment from the admin shell.

Comment 9 Daniel Walsh 2010-05-13 13:28:41 UTC
Ritesh you can ignore this for now.

Comment 10 Dan Williams 2010-05-13 17:56:39 UTC
Upstream fix is a7e0e6231123b09f717f43ea4064e062b3440223

Comment 11 Bug Zapper 2010-07-30 11:32:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:

Comment 12 Dan Williams 2011-02-24 05:09:43 UTC
Should be long fixed in 0.8.2 and later.

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