The following was filed automatically by setroubleshoot: Summary: SELinux is preventing krootimage "setattr" access on backgroundrc.lock.MT1376. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by krootimage. It is not expected that this access is required by krootimage and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:etc_t:s0 Target Objects backgroundrc.lock.MT1376 [ file ] Source krootimage Source Path /usr/libexec/kde4/krootimage Port <Unknown> Host (removed) Source RPM Packages kdebase-workspace-4.3.1-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.30-4.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.31-0.204.rc9.fc12.x86_64 #1 SMP Sat Sep 5 20:45:55 EDT 2009 x86_64 x86_64 Alert Count 1 First Seen Thu 10 Sep 2009 07:58:50 AM PDT Last Seen Thu 10 Sep 2009 07:58:50 AM PDT Local ID a4c2bcc8-f53a-4214-bd9a-0f6e63224cdc Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1252594730.334:30): avc: denied { setattr } for pid=1376 comm="krootimage" name="backgroundrc.lock.MT1376" dev=dm-0 ino=10250 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1252594730.334:30): arch=c000003e syscall=91 success=yes exit=0 a0=8 a1=1a4 a2=1914a60 a3=7fff12d3ff40 items=0 ppid=1363 pid=1376 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="krootimage" exe="/usr/libexec/kde4/krootimage" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) audit2allow suggests: #============= xdm_t ============== allow xdm_t etc_t:file setattr;
Not sure why krootimage is trying to write files under /etc. The should be under /var some where.
*** Bug 522516 has been marked as a duplicate of this bug. ***
*** Bug 522517 has been marked as a duplicate of this bug. ***
kdm's config files are under, /etc/kde/kdm, I presume this user was running systemsettings (as root, or with elevated privs) to configure kdm theme, background, etc... Reporter, can you clarify if this is the case or not?
I think I've found the problem, although I haven't yet tried to fixed it. What I'd done was create a directory under / called /Wallpapers, and placed a lot of pictures (mostly JPEG) in it. But, since I run SELinux in "permissive" mode, I didn't think about changing the security context of those pictures. Thus I get "access denied" messages when the KDE (or KDM) process (like 'krootimage") uses (or tries to use) the image as a background. Anyhow, I just posted several "bugs" related to this problem, but - if I'm correct about the cause - you should ignore/close them. (They all relate to either "krootimage" or "backgroundrc.") I had just entered the last "bug" report when this idea occurred to me. I'm going to see if I can relabel the files in the directory now, and, if that fixes this, I'll add another comment. BTW, does the suggested fix (allow xdm_t etc_t:file setattr;) in the first post necessarily imply that the krootimage program (which, I think, is setting the background image for the KDM login screen) was trying to write to /etc?
(In reply to comment #4) > kdm's config files are under, /etc/kde/kdm, I presume this user was running > systemsettings (as root, or with elevated privs) to configure kdm theme, > background, etc... > > Reporter, can you clarify if this is the case or not? Since the KDM process resets the "background" image location in the configuration file in /etc/kde/kdm, and since I've told KDM to randomly select a background image from the /Wallpapers directory on every boot, and every minute thereafter, that file does get changed every time I boot the system. So, no, I wasn't using "system settings," but, yes, the configuration file was being changed, and that change is automatically made at every login.
I would argue that this should be in /var/lib/kdm not /etc/kde/kdm since /etc is supposed to be readonly. chcon -R -t xdm_var_lib_t /etc/kde/kdm WIll fix your problem.
Alright, it would appear then, that we can't support kdm's slideshow feature out of the box (ie, it requires unacceptable policy changes). You're welcome to adjust your local selinux policy to suit your own needs, of course.
Looking more into this, matchpathcon /etc/kde/kdm/backgroundrc /etc/kde/kdm/backgroundrc system_u:object_r:xdm_var_run_t:s0 So the problem is the lock file can not be created. So if the backgroundrc file was moved to a different location like /var/lib/kdm it would work fine. Or if we want to keep it in the /etc directory can we move it to a subdir of /etc/kde/kdm
I'll take a closer look, to see which approach works better, thanks.
Well the first suggestion is no good since It allows xdm_t to write Xsession which can influence the login session.
Those lock files are apparently new in KDE 4.3, to prevent some race conditions in kconfig. I guess that's why this hasn't come up earlier.
Well it should still not be attempting to write to /etc/. /etc/ is supposed to be a read/only file system. If this stuff is moved to /var/lib/kdm, SELinux control will get much easier and you guys would work better in systems with locked down /etc partitions. If I give kdm the ability to write to this directory and the contents. The tool could also overwrite XSession which would allow the tool to manipulate the way other peoples logins. Why am I paranoid about the login program? Well login programs can be run by anyone, login programs are getting quite extensive with thousands of lines of code for stuff like networking, and Assistive Controls. If a bug shows up in one of these a cracker could walk up to a machine and do evil without having to crack into a machine.
Rex is this something we want to fix locally and then try and upstream patches or just bump upstream entirely? -- Steven M. Parrish - KDE Triage Master - PackageKit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
It's a problem of our own doing, since this is usually at /usr/share/config/kdm and we moved it to /etc/kde/kdm.
kdmrc indeed has BackgroundCfg=/etc/kde/kdm/backgroundrc So it looks like we can move this to (something like) /var/lib/kdm alright. I'll test it out.
kde-settings %changelog * Sat Jan 30 2010 Rex Dieter <rdieter> 4.4-10 - move /etc/kde/kdm/backgroundrc => /var/lib/kdm/backgroundrc (#522513) - own /var/lib/kdm (regression, #442081) moving this config file within a release is painful and a bit risky, not sure we want to go there.
Are you sure this is a good idea? IMHO config files should really be in /etc, not /var.
I think so in this case. backgroundrc default location happens to be /var/lib/kdm (according to kdm's sources), it only ended up in /etc/kde/kdm due to our previously customized BackgroundCfg= directive
*** Bug 578300 has been marked as a duplicate of this bug. ***
*** Bug 577456 has been marked as a duplicate of this bug. ***