SpamAssassin Log explosion issue following update

[Ted Rule]

Ah.

So does that mean my current method for getting sysadm_t status is
flawed?

At the moment I login as staff_u, newrole into sysadm_r, and thence "su
-" to sysadm_t.

This leaves me in "staff_u:sysadm_r:sysadm_t", whereupon run_init seems
to be perfectly capable of running init scripts whilst in enforcing
mode.

Perhaps the root of my problem is that I ran "yum update" whilst in
permissive starting from "staff_u:sysadm_r:sysadm_t", but the policy
failed to transition to system_u when some of the rpm postinstall
scripts ran /etc/init.d/xxxxx?



On Fri, 2007-02-23 at 08:10 -0500, Stephen Smalley wrote:
> On Fri, 2007-02-23 at 09:16 +0000, Ted Rule wrote:
> > I've had another dig through the remnants of logs following yesterday's
> > log explosion. Fortunately, I hadn't completely eliminated the log
> > history of the crash.
> > 
> > It seems that Dan is quite right in saying that the RPM Upgrade didn't
> > cause the issue. The logs show that it all started when I amended my
> > localanacron policy some 2 minutes before the log explosion started.
> > 
> > I see these two entries:
> > 
> > ...
> > Feb 22 11:19:10 topaz kernel: security:  invalidating context
> > staff_u:sysadm_r:initrc_t:s0
> > Feb 22 11:19:10 topaz kernel: security:  invalidating context
> > staff_u:system_r:spamd_t:s0
> 
> This means that at an earlier point in time, while permissive, the
> system executed an init script and spamd and performed automatic domain
> transitions even though the resulting contexts weren't legal under
> policy (allowed when permissive) due to invalid combinations of
> role/type or user/role (e.g. initrc_t should be in system_r, not
> sysadm_r, and likely staff_u isn't authorized for system_r?).  Then
> later you reloaded policy while enforcing, and the system invalidated
> those contexts and remapped them to unlabeled.
> 
> run_init explicitly transitions to system_u:system_r:initrc_t for
> running init scripts.  The role transition can be done automatically via
> policy (role_transition statements), but we don't presently have support
> for automatic user transitions in policy.

-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/