Bug 529951

Summary: SELinux is preventing the /bin/loadkeys from using potentially mislabeled files (Documents).
Product: [Fedora] Fedora Reporter: Pavel Horák <pavhor>
Component: livecd-toolsAssignee: David Huff <dhuff>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: awilliam, bruno, dwalsh, fedora, katzj, kevin, lakshminaras2002, mgrepl, rdieter, rnovacek
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:f33bab51fd9c8bcc423f93bab947aaf622cb8c3326de605ae8376d57e26430a2
Fixed In Version: livecd-tools-034-7.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-16 03:47:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 473302    

Description Pavel Horák 2009-10-20 20:43:47 UTC
Summary:

SELinux is preventing the /bin/loadkeys from using potentially mislabeled files
(Documents).

Detailed Description:

[SELinux is in permissive mode. This access was not denied.]

SELinux has denied loadkeys access to potentially mislabeled file(s)
(Documents). This means that SELinux will not allow loadkeys to use these files.
It is common for users to edit files in their home directory or tmp directories
and then move (mv) them to system directories. The problem is that the files end
up with the wrong file context which confined applications are not allowed to
access.

Allowing Access:

If you want loadkeys to access this files, you need to relabel them using
restorecon -v 'Documents'. You might want to relabel the entire directory using
restorecon -R -v 'Documents'.

Additional Information:

Source Context                unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c102
                              3
Target Context                unconfined_u:object_r:user_home_t:s0
Target Objects                Documents [ dir ]
Source                        loadkeys
Source Path                   /bin/loadkeys
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           kbd-1.15-9.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-24.fc12
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   home_tmp_bad_labels
Host Name                     (removed)
Platform                      Linux (removed) 2.6.31.1-56.fc12.i686
                              #1 SMP Tue Sep 29 16:32:02 EDT 2009 i686 athlon
Alert Count                   2
First Seen                    Wed 21 Oct 2009 04:09:19 AM CEST
Last Seen                     Wed 21 Oct 2009 04:09:19 AM CEST
Local ID                      40afda63-b9d7-4be8-9866-c97bdc442298
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1256090959.940:31037): avc:  denied  { read } for  pid=2400 comm="loadkeys" name="Documents" dev=dm-0 ino=92322 scontext=unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir

node=(removed) type=AVC msg=audit(1256090959.940:31037): avc:  denied  { open } for  pid=2400 comm="loadkeys" name="Documents" dev=dm-0 ino=92322 scontext=unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir

node=(removed) type=SYSCALL msg=audit(1256090959.940:31037): arch=40000003 syscall=5 success=yes exit=6 a0=80568e7 a1=98800 a2=80568e7 a3=bf8cfcd1 items=0 ppid=2258 pid=2400 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="loadkeys" exe="/bin/loadkeys" subj=unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  selinux-policy-3.6.32-24.fc12,home_tmp_bad_labels,loadkeys,loadkeys_t,user_home_t,dir,read
audit2allow suggests:

#============= loadkeys_t ==============
allow loadkeys_t user_home_t:dir { read open };

Comment 1 Daniel Walsh 2009-10-20 22:50:03 UTC
What were you doing when you got this AVC to happen?

Comment 2 Pavel Horák 2009-10-21 09:03:26 UTC
This bug emerged right after F12-Beta-i686-Live-KDE.iso (burned to CD) booted to KDE. I was doing "nothing". Previous version I tried (I think it was Beta RC2 from 2009-10-15 was ok).

Comment 3 Daniel Walsh 2009-10-21 14:18:16 UTC
When you login, what does

id -Z 

show?

Comment 4 Pavel Horák 2009-10-21 15:01:46 UTC
I tried it again and I can't reproduce it now :(

[liveuser@localhost ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Comment 5 Daniel Walsh 2009-10-21 15:18:38 UTC
Well since it makes no sense at all,  I will just close it as worksforme.

If you can reproduce, reopen it.  Thanks.

Comment 6 Ben Boeckel 2009-11-02 21:30:00 UTC
It just occurred here when installing from the KDE Live CD F12 beta i386. It happened once it was setting the permissions on the filesystem after copying the image over.

Reopening.

Comment 7 Daniel Walsh 2009-11-03 13:46:07 UTC
Did you get the same avc?  Could you attach your /var/log/audit/audit.log?  I can not see why the load_keys program would be trying to read the contents of the Documents directory under a users homedir.

Comment 8 Ben Boeckel 2009-11-03 14:03:06 UTC
The bug reporting tool came up with this bug report as a duplicate, so I assume it is the same denial.

This bug actually happened on a friend's machine while installing, I entered my information to report the bug so that it got reported. I'll get him CC'd to get more information.

Comment 9 Ben Boeckel 2009-11-03 14:36:29 UTC
Blocking F12Blocker (KDE-SIG meeting).

Comment 10 Adam Williamson 2009-11-03 15:12:57 UTC
The impact of this bug isn't at all clear, from the descriptions above you get a denial but nothing seems to suggest this breaks anything. Could you explain more clearly what the problem is here? I do catch a reference to '"install to hd link on desktop lacking execute permission" problem' in the KDE meeting log, but that's a bit cryptic with no context.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 11 Rex Dieter 2009-11-03 15:23:37 UTC
I would agree, in retrspect, that without knowing the impact here, it's premature to consider this a blocker.  removing, until we have further data.

Comment 12 Adam Williamson 2009-11-03 16:11:00 UTC
it's obviously not nice from a polish perspective, but we're right down to the wire for f12 final (we basically have today and tomorrow to fix blockers) so i have a pretty high bar on new blocker issues right now :/

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 13 Kevin Kofler 2009-11-03 21:35:07 UTC
The .desktop file lacking execute permission is a completely separate issue.

Comment 14 Adam Williamson 2009-11-03 21:56:57 UTC
Thanks for that clarification.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 15 Daniel Walsh 2009-11-04 14:01:39 UTC
I am allowing it in selinux-policy-3.6.32-41.fc12.noarch

Just for polish reasons.  But will remove from Rawhide after F12 ships, since I think this is covering up a bug.

Comment 16 Adam Williamson 2009-11-04 17:00:21 UTC
it may help the KDE folks fix it properly if you could provide a hint about what you think the bug is - I guess "I can not see why the load_keys program would be trying to read the contents of the Documents directory under a users homedir." ?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 17 Bug Zapper 2010-03-15 12:57:08 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 18 Fedora Admin XMLRPC Client 2010-05-07 15:41:25 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 19 Bruno Wolff III 2010-09-12 01:18:31 UTC
This looks like a duplicate of Bug 519709 for which an upstream fix has been committed. This will probably be fixed in the next release of livecd-tools.

Comment 20 Fedora Update System 2010-09-12 04:19:22 UTC
livecd-tools-034-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/livecd-tools-034-1.fc14

Comment 21 Fedora Update System 2010-09-13 18:09:06 UTC
livecd-tools-034-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update livecd-tools'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/livecd-tools-034-2.fc14

Comment 22 Fedora Update System 2010-09-15 03:22:06 UTC
livecd-tools-034-7.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/livecd-tools-034-7.fc14

Comment 23 Fedora Update System 2010-09-15 06:51:25 UTC
livecd-tools-034-7.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update livecd-tools'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/livecd-tools-034-7.fc14

Comment 24 Fedora Update System 2010-09-16 03:46:11 UTC
livecd-tools-034-7.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.