Bug 522513 - setroubleshoot: SELinux is preventing krootimage "setattr" access on backgroundrc.lock.MT1376.
Summary: setroubleshoot: SELinux is preventing krootimage "setattr" access on bac...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase-workspace
Version: 12
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ngo Than
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:1ff72ed0ae2...
: 522516 522517 577456 578300 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-10 15:10 UTC by Peter Trenholme
Modified: 2010-06-17 17:53 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-01-30 20:14:58 UTC


Attachments (Terms of Use)

Description Peter Trenholme 2009-09-10 15:10:54 UTC
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;

Comment 1 Daniel Walsh 2009-09-10 15:34:54 UTC
Not sure why krootimage is trying to write files under /etc.

The should be under /var some where.

Comment 2 Daniel Walsh 2009-09-10 15:35:20 UTC
*** Bug 522516 has been marked as a duplicate of this bug. ***

Comment 3 Daniel Walsh 2009-09-10 15:36:18 UTC
*** Bug 522517 has been marked as a duplicate of this bug. ***

Comment 4 Rex Dieter 2009-09-10 15:53:48 UTC
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?

Comment 5 Peter Trenholme 2009-09-10 16:13:31 UTC
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?

Comment 6 Peter Trenholme 2009-09-10 16:24:02 UTC
(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.

Comment 7 Daniel Walsh 2009-09-10 17:03:42 UTC
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.

Comment 8 Rex Dieter 2009-09-10 17:49:28 UTC
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.

Comment 9 Daniel Walsh 2009-09-10 18:17:31 UTC
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

Comment 10 Rex Dieter 2009-09-10 18:21:27 UTC
I'll take a closer look, to see which approach works better, thanks.

Comment 11 Daniel Walsh 2009-09-10 19:38:31 UTC
Well the first suggestion is no good since It allows xdm_t to write Xsession which can influence the login session.

Comment 12 Kevin Kofler 2009-09-11 07:34:19 UTC
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.

Comment 13 Daniel Walsh 2009-09-11 13:34:41 UTC
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.

Comment 14 Steven M. Parrish 2009-09-26 22:50:55 UTC
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

Comment 15 Bug Zapper 2009-11-16 12:12:13 UTC
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

Comment 17 Rex Dieter 2010-01-30 19:33:45 UTC
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.

Comment 18 Rex Dieter 2010-01-30 19:35:09 UTC
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.

Comment 19 Rex Dieter 2010-01-30 20:14:58 UTC
kde-settings %changelog
* Sat Jan 30 2010 Rex Dieter <rdieter@fedoraproject.org> 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.

Comment 20 Kevin Kofler 2010-01-31 06:42:25 UTC
Are you sure this is a good idea? IMHO config files should really be in /etc, not /var.

Comment 21 Rex Dieter 2010-01-31 12:38:35 UTC
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

Comment 22 Rex Dieter 2010-03-30 20:29:01 UTC
*** Bug 578300 has been marked as a duplicate of this bug. ***

Comment 23 Rex Dieter 2010-04-28 15:12:33 UTC
*** Bug 577456 has been marked as a duplicate of this bug. ***


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