On Thu, Mar 1, 2018 at 6:00 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Fri, Feb 16, 2018 at 12:19 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: >> Define a selinux state structure (struct selinux_state) for >> global SELinux state and pass it explicitly to all security server >> functions. The public portion of the structure contains state >> that is used throughout the SELinux code, such as the enforcing mode. >> The structure also contains a pointer to a selinux_ss structure whose >> definition is private to the security server and contains security >> server specific state such as the policy database and SID table. >> >> This change should have no effect on SELinux behavior or APIs >> (userspace or LSM). It merely wraps SELinux state and passes it >> explicitly as needed. >> >> Signed-off-by: Stephen Smalley <sds@xxxxxxxxxxxxx> >> --- >> This is effectively v2 of "selinux: introduce a selinux namespace", >> but rewritten per the review to only perform the encapsulation of state >> and rebased onto latest selinux/next, currently v4.16-rc1-based. >> Changes from v1: >> - Rename selinux_ns to selinux_state, >> - Statically allocate selinux_state and selinux_ss, >> - Drop any namespace-specific fields, code, and references, >> - Use static inlines rather than macros. >> >> I also intend to rework the "selinux: support multiple selinuxfs instances" >> and "selinux: move the AVC into the selinux namespace" patches similarly >> and re-base on this one, but want to wait until this one is finalized since >> every change to this own will require further reworking of the later ones. > > Thanks for the respin Stephen, I know that was probably a bit painful > given the size of the patch; it definitely wasn't fun to review. For > the most part I think everything here looks fine (minor nitpick, see > below), and because of these points: > > 1) Everything here is internal to SELinux so we change it without > breaking userspace or even other parts of the kernel. > > 2) Other work is dependent on this patch. > > 3) A patch of this size and scopr, I want it in linux-next sooner > rather than later. > > ... I'm going to merge this now, or rather as soon as my test kernel > finishes building and I can give this a quick sanity check. Quick sanity tests looked good, it's in selinux/next as of right now. > As expected, there were some minor merge problems with the SCTP > patches, but those were trivially fixed. > >> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h >> index 02f0412d42f2..c3a1ef10e710 100644 >> --- a/security/selinux/include/security.h >> +++ b/security/selinux/include/security.h > > ... > >> +static inline bool is_enforcing(struct selinux_state *state) >> +static inline void set_enforcing(struct selinux_state *state, bool value) > > More nitpickery: I'm not a fan of these names. > > I'm going to take partial blame for this as I didn't pay close enough > attention to the names earlier, I was focused on the #define vs inline > function nature of the functions. I realize it's late, and I want to > get this merged (see above), so I'll put together a separate patch on > top of this to change the names. -- paul moore www.paul-moore.com
