On 06/27/2014 08:15 AM, Stephen Smalley wrote: > On 06/26/2014 10:17 AM, Paul Moore wrote: >> On Thursday, June 26, 2014 09:57:57 AM Stephen Smalley wrote: >>> On 06/25/2014 03:49 PM, Stephen Smalley wrote: >>>> I suspect it won't matter in practice, but the reason for it is that >>>> permissions or other state may have been cached during bootup prior to >>>> initial policy load that may no longer be valid. >> >> ... >> >>> So I am not sure we can safely remove the avc_ss_reset() from initial >>> policy load in the mainline kernel, as we are not guaranteed that there >>> is no network interface configuration prior to initial policy load and >>> we are not guaranteed that there will be a setenforce 1. It would >>> perhaps be better there to instead just avoid calling synchronize_net >>> altogether if possible or only call it once for the entire avc_ss_reset, >>> not on each of the netif/node/port callbacks. >> >> When I took a quick glance at this briefly yesterday one of the things that >> crossed my mind was exporting the different netif/node/port flush functions >> and grouping the callbacks into a single callback that calls each of the flush >> functions and then synchronize_net() once at the end; similar to what you >> describe above. Perhaps that is the best solution upstream. >> >> Unless someone else wants to develop/test a patch, I'll put one together. > > Did you confirm that we need the synchronize_net() call at all? Let me phrase this differently: 1) Does the synchronize_net() call guarantee that after the policy load completes (or more specifically, after the avc_ss_reset completes), all subsequent network permission checks will be based on the netif/node/port contexts defined by the new policy and not based on the old ones? -and- 2) Does anyone currently rely on this behavior, i.e. they make a change to the netif/node/port contexts in policy, load the new policy, and need to know that the new context assignments are being applied on every network operation before they can proceed safely? _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
