Bug 1686675 - sddm crashes on first boot of a fresh Rawhide KDE install (due to SELinux execmod denial)
Summary: sddm crashes on first boot of a fresh Rawhide KDE install (due to SELinux exe...
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: x86_64
OS: All
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
Whiteboard: openqa
Depends On:
Blocks: F31BetaBlocker
TreeView+ depends on / blocked
Reported: 2019-03-08 01:22 UTC by Adam Williamson
Modified: 2019-04-05 17:58 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-04-05 17:58:46 UTC
Type: Bug

Attachments (Terms of Use)
backtrace from the crash (56.33 KB, text/plain)
2019-03-08 01:24 UTC, Adam Williamson
no flags Details
SELinux warning (2.80 KB, text/plain)
2019-03-10 10:03 UTC, Mattia Verga
no flags Details

Description Adam Williamson 2019-03-08 01:22:28 UTC
In Fedora-Rawhide-20190306.n.1, all KDE install tests failed. Both the KDE live image and generic netinst image boot fine and can install a KDE system, but the installed system boots to a black screen with a cursor.

You can log in to a tty, where you find traces of an sddm-greeter crash, with error "stack smashing detected". I will attach a full trace. This is fully reproducible - you can download https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190306.n.1/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20190306.n.1.iso , install it (create a user during install), try to boot the installed system, and you should see the crash.

Proposing as an F31 Beta blocker per "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" - https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior .

Comment 1 Adam Williamson 2019-03-08 01:24:51 UTC
Created attachment 1542008 [details]
backtrace from the crash

Comment 2 Rex Dieter 2019-03-10 01:13:43 UTC
From backtrace,

Appears to be some qml/jsruntime JIT issue (in qt5-qtdeclarative I assume):

Thread 1 (Thread 0x7f16c3e6cdc0 (LWP 1220)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {0, 139735806113624, 94740190158032, 139735805972696, 94740190158032, 94740190202768, 94740190158032, 139735806122898, 139735368281656, 25473869312, 139735367981808, 0, 139735368401760, 0, 0, 139735808783288}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007f16c6b1c8b5 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x7ffce9f01570, sa_sigaction = 0x7ffce9f01570}, sa_mask = {__val = {139735805931910, 4294967295, 9324068073094538752, 94740188721824, 1, 140724233311600, 140724233311600, 94740189191664, 139735819755637, 94740189191664, 140724233311600, 94740186923936, 9324068073094538752, 1, 94740189191664, 94740186924336}}, sa_flags = -370141840, sa_restorer = 0x7f16c73e9068 <QCoreApplication::self>}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f16c6b75377 in __libc_message (action=<optimized out>, fmt=fmt@entry=0x7f16c6c838b4 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181
        ap = {{gp_offset = 32, fp_offset = 32764, overflow_arg_area = 0x7ffce9f01660, reg_save_area = 0x7ffce9f015f0}}
        fd = <optimized out>
        list = <optimized out>
        nlist = <optimized out>
        cp = <optimized out>
        written = <optimized out>
#3  0x00007f16c6c05d85 in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=false, msg=msg@entry=0x7f16c6c83892 "stack smashing detected") at fortify_fail.c:28
No locals.
#4  0x00007f16c6c05d38 in __stack_chk_fail () at stack_chk_fail.c:29
No locals.
#5  0x00007f16c7d56ffb in QV4::JIT::PlatformAssemblerCommon::link (this=<optimized out>, function=0x562a6b5224e0, jitKind=jitKind@entry=0x7f16c7ed4d8c "BaselineJIT") at ../3rdparty/masm/stubs/ExecutableAllocator.h:167
        dummy = {executableAllocator = {realAllocator = 0x562a6b654e30}}
        linkBuffer = {<JSC::LinkBufferBase<JSC::MacroAssembler<JSC::MacroAssemblerX86_64>, JSC::DefaultExecutableOffsetCalculator>> = {m_executableMemory = {m_ptr = 0x562a6b623760}, m_size = 1350, m_code = 0x7f16a41f3000, m_assembler = 0x562a6b615f68, m_globalData = 0x7ffce9f016c0}, <No data fields>}
        codeRef = <optimized out>
        showCode = false
        doProfile = false
#6  0x00007f16c7d488d3 in QV4::JIT::BaselineAssembler::link (this=<optimized out>, function=<optimized out>) at jit/qv4baselineassembler.cpp:849
No locals.
#7  0x00007f16c7d480f9 in QV4::JIT::BaselineJIT::generate (this=0x7ffce9f017e0) at jit/qv4baselinejit.cpp:72
        code = 0x7f16a43211a0 <error: Cannot access memory at address 0x7f16a43211a0>
        len = 103
#8  0x00007f16c7ccd5af in QV4::Moth::VME::exec (frame=frame@entry=0x7ffce9f01860, engine=engine@entry=0x562a6b655cb0) at jsruntime/qv4vme_moth.cpp:428
        _executionEngineCallDepthRecorder = {ee = 0x562a6b655cb0}
        function = 0x562a6b5224e0
        profiler = {profiler = 0x0, function = 0x7f16adc99e40, startTime = 139735084054224}
        debugger = <optimized out>
        result = 140724233312256
#9  0x00007f16c7cd16ed in QV4::Module::evaluate (this=this@entry=0x7f16adc99e38) at jsruntime/qv4module.cpp:125
        unit = <optimized out>
        v4 = 0x562a6b655cb0
        moduleFunction = 0x562a6b5224e0
        frame = {engine = 0x562a6b655cb0, savedStackTop = 0x7f16adc99e40, parent = 0x0, v4Function = 0x562a6b5224e0, jsFrame = 0x7f16adc99e40, originalArguments = 0x0, originalArgumentsCount = 0, instructionPointer = 0, yield = 0x0, unwindHandler = 0x0, unwindLabel = 0x0, unwindLevel = 0, yieldIsIterator = false, callerCanHandleTailCall = false, pendingTailCall = false}
        frameCleanup = <optimized out>
#10 0x00007f16c7d9cdd1 in QQmlScriptData::scriptValueForContext (parentQmlContextData=<optimized out>, this=0x7f169c0d9ad0) at qml/qqmltypeloader.cpp:2959
        v4 = 0x562a6b655cb0
        qmlExecutionContext = {ptr = 0x7f16adc99e30}
        module = {ptr = 0x7f16adc99e38}
        value = <optimized out>
        scope = {engine = 0x562a6b655cb0, mark = 0x7f16adc99e30}
        qmlContextData = <optimized out>
        v4 = <optimized out>
        scope = <optimized out>
        qmlContextData = <optimized out>
        qmlExecutionContext = <optimized out>
        module = <optimized out>
        value = <optimized out>
        error = <optimized out>

Comment 3 Rex Dieter 2019-03-10 01:14:25 UTC
May have to work to get Qt 5.12.x available for f30 testing sooner rather than later, I believe it does resolve at least several issues related to newer gcc.

Comment 4 Rex Dieter 2019-03-10 01:16:10 UTC
Oh, sorry for the spam, this is about rawhide/f31, which should have Qt 5.12.x already, sigh :(

Comment 5 Mattia Verga 2019-03-10 09:53:16 UTC
I suspect this is due to #1667171.

To prove that:
- change to vty2, login as root and set "setenforce 0"
- systemctl restart sddm

This will bring sddm up

Comment 6 Mattia Verga 2019-03-10 10:03:14 UTC
Created attachment 1542505 [details]
SELinux warning

Well, actually the SELinux message is quite different from the one in the above bug, I'll attach it here.

Comment 7 Rex Dieter 2019-03-10 13:03:17 UTC
The important part,
type=AVC msg=audit(1552211962.890:178): avc:  denied  { execmod } for  pid=991 comm="sddm-greeter" path=2F6D656D66643A4A4954436F64653A2F6C696236342F6C6962517435516D6C2E736F2E35202864656C6574656429 dev="tmpfs" ino=29321 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=0

indeed, that may very well be it.

Comment 8 Lukas Vrabec 2019-03-12 17:59:40 UTC

This looks suspicious, with execmod you make executable a file that has been modified by copy-on-write. Which is some temp file create by some user. Does anyone know whats going on?

Comment 9 Martin Bříza 2019-03-12 18:32:36 UTC
Hey, I'm not sure and can't really check ATM but I'm convinced the weird file could be related to how QML works now in Qt. There's some kind of JIT or maybe even ahead of the time compilation of the QML files to improve startup performance. It could be worth looking into how disable that for SDDM.

But again, I didn't really look into this too deep, I'm reacting based on what came into my email at this moment.

Comment 10 Lukas Vrabec 2019-03-14 10:02:21 UTC
This should be solved on SDDM side, from security POV, it's not safe to allow.

Comment 11 Martin Bříza 2019-03-14 10:40:08 UTC
Can you please test if putting QML_DISABLE_DISK_CACHE=1 into the environment fixes this issue?

Comment 12 Martin Bříza 2019-03-14 10:44:22 UTC
It may need to be "true" actually

Comment 13 Pier Luigi Fiorini 2019-03-14 11:32:03 UTC
This indeed seem to be what Qt recommend: https://bugreports.qt.io/browse/QTBUG-58508

If setting this environment variable works, I will gladly set in the greeter main() and release the hot fix with SDDM 0.18.1

Comment 14 Rex Dieter 2019-03-14 13:29:25 UTC
Build with that workaround on the way for testing,

Comment 15 Fedora Update System 2019-03-14 14:25:57 UTC
sddm-0.18.0-5.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-aa37ca72c6

Comment 16 Rex Dieter 2019-03-14 14:27:12 UTC
To clarify, is this denial specific to f31+ , or could affect previous fedora releases as well?

Comment 17 Mattia Verga 2019-03-14 17:10:06 UTC
Neither installing sddm-0.18.0-5 or manually exporting QML_DISABLE_DISK_CACHE=1 or QML_DISABLE_DISK_CACHE=true seems to work. I still get the same SELinux denial.
This is on a F31 virtual machine.

Is it correct to do a "export QML_DISABLE_DISK_CACHE=1" in vty2 as root and then restart sddm service (which runs on vty1)?

Comment 18 Rex Dieter 2019-03-14 17:18:55 UTC
Pretty sure systemd services will not pick up any user environment, which is why I implemented it the systemd service file.

Comment 19 Adam Williamson 2019-03-14 17:38:40 UTC
Mattia: did you reboot after installing the -5 package?

Comment 20 Fedora Update System 2019-03-14 20:59:29 UTC
sddm-0.18.0-5.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-aa37ca72c6

Comment 21 Rex Dieter 2019-03-15 15:34:59 UTC
I can confirm this affects f30 with Qt 5.12.x as well,

Can we rebase this to f30 (or prefer a separate bug)?

Comment 22 Rex Dieter 2019-03-15 16:26:43 UTC
Further testing, it appears that setting QML_DISABLE_DISK_CACHE=1 via sddm.service isn't doing what we want.  I can see
repopulating with content performing 'systemctl start sddm'

It appears to be an important Qt 5.12 feature for 

As a compromise, can selinux allow this under the specific locations used?  Per
"Each time you load a changed QML document, the cache is automatically re-created. Cache files are located in a sub-directory of QStandardPaths::CacheLocation with the name "qmlcache". The file extension is .qmlc for QML documents and .jsc for imported JavaScript modules."

In this context, CacheLocation is under $XDG_CACHE_DIR , which defaults to $HOME/.cache

Comment 23 Mattia Verga 2019-03-15 17:05:56 UTC
(In reply to Adam Williamson from comment #19)
> Mattia: did you reboot after installing the -5 package?

Yes, I did

Comment 24 Rex Dieter 2019-03-15 17:08:10 UTC
Adding an explicit qputenv in sddm's Greeter.app.cpp and now no cdqmlcache is generated, but sddm startup still fails, so perhaps qmlcache is not to blame afterall. ??

Comment 25 Adam Williamson 2019-03-15 17:35:22 UTC
Do SELinux denials still show up? The same ones?

Comment 26 Rex Dieter 2019-03-16 00:40:03 UTC
Yes and yes, respectively

Comment 27 Rex Dieter 2019-03-22 14:53:47 UTC
Reassigning to qt5-qtdeclarative, that's where the JIT lives, since that's our best-guess what's at issue here.

Ideally and personally, selinux policy will likely need adjustment to allow this somehow.  Disabling the JIT is most likely not be practical, if we want kde/plasma to be reliable and functional.

Comment 28 Rex Dieter 2019-03-22 17:52:13 UTC
Per comment #27 , I'll reach out to Qt upstream to verify if this is intended behavior or not (I assume yes, but would like to confirm).

In the meantime, selinux-policy maintainers please explore what it would take to remediate this on the policy side, thanks.

Comment 29 Lukas Vrabec 2019-03-25 17:18:49 UTC
commit 75b1d69bcb42ed22a86399a638615ea0e3e0b44d (HEAD -> rawhide)
Author: Lukas Vrabec <lvrabec>
Date:   Mon Mar 25 18:18:23 2019 +0100

    Allow xdm_t domain to create own tmp files BZ(1686675)

Comment 30 Rex Dieter 2019-03-25 17:57:59 UTC
I suspect that change alone will not be sufficient... it may allow sddm to function, but any other application using QML will likely to fail similarly (including plasmashell).

Comment 31 Lukas Vrabec 2019-03-27 17:43:35 UTC
I needed to change the fix: 

commit b449b264e39f381beef1cb99977f543731972c64 (HEAD -> rawhide, origin/rawhide)
Author: Lukas Vrabec <lvrabec>
Date:   Wed Mar 27 18:42:55 2019 +0100

    Allow xdm_t domain to execmod temp files BZ(1686675)

Comment 32 Rex Dieter 2019-04-02 19:22:58 UTC
Any ETA for a similar fix to land for f30?

Comment 33 Adam Williamson 2019-04-02 19:46:28 UTC
and what about the concern raised in #c30?

Comment 34 Lukas Vrabec 2019-04-03 12:30:08 UTC
(In reply to Rex Dieter from comment #32)
> Any ETA for a similar fix to land for f30?

I'll create new builds in these days.

(In reply to Adam Williamson from comment #33)
> and what about the concern raised in #c30?

Do we have any similar existing issue? 


Comment 35 Rex Dieter 2019-04-03 13:58:20 UTC
I strongly suspect all consumers of Qt5's QML JIT could be affected by this, but I can't confirm until I have a policy to test.  Once you have that built, let us know, and I'll be able to confirm/deny that theory.

Comment 36 Adam Williamson 2019-04-03 23:28:23 UTC
The builds attempted today all failed, with this error:

BUILDSTDERR: libsepol.expand_filename_trans: Conflicting name-based type_transition xguest_t cache_home_t:dir "fontconfig":  cache_home_t vs user_fonts_cache_t
BUILDSTDERR: libsepol.expand_module: Error during expand
BUILDSTDERR: /usr/bin/semodule_expand:  Error while expanding policy
BUILDSTDERR: make: *** [Rules.modular:205: validate] Error 1

Looks like a mistake in the change marked "Allow fontconfig file transition for xguest_u user".

Comment 37 Adam Williamson 2019-04-03 23:32:34 UTC
Looks like https://github.com/fedora-selinux/selinux-policy-contrib/pull/102 is the fix for this, I guess, but I'll leave it to Lukas to fix up tomorrow...

Comment 38 Lukas Vrabec 2019-04-04 15:58:14 UTC
Issue should be fixed in the latest selinux-policy package for rawhide.

Comment 39 Mattia Verga 2019-04-05 16:01:30 UTC
I confirm SDDM now is displayed correctly at startup. I haven't seen any other problem as suggested in comment #35, but I don't know exactly what other applications use QML JIT and can be affected.

Comment 40 Rex Dieter 2019-04-05 16:06:23 UTC
I too can confirm both sddm and plasmashell session performs well with selinux-policy-3.14.3-27.fc30.  Thanks!

Once selinux-policy-3.14.3-27.fc30 lands in f30 updates-testing, we can send the Qt 5.12 back to -testing as well.

Comment 41 Lukas Vrabec 2019-04-05 16:08:39 UTC
Great, thanks for testing.

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