selinux-policy-targeted and logrotate

[Stephen Smalley]

On Fri, 2005-06-17 at 09:58 -0500, alex at milivojevic.org wrote:
> I've installed selinux-policy-targeted-1.17.30-2.88 from RHEL4 U1 on my system. 
> It fixed number of problems with /tmp mounted as tmpfs (and hence having context
> of tmpfs_t, instead of tmp_t).  However, I'm still noticing one problem. 
> Logrotate postrotate scripts fail.  Log files show it was SELinux blocking
> them:
> 
> Jun 16 04:02:23 mybox kernel: audit(1118912543.190:0): avc:  denied  { associate
> } for  pid=28151 comm=logrotate name=logrotate.8npXq2
> scontext=system_u:object_r:var_t tcontext=system_u:object_r:tmpfs_t
> tclass=filesystem
> Jun 17 04:02:18 mybox kernel: audit(1118998938.340:0): avc:  denied  { associate
> } for  pid=6006 comm=logrotate name=logrotate.aNF9be
> scontext=system_u:object_r:var_t tcontext=system_u:object_r:tmpfs_t
> tclass=filesystem

Hmm...tmpfs_t instead of logrotate_tmp_t?  Ok, I had thought that Dan
had come up with a solution that would be equivalent to mounting with
fscontext=system_u:object_r:tmp_t and running restorecon /tmp, but I
guess he didn't.  Just running restorecon /tmp is only going to change
the context on /tmp; any further files will end up transitioning from
the superblock context (which is still tmpfs_t in the absence of using
fscontext=), so they would end up requiring tmpfs_domain for each domain
with /tmp files and labeling those /tmp files with xxx_tmpfs_t instead.
At which point the xxx_tmp_t types become unused and irrelevant.

> As I was typing this email, I noticed Daniel already have SELinux/RHEL4/u2
> directory, and chagelog indicated problem with logrotate and tmpfs was tackled
> after version 1.17.30-2.88 was released.  So I downloaded
> selinux-policy-targeted-1.17.30-3.6 and installed it on test system.  I noticed
> small problem with postinstall script.  It calls /sbin/restorecon, and it seems
> to be relabeling all my file systems as I type this (taking a looong time). 
> Not sure if this would be good idea on production systems that might have some
> directories with custom labels.  For example, I have chrooted Apache on one of
> my systems, and relabeling would destroy it since all the files in chroot jail
> would be reset to wrong labels.  Also, if I used chcon to give some application
> access to files in non-default area, relabeling entire file system would trash
> those too.

Yes, blind relabeling considered harmful.  Not sure what went into RHEL4
updates, but FC only runs fixfiles -C to do a selective relabel based on
a diff of the old and new file contexts (which can still degenerate to a
full relabel if the diff is too large).

> Another problem I noticed was that file_contexts and policy.18 files were
> created as dot rpmnew, and than restorecon complains about "invalid labels" or
> something like that (can't cut&paste it or look exact wording, it scrolled off
> very fast, I hardly spotted that newrpm thing).  I guess there are some new
> types defined in updated policy, but since policy file was created as rpmnew,
> the script simply reloaded old policy file, and kernel didn't knew about new
> types.
> 
> Anyhow, I believe I had original policy.18 and file_contexts as installed by
> previous version of the package.  Shouldn't in this case RPM install new files
> instead of creating them as rpmnew?

Yes, if they truly were the originals.  rpm -V selinux-policy-targeted.
I suspect that the problem is that you installed
selinux-policy-targeted-sources, which performs a make load in the
policy source directory as part of the %post sources, thereby
overwriting the files from selinux-policy-targeted.  rpm then thinks
that you have customized the built files even if you never actually
modified policy sources themselves.  Of course, if you update policy
sources, then that should rebuild your policy.

-- 
Stephen Smalley
National Security Agency