Bug 489538 - severe badness on F-10 -> rawhide upgrade w.r.t. policy and dbus
severe badness on F-10 -> rawhide upgrade w.r.t. policy and dbus
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-10 12:20 EDT by Bill Nottingham
Modified: 2014-03-16 23:17 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-10 16:11:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2009-03-10 12:20:32 EDT
Description of problem:

We've noticed recently a spate of errors on rawhide upgrades where, in the middle of the transaction, the desktop goes away and the transaction dies.

Upon debugging, it appears that the session bus for the desktop is refusing connections.

Coincident with the error appears to be the following message in syslog:

SELinux: Context unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 became invalid (unmapped)

Is the policy update removing the running context out from under the session bus? If so, how do we prevent this, as it causes fairly catastrophic effects to the desktop session.

Version-Release number of selected component (if applicable):

rawhide

How reproducible:

Often enough that it's not a coincidence
Comment 1 Daniel Walsh 2009-03-10 16:11:41 EDT
Fixed in selinux-policy-3.6.8-3.fc11
Comment 2 Colin Walters 2009-03-11 12:01:46 EDT
So if the SELinux policy removes a previously valid context, in general we will have a problem with any userspace program which acts as a SELinux userspace security manager.  Right now dbus is the most prominent, but the X server has the fundamental support, and once we add policy a similar bug could reappear there.

The solutions I see are:

1) Never remove security contexts from policy (an automated check here would probably be pretty easy)
2) Don't apply selinux-policy changes immediately, they require a reboot

Note You need to log in before you can comment on or make changes to this bug.