Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Stephen Smalley <stephen.smalley.work@gmail.com>]

On Tue, Jul 21, 2020 at 4:14 PM Dominick Grift
<dominick.grift@defensec.nl> 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.