In Gentoo, start_kdeinit is running with root priviledges, while on other distributions its launched from standard user account. From what i have managed to find out on #kde-devel this should NOT be launched from root account, and Gentoo seems the very only one distribution that applies this. Reproducible: Always Steps to Reproduce: 1. Start KDE 4 2. In console, as root write: ps aux | grep start_kdeinit Actual Results: root 3047 0.0 0.0 3732 84 ? S 21:13 0:00 /usr/lib64/kde4/libexec/start_kdeinit +kcminit_startup Expected Results: [your_user_name] 3047 0.0 0.0 3732 84 ? S 21:13 0:00 /usr/lib64/kde4/libexec/start_kdeinit +kcminit_startup [22:25:19] <thiago_home> hmm... I saw something weird in one of your earlier pastes [22:26:14] <thiago_home> root 3047 0.0 0.0 3732 84 ? S 21:13 0:00 /usr/lib64/kde4/libexec/start_kdeinit +kcminit_startup [22:26:44] <thiago_home> why is that running as root? [22:26:53] <Belliash> i got not idea [22:27:45] <thiago_home> that sounds like the problem to me [22:27:56] <PovAddict> I saw that too [22:28:04] <PovAddict> I should have mentioned it :/ [22:33:20] <PovAddict> nicolas 2658 0.0 0.0 3764 80 ? S Apr27 0:00 /usr/lib/kde4/libexec/start_kdeinit +kcminit_startup [22:33:22] <PovAddict> on debian [22:33:31] <sandsmark> that looks more normal
Please don't CC teams on your own
Behaviour confirmed, reason still unclear
173 if (CMAKE_SYSTEM_NAME MATCHES Linux) 174 MESSAGE(STATUS "Using setuid root kdeinit wrapper in order to protect it from bad Linux OOM-killer") 175 set(KDEINIT_OOM_PROTECT 1) 176 install(CODE " 177 set(START_KDEINIT_PATH \"\$ENV{DESTDIR}${LIBEXEC_INSTALL_DIR}/start_kdeinit\") 178 EXECUTE_PROCESS(COMMAND sh -c \"chown 0 '\${START_KDEINIT_PATH}' && chmod u+s '\${START_KDEINIT_PATH}'\") 179 ") 180 endif (CMAKE_SYSTEM_NAME MATCHES Linux) Looks like it's intended to do that. kdelibs-4.6.2/kinit/CMakeLists.txt
Applied in all versions for overlay.
Patch removing the suid bit applied in kdelibs-4.6.2-r3 (about to be stabilized). @security: this was intended behaviour from the start, not really a bug... we have removed the suid bit now anyway. we (kde) think you can close this report.
(In reply to comment #5) > @security: this was intended behaviour from the start, not really a bug... we > have removed the suid bit now anyway. we (kde) think you can close this report. Did this gentoo-specific configuration allow an unprivileged user to elevate privileges somehow? Were any user specified commands run as root? Thanks.
Well, most distributions doesn't have suid set on this and everything works perfectly. Why Gentoo should? To make KDE users more vulnerable? Everytime it's told to not launch KDE as root - but you force ppl to launch it core part with root priviledges. About OOM - afaik it has been implemented in kdeinit4 and i will allow myself to quote another Gentoo developer: <scarabeus> protecting from oom rooting the service is stupid anyway <scarabeus> so dont worry it wont break anything
(In reply to comment #6) > (In reply to comment #5) > > @security: this was intended behaviour from the start, not really a bug... we > > have removed the suid bit now anyway. we (kde) think you can close this report. > > Did this gentoo-specific configuration allow an unprivileged user to elevate > privileges somehow? Were any user specified commands run as root? Thanks. Not to my knowledge (but I am no C guru neither specialist for programming setuid stuff). We just used the unmodified upstream setting. The program is designed by upstream to * protect processes from the oom killer * drop privileges * and then exec further stuff [23:55:17] -*- thiago_home doesn't run make install as root, so he has no setuid root executables [23:55:35] -*- bcooksley is the same [23:55:53] <thiago_home> most distros probably build it as non-root [23:56:02] <dilfridge> we dont build as root either... [23:56:23] <thiago_home> if the file is setuid root, then you made install as root [23:56:31] <dilfridge> long story [23:56:52] <dilfridge> 173 if (CMAKE_SYSTEM_NAME MATCHES Linux) [23:56:52] <dilfridge> 174 MESSAGE(STATUS "Using setuid root kdeinit wrapper in order to protect it from bad Linux OOM-killer") [23:56:52] <dilfridge> 175 set(KDEINIT_OOM_PROTECT 1) [23:56:52] <dilfridge> 176 install(CODE " [23:56:52] <dilfridge> 177 set(START_KDEINIT_PATH \"\$ENV{DESTDIR}${LIBEXEC_INSTALL_DIR}/start_kdeinit\") [23:56:52] <dilfridge> 178 EXECUTE_PROCESS(COMMAND sh -c \"chown 0 '\${START_KDEINIT_PATH}' && chmod u+s '\${START_KDEINIT_PATH}'\") [23:56:52] <dilfridge> 179 ") [23:56:52] <dilfridge> 180 endif (CMAKE_SYSTEM_NAME MATCHES Linux) [23:57:06] <bcooksley> installation though is a different story - opensuse at least is setsuid for that executable [23:57:18] <dilfridge> kdelibs/kinit/CMakeLists.txt [23:57:18] <thiago_home> ok, then it is setuid root intentionally
(In reply to comment #7) > Well, most distributions doesn't have suid set on this and everything works > perfectly. Why Gentoo should? To make KDE users more vulnerable? Everytime it's > told to not launch KDE as root - but you force ppl to launch it core part with > root priviledges. > Thanks for the input, Rafal. I agree this is less secure, and not ideal. However, I don't think this is a vulnerability per se. Taking advantage of this would require the presence of a vulnerability similar to CVE-2008-1671 / GLSA 200804-30. @kde, is this something we can get into the stable series of kdelibs 4.4?
(In reply to comment #9) > (In reply to comment #7) > > Well, most distributions doesn't have suid set on this and everything works > > perfectly. Why Gentoo should? To make KDE users more vulnerable? Everytime it's > > told to not launch KDE as root - but you force ppl to launch it core part with > > root priviledges. > > > > Thanks for the input, Rafal. I agree this is less secure, and not ideal. > However, I don't think this is a vulnerability per se. Taking advantage of this > would require the presence of a vulnerability similar to CVE-2008-1671 / GLSA > 200804-30. > > @kde, is this something we can get into the stable series of kdelibs 4.4? Is it worth putting into 4.4? would not be easier to just push 4.6 forward as it is already being stabilised? (1 hour pointless compilation for kdelibs just to fix highly theoretical security issue is not something our users would love us for)
Ajusting severity cause i cant see reason why this should be critical.
> @kde, is this something we can get into the stable series of kdelibs 4.4? Not worth bothering. Bug 354033 is the stablerequest for KDE 4.6, and has been submitted to arches already a week ago. We just resolved the last real blocker (I hope).
(In reply to comment #12) > > @kde, is this something we can get into the stable series of kdelibs 4.4? > > Not worth bothering. Bug 354033 is the stablerequest for KDE 4.6, and has been > submitted to arches already a week ago. We just resolved the last real blocker > (I hope). Perfect, thank you.
http://forums.gentoo.org/viewtopic-t-876693.html Is this related? Thats the only one process from KDE running as root i have noticed.
(In reply to comment #11) > Ajusting severity cause i cant see reason why this should be critical. So gaining root access isnt critical for you? Something already uses that hole for creating files and folders under / (root owned), and you say it isn't critical? Maybe i shouldn't create nornal user and launch everything as root then?!
Please stop messing with prorities when you don't know what you are doing. It is not critical as there is no currently known exploit for start_kdeinit and from what i see in code it probably even ain't possible to do so. As I said that thing runs like that for OOM protection which is stupid move, but not fatal.
KDE 4.6 containing the patch is stable on all arches. kdelibs-4.4 has been removed from the tree. @security: imho this can be resolved.
(In reply to comment #17) > KDE 4.6 containing the patch is stable on all arches. > kdelibs-4.4 has been removed from the tree. > > @security: imho this can be resolved. Agreed. Thanks for your help on this.
