On Fri, 2005-06-17 at 09:58 -0500, alex(a)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