Bug 590883
| Summary: | qt-4.7.x : SELinux is preventing ... "write" access on ... | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | atswartz | ||||||
| Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 14 | CC: | awilliam, carlg, coder.tux, dwalsh, eparis, fedora, fedora, ipilcher, itamar, john5342, jreznik, karo1170, kevin, ltinkl, magnus.tuominen, martin.nad89, mgrepl, mhlavink, moabi2000, orion, o.voves, piotrek.juzwiak, rdieter, rnovacek, sasch.pe, satellitgo, smparrish, than, thomasj | ||||||
| Target Milestone: | --- | Keywords: | FutureFeature | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | setroubleshoot_trace_hash:d3045667d805abbfb4405e9e4e20c2e06f1d064d5f3adb342b4afaf3d76e80a1 AcceptedBlocker | ||||||||
| Fixed In Version: | selinux-policy-3.9.5-10.fc14 | Doc Type: | Enhancement | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2010-10-05 13:08:48 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: | 538277, 604768 | ||||||||
| Attachments: |
|
||||||||
|
Description
atswartz
2010-05-10 21:05:53 UTC
Why would /usr/libexec/kde4/kdm_greet be trying to write to /bin? Do you have some python code out there? no *** Bug 591773 has been marked as a duplicate of this bug. *** For those experiencing this, did you customize kdm? If so, please post your /etc/kde/kdm/kdmrc and /var/lib/kdm/backgroundrc Created attachment 413821 [details]
kdmrc
Attaching as requested, kdmrc.
Created attachment 413822 [details]
backgroundrc
*** Bug 596931 has been marked as a duplicate of this bug. *** I customized KDM to login without typing any passwd and i'm getting this AVC too. SELinux is preventing /usr/libexec/kde4/kdm_greet "write" access on /usr/bin/startkde. and SELinux is preventing /usr/libexec/kde4/kdm_greet "write" access on /usr/libexec/kde4. This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Confirmed, putting on kde-4.5 blocker The variant I've been seeing lately (14 times in the past few days according to sealert) on my f13+kde-4.5.0 test box:
SELinux is preventing /usr/libexec/kde4/kdm_greet "write" access on /usr/libexec/kde4/lnusertemp.
...
node=localhost.localdomain type=AVC msg=audit(1281627743.173:23318): avc: denied { write } for pid=5112 comm="kdm_greet" name="lnusertemp" dev=dm-0 ino=74142 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file node=localhost.localdomain type=SYSCALL msg=audit(1281627743.173:23318): arch=c000003e syscall=21 success=no exit=-13 a0=13b8258 a1=2 a2=7ffff61e5ba0 a3=34 items=0 ppid=5109 pid=5112 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kdm_greet" exe="/usr/libexec/kde4/kdm_greet" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
What is this file? /usr/libexec/kde4/lnusertemp. Does kdm have any reason to want to write to it? /usr/libexec/kde4/lnusertemp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped "lnusertemp -- tool to create KDE resources and symlinks to them lnusertemp is used to create KDE resources in temporary directories and symlinks to them in KDEHOME. The resource that needs to be created is given as an argument and can be anyone of..." more info here : http://www.digipedia.pl/man/doc/view/lnusertemp.1/ >_< Summary: SELinux is preventing /usr/libexec/kde4/kdm_greet "write" access on /usr/libexec/kde4/drkonqi. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by kdm_greet. It is not expected that this access is required by kdm_greet 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://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:bin_t:s0 Target Objects /usr/libexec/kde4/drkonqi [ file ] Source kdm_greet Source Path /usr/libexec/kde4/kdm_greet Port <Unknown> Host BubbleWork Source RPM Packages kdm-4.5.0-2.fc14 Target RPM Packages kdebase-runtime-4.5.0-3.fc14 ... Raw Audit Messages node=BubbleWork type=AVC msg=audit(1282432145.165:35): avc: denied { write } for pid=2999 comm="kdm_greet" name="drkonqi" dev=dm-1 ino=55513 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file node=BubbleWork type=SYSCALL msg=audit(1282432145.165:35): arch=c000003e syscall=21 success=yes exit=0 a0=1b92508 a1=2 a2=7fff9b9ffd10 a3=2e items=0 ppid=2994 pid=2999 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kdm_greet" exe="/usr/libexec/kde4/kdm_greet" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) I am reliably getting the lnusertemp variant of this bug. It did vanish for a while but sometime in the last few days it came back. Unfortunately i don't know what updates might have caused it. Will have to have a proper look tomorrow at my update history to try and narrow it down. Mind doing a fs relabel to ensure that's not it? As root, # touch /.autorelabel and reboot Freshly installed system, seeing:
ype=AVC msg=audit(1285711360.517:5): avc: denied { write } for pid=1508 comm="kdm_greet" name="drkonqi" dev=sda5 ino=813438 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=AVC msg=audit(1285711362.214:6): avc: denied { write } for pid=1508 comm="kdm_greet" name="startkde" dev=sda5 ino=827367 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=AVC msg=audit(1285711362.563:8): avc: denied { write } for pid=1508 comm="kdm_greet" name="lnusertemp" dev=sda5 ino=797943 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file
and on shutdown from kdm screen:
type=AVC msg=audit(1285707291.845:10): avc: denied { ioctl } for pid=1534 comm="shutdown" path="/var/log/kdm.log" dev=sda5 ino=664036 scontext=system_u:system_r:shutdown_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_log_t:s0 tclass=file
I also found a kde-settings update still waiting. I don't know whether it was that or the relabel but i am now not getting any denials related to kdm_greet. If i start getting them again i will update this bug. Appears to be a probe of some kind:
1696 1285712445.851922 stat64("/usr/libexec/kde4/drkonqi", {st_mode=S_IFREG|0755, st_size=583176, ...}) = 0
1696 1285712445.852206 lstat64("/usr/libexec/kde4/drkonqi", {st_mode=S_IFREG|0755, st_size=583176, ...}) = 0
1696 1285712445.852464 access("/usr/libexec/kde4/drkonqi", R_OK) = 0
1696 1285712445.852611 access("/usr/libexec/kde4/drkonqi", W_OK) = -1 EACCES (Permission denied)
1696 1285712445.853564 access("/usr/libexec/kde4/drkonqi", X_OK) = 0
Not sure where in the code this is coming from yet.
My guess at the moment is that this comes from KStandardDirs::findExe(). So what happens here is that KStandardDirs::checkExecutable uses QFileInfo. In Qt 4.7, QFileInfo was changed to do some checks in the constructor and return cached values instead of only checking when requested. So this is a Qt 4.7 issue, not a KDE 4.5 issue. (As you'll notice, the original report was with KDE 4.4.3!) Coming at it from the other end, looks the the Qt function QFSFileEnginePrivate::getPermissions() will call access(,W_OK) to check write permissions on file. Somewhere, somebody is probably (unnecessarily) checking for all the permissions on files instead of just what is needed. That's it for me today. Actually, I don't think the checks are in the constructor (though that has to be checked, too: there's some caching involved too and I haven't checked whether the constructor tries to fill the cache), but what happens is that if you request ANY check from QFileInfo, e.g. isExecutable, it'll always do (a stat and) all 3 access checks (with R_OK, W_OK and X_OK). See QFSFileEnginePrivate::getPermissions at line 765 of http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/io/qfsfileengine_unix.cpp (new function in 4.7). Request ANY flag (which also includes all the flags in stat, not just the 3 access flags) and it'll check them all. SELinux doesn't like that. 4.6 would do only the requested check. Needless to say, a lot of Qt-using code, especially kdelibs, uses QFileInfo. We may have to patch Qt to revert this "feature" wholesale. One quick hack might be to skip the write check in QFileInfo if the path matches some regex such as "^(/usr)?/(bin|lib(64|exec)?|share)" (QRegExp also supports non-capturing parentheses – (?:foo) instead of (foo) – which may be faster). (That'd probably also work around the KConfig write checks where the KDE code actually checks isWritable, which have been the subject of previous SELinux AVCs and which are currently papered over by selinux-policy.) Upstream report filed: http://bugreports.qt.nokia.com/browse/QTBUG-14039 There is a kernel fix coming from eparis that can differentiate from an access(W_OK) from an actual attempt to write. This fix will allow us to write better policy to allow apps to actually do this type of checking. Dan, what's the eta on that? Is it something we can count on to address this in time for f14 or should we explore alternatives in the meantime? Eric?
I can add some dontaudit rules for f14 also
dontaudit xdm_t { usr_t bin_t }:file write;
Should handle it.
Unfortunately, the scope of this goes way beyond just kdm, it affects any application using Qt's api for checking file access rights. Well luckily most people run user apps as unconfined_t which would be allowed this access, and would not generate the AVC. The only App I seeing this with currently is kdm apps running as xdm_t. The new audit_access permission isn't present until 2.6.36 so what you propose in comment 28 is the best we can do in f14. f15 you'd want: dontaudit xdm_t { usr_t bin_t }: file audit_access; Fixed in selinux-policy-3.9.5-8.fc14 Hopefully someone will remind me to make this change in f15. *** Bug 625367 has been marked as a duplicate of this bug. *** marking this one as an F14 Blocker, as the dupe (625367) was one. THis was discussed at the 2010-10-01 blocker review meeting. We accept it as a blocker under the criterion "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)". Dan, can you push -8 as an update soon? Thanks! updating summary to be slightly less ambiguous (now that's it's been reassigned away from qt) selinux-policy-3.9.5-10.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/selinux-policy-3.9.5-10.fc14 selinux-policy-3.9.5-10.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. (In reply to comment #38) > selinux-policy-3.9.5-10.fc14 has been pushed to the Fedora 14 stable > repository. If problems still persist, please make note of it in this bug > report. Shouldn't this have shown up in the repos by now? Looks like both of these were pushed stable at the same time: https://admin.fedoraproject.org/updates/selinux-policy-3.9.5-7.fc14 https://admin.fedoraproject.org/updates/selinux-policy-3.9.5-10.fc14 and whichever one that gets tagged last wins. I'll fix the tagging so that this gets fixed on the next updates push. The karma on -10 was a little too fast. :^) Removing external tracker bug with the id '14039' as it is not valid for this tracker |