Bug 487782
| Summary: | new selinux alert for NM after update to 0.7.0.98-1 (F11/Alpha) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrew Hecox <ahecox> |
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dcbw, dwalsh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-03-03 20:41:15 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: | |||
|
Description
Andrew Hecox
2009-02-27 21:09:57 UTC
Dan: not entirely sure what pppd's issue is; NM will signal pppd when it wants to terminate it. Is there any indication of what signal pppd is actually trying to send here? No the problem is something is running as initrc_t. Did you add a new network manager script launched by dbus that is not running as NetworkManager_t but as initrc_t. (In reply to comment #2) > No the problem is something is running as initrc_t. Did you add a new network > manager script launched by dbus that is not running as NetworkManager_t but as > initrc_t. Nothing new; but for PPTP, 3G, and PPPoE, NM executes 'pppd' with a custom plugin, and pppd would then load that plugin (it's a .so though not a script) when the PPP connection comes up. That's all the interaction NM has with pppd; pppd should only be loading the .so which then uses D-Bus to talk back to NM. No scripts should be involved. fwiw, the alert is generated when I (physically) remove the device. Andrew what does ps -eZ | grep initrc_t show? nothing, initially. running in a loop and pulling out the card (when I originally noticed the sealert) provides: $ while : ; do ps -eZ | grep initrc_t; sleep 1; done system_u:system_r:initrc_t:s0 3271 ? 00:00:00 nm-dispatcher.a system_u:system_r:initrc_t:s0 3271 ? 00:00:00 nm-dispatcher.a system_u:system_r:initrc_t:s0 3271 ? 00:00:00 nm-dispatcher.a system_u:system_r:initrc_t:s0 3271 ? 00:00:00 nm-dispatcher.a system_u:system_r:initrc_t:s0 3271 ? 00:00:00 nm-dispatcher.a system_u:system_r:initrc_t:s0 3271 ? 00:00:00 nm-dispatcher.a system_u:system_r:initrc_t:s0 3271 ? 00:00:00 nm-dispatcher.a system_u:system_r:initrc_t:s0 3271 ? 00:00:00 nm-dispatcher.a system_u:system_r:initrc_t:s0 3271 ? 00:00:00 nm-dispatcher.a until I re-insert the card. Seems normal; /usr/libexec/nm-dispatcher.action will run when devices go up or down. But AFAIK, that shouldn't have anything to do with 'ppp' at all, unless one of the scripts that some package drops into /etc/NetworkManager/dispatcher.d pokes pppd. Which process is kicking off the /usr/libexec/nm-dispatcher.action? udev? dbus service activation kicks off nm-dispatcher.action in response to a method call from NM. Fixed in selinux-policy-3.6.7-1.fc11 |