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/ -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
