Bug 428645 - selinux blocks script launched by NetworkManager dispatcher.d
selinux blocks script launched by NetworkManager dispatcher.d
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-01-14 06:54 EST by Kevin R. Page
Modified: 2008-01-25 08:51 EST (History)
1 user (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-25 08:51:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kevin R. Page 2008-01-14 06:54:21 EST
Description of problem:
I have a script in /etc/NetworkManager/dispatcher.d/ntpd-script set to start
ntpd on connection to a network (see http://www.ces.clemson.edu/linux/nm.shtml )

The latest release of selinux-policy-targeted has stopped this from working - it
was ok previously.

The script is in /etc, ls -aZ shows:
-rwx------  root root system_u:object_r:etc_t:s0       ntpd-script

setroubleshoot suggests setting context to bin_t - is this the right thing to do?

Raw Audit Messages :avc: denied { execute } for comm=sh dev=dm-1 egid=0 euid=0
exe=/bin/bash exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=ntpd-script pid=17255
scontext=system_u:system_r:NetworkManager_t:s0 sgid=0
subj=system_u:system_r:NetworkManager_t:s0 suid=0 tclass=file
tcontext=system_u:object_r:etc_t:s0 tty=(none) uid=0 

Version-Release number of selected component (if applicable):
Comment 1 Daniel Walsh 2008-01-14 13:03:57 EST
It needs to be labeled bin_t to work.  Why did you move this out of 


 matchpathcon /etc/NetworkManager/dispatcher.d/ntpd-script
/etc/NetworkManager/dispatcher.d/ntpd-script	system_u:object_r:bin_t

If you move it to this directory and run restorecon on it, the script will be
labeled bin_t and be executable.

If you must have it in /etc (not recommended), you need to fix the labeling by

# semanage fcontext -a -t bin_t /etc/ntpd-script
# restorecon /etc/ntpd-script

Comment 2 Kevin R. Page 2008-01-14 13:37:43 EST
Ah, sorry, I fouled up cut'n'paste on the second reference to the file - it is,
and always has been, in /etc/NetworkManager/dispatcher.d/

restorecon doesn't label it bin_t :

# restorecon /etc/NetworkManager/dispatcher.d/ntpd-script
# ls -aZ /etc/NetworkManager/dispatcher.d/ntpd-script 
-rwx------  root root system_u:object_r:etc_t:s0


# matchpathcon /etc/NetworkManager/dispatcher.d/ntpd-script
/etc/NetworkManager/dispatcher.d/ntpd-script    system_u:object_r:etc_t:s0

which is different to your output in comment #1.

I guess, from your matchpathcon output, that you're running a newer policy - is
a specific version I should try?
Comment 3 Daniel Walsh 2008-01-14 14:13:33 EST
Fixed in selinux-policy-3.0.8-76.fc8
Comment 4 Orion Poplawski 2008-01-15 13:38:44 EST
Same problem in F7 with selinux-policy-2.6.4-67.fc7.
Comment 5 Orion Poplawski 2008-01-17 16:48:13 EST
Confirmed that the original issue is resolved for me in -76.fc8, now just for F7.
Comment 6 Daniel Walsh 2008-01-18 13:15:16 EST
Fixed in selinux-policy-3.6.4-70.fc7
Comment 7 Orion Poplawski 2008-01-22 15:19:44 EST
(In reply to comment #6)
> Fixed in selinux-policy-3.6.4-70.fc7

Looks good to me.
Comment 8 Kevin R. Page 2008-01-24 02:57:27 EST
Original block is fixed, but with the same script I now get:
SELinux is preventing ntpd-script (NetworkManager_t) "getattr" to
/var/run/ntpd.pid (ntpd_var_run_t).

Policy RPM:  selinux-policy-3.0.8-76.fc8

Raw Audit Messages :
avc: denied { getattr } for comm=ntpd-script dev=dm-1 egid=0 euid=0
exe=/bin/bash exit=-13 fsgid=0 fsuid=0 gid=0 items=0 path=/var/run/ntpd.pid
pid=5635 scontext=system_u:system_r:NetworkManager_t:s0 sgid=0
subj=system_u:system_r:NetworkManager_t:s0 suid=0 tclass=file
tcontext=system_u:object_r:ntpd_var_run_t:s0 tty=(none) uid=0 
Comment 9 Orion Poplawski 2008-01-24 10:32:47 EST
I saw similar with my script and /var/lock.  I fixed it by using the "service"
command instead of trying to manipulate /var/lock directly.  E.g.:

/sbin/service ntp status

/sbin/service ntp start

Comment 10 Daniel Walsh 2008-01-24 13:25:13 EST
So your dispatcher script is doing a service ntp start ?
Comment 11 Daniel Walsh 2008-01-24 13:28:02 EST
For these type of local customizations, I think you are going to have to write
your own policy for now.  

In Rawhide, we have begun breaking out initrc scripts into separate types.  So I
can add 


Which allows NetworkManager to turn on and off ntp.
Comment 12 Orion Poplawski 2008-01-24 13:38:41 EST
I can start and stop ntp (and ypbind and autofs) just fine using "/sbin/service"
in my dispatcher scripts.  I'm assuming that that handles the appropriate
transitions.  I don't think the dispatcher scripts should manipulate /var/run
and /var/lock directly.  No idea what Kevin's script is doing, so maybe he's
having a different problem.
Comment 13 Daniel Walsh 2008-01-24 13:45:53 EST
Yes currently policy has 


Which is probably to broad.  

THis allows NetworkManager to run any initrc script.  I would like to get to the
point where it would only be able to start and stop network services scripts.

Not iptables for example.
Comment 14 Kevin R. Page 2008-01-24 18:15:19 EST
(In reply to comment #10)
> So your dispatcher script is doing a service ntp start ?

Yes, and a restart again if the interface is changed. With ntpd in a normal
runlevel init has to wait for ntpd to time out when there (often) isn't any
network on boot.

The script (taken from the link in comment #0) was checking for - but not
changing -  /var/run/ntpd.pid to find whether ntpd was active. I changed this to
call "/sbin/service/ntpd status" and it's no longer blocked by selinux (with the
current policy, at least). Thanks!

As for the future, I'd expect (hope!?) with the move to Upstart, and
NetworkManager replacing the network init script in F9, that the NetworkManager
dispatcher will become the default mechanism to start any services which require
a network connection.

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