On Tue, Jul 21, 2020 at 4:14 PM Dominick Grift <dominick.grift@xxxxxxxxxxx> wrote: > > +context for both subjects and objects when their label is invalidated > > +by a policy reload (their SID is unchanged but the SID is > > +transparently remapped to the unlabeled context). > > I will note here that I suspect there is currently something broken > with libselinux / unlabeled sids > > libselinux consumers still use *invalidated* contexts associated with > inodes to compute access vectors. > > for example rpm will not consistently work until the filesystems are > relabeled after a new policy is loaded that invalidates contexts > currently associated with /bin/sh (entrypoint for setfscreatecon to > "rpm_script_t") > > systemd will not consistently work until the filesystems are relabeled > after a new policy loaded that invalidates contexts currently associated > with (i suspect) parent directories for socket activated sock files > (maybe setfscreatecon?) That's because userspace doesn't pass SIDs to the kernel (they aren't exported by the kernel); it passes security contexts, and the kernel refuses to accept invalid contexts. So a context previously used by userspace that is invalidated by a policy reload and then later passed in again to a kernel interface will produce an error. IIRC, the security_get_initial_context() and avc_get_initial_sid() interfaces were added to allow userspace object managers like SEPostgreSQL to get the context associated with an initial SID like the unlabeled SID for their own internal use/handling, but libselinux doesn't try to remap like that internally and it wouldn't always know whether the context was previously valid unless it maintained state on all calls.
