Page MenuHomePhabricator

su not working under kernel 4.11
Closed, ResolvedPublic

Description

Hello,

I'm running efl-1.19.0 and e-0.21.7 under Debian unstable. Since upgrading the Linux kernel from latest 4.10 to 4.11 I cannot run "su" under X any more. "su" on console works perfectly though.

~$ su
su: Authentication failure

~$ sudo ls
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

Also, the Cpufreq module cannot set the cpu power state setting.

This issue has already been reported on e-users mailing list and has also been discussed on a gentoo forum without a solution: https://forums.gentoo.org/viewtopic-p-8064594.html

I'd be happy to help debug this issue or provide more information about my system.

Cheers, Andreas.

ak created this task.May 7 2017, 2:52 AM
bu5hm4n added a subscriber: bu5hm4n.May 7 2017, 6:36 AM

Can you post the output of 'strace su' ?

Your error message of sudo looks like something with your user ids / fs is somehow messed up...

ak added a comment.May 7 2017, 9:26 AM

There is nothing wrong with user IDs and FS. sudo works perfectly on console as well as under XFCE. It worked with enlightenment, too, but fails with latest kernel 4.11.

I'll attach the "strace su" output.

raster added a subscriber: raster.May 7 2017, 6:53 PM

as per e devel list mail discussions - kernel has started disabling setuid root apps somehow. ask kernel maintainers. efl and e have not changed. they do not go implement or enforce anything like seccomp or such sandboxing. the kernel broke userspace somehow.

xanadu added a subscriber: xanadu.May 14 2017, 9:59 AM

I can confirm the problem with kernel 4.11 and wanted to ask if anybody filed a bug report at kernel.org.

EmilMedve added a subscriber: EmilMedve.EditedMay 17 2017, 9:31 AM

It seems that enlightenment_start is ptrace-ing all its child processes and (root) suid binaries won't change their euid to 0 causing sudo, pam, etc. unusable. I can reproduce this specific scenario on other kernel versions ('strace -o /dev/null sudo ls' from a console/tty). I wonder why this isn't visible with enlightenment_start for kernels <v4.11

Cheers,

raster added a subscriber: cedric.May 17 2017, 9:40 AM

well it's ptracing just enlightenment... not all children. we ptrace e for catching segfaults...

Hmm... Seems you're right: /proc/*/status:TracerPid is non-zero only for enlightenment. However, as soon as I start a shell outside enlightenment_start's tree, suid starts working as expected. I bet this is some systemd supporting patch that makes the entire process group inherit something unexpected (?) from the leader

Cheers,

If its a systemd patch, why is it starting with linux 4.11 ... ?

Also, does this happen when you start enlightenment via startx ? i dont think that enlightenment_start is the leader process of the session when started so ...

Btw. what is ls /usr/bin/sudo for you (thats my local path i dont know if its the same for you :) )

Since you run systemd can you post the log of your journal for that boot ?

If its a systemd patch, why is it starting with linux 4.11 ... ?

The assumption is not a systemd patch, but a kernel patch, applied in the v4.11 cycle, in support of some systemd feature... I reverted back to v4.10(.16) (i.e. everything else being the same; except inherent defconfig differences) and things are working fine

Also, does this happen when you start enlightenment via startx ? i dont think that enlightenment_start is the leader process of the session when started so ...

Even with startx, I start e with enlightenment_start (via ~/.xinitrc). I believe trying to start directly with enlightenment will get you an advice about starting with enlightenment_start, but I guess you could force it to start on its own

Btw. what is ls /usr/bin/sudo for you (thats my local path i dont know if its the same for you :) )

Same for me, with -rws--x--x. I don't think sudo is an issue, as this can be reproduced with other suid binaries: unix_chkpwd(pam), etc.

Also, does this happen when you start enlightenment via startx ? i dont think that enlightenment_start is the leader process of the session when started so ...

Even with startx, I start e with enlightenment_start (via ~/.xinitrc). I believe trying to start directly with enlightenment will get you an advice about starting with enlightenment_start, but I guess you could force it to start on its own

Btw. what is ls /usr/bin/sudo for you (thats my local path i dont know if its the same for you :) )

Same for me, with -rws--x--x. I don't think sudo is an issue, as this can be reproduced with other suid binaries: unix_chkpwd(pam), etc.

Yep. Maybe some kernel stuff reflects in the fs and the s bit would be gone ...

Can you try:

"enlightenment -i-really-know-what-i-am-doing-and-accept-full-responsibility-for-it"

This should start e without ptracing ... :)

Will give it a shot...

I'm being overly optimistic just now, but I'm tempted to bisect the kernel...

Cheers,

I already ran a git bisect. This is the affecting patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=20523132ec5d1b481e1d66557292ed3a3021e817

Kernel bug still silent: https://bugzilla.kernel.org/show_bug.cgi?id=195799
As instructed on gentoo forum, I will send an email to linux-security-module@vger.kernel.org if nothing changes in few days.

EmilMedve added a comment.EditedMay 18 2017, 8:42 AM

Starting e directly:

E_START=enlightenment enlightenment -i-really-know-what-i-am-doing-and-accept-full-responsibility-for-it

makes the issue go away. So I guess that brings it down to sync-ing enlightenment_start with whatever the above patch means

Cheers,

Okay, this is super weird, i think there is a kernel bug there the tracer pid of a process is not NULLed out anymore - But i am not sure if thats a bug in the kernel or if its us doing some wrong ptrace ops ...

(I have not found anything in the man page of ptrace that could indicate something weird there ...)

could you check in some app, started in e with the bug, what the TracerPid of /proc/<pidof that app>/status tells you?

could you check in some app, started in e with the bug, what the TracerPid of > /proc/<pidof that app>/status tells you?

Checked it the other day (see one of the comments above): only e has the TracerPid different from zero (enlightenment_start's PID)

Cheers,

Sorry - didnt see it :)

Okay a bit more information.

It seems commit 9227dd2a84a765fcfef1677ff17de0958b192eda in the linux kernel removes LSM_UNSAFE_PTRACE_CAP and only uses LSM_UNSAFE_NO_NEW_PRIVS the problem here is that this means that a execped process from this point on CANNOT get any higher priviliges than before. The question if this is a linux bug or new feature is still unanswered.

Anyway, does someone know if we can still ptrace a zombie process?

Hum, weird things is that the ptrace should only be on the enlightenment process not on any of it child. Maybe we have a bug here, but last time I looked at that code, we were not getting anything from any child after a fork.

I already ran a git bisect. This is the affecting patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=20523132ec5d1b481e1d66557292ed3a3021e817

Kernel bug still silent: https://bugzilla.kernel.org/show_bug.cgi?id=195799
As instructed on gentoo forum, I will send an email to linux-security-module@vger.kernel.org if nothing changes in few days.

Did you try contacting the author of that patch ? If you didn't I should do as I did write the code that use ptrace.

No I didn't contact him. To be honest all these are pretty new for me. Received a LOT of help on Gentoo forum and... just followed the yellow bricks.

This is really great! thanks @costel78 for the bisecting. this really has helped point out something concrete... it's something to chase up. i think that this is simply a kernel change made without knowing some impact it may have like on us because of the way we trap crashes in order to grab backtraces. they likely didn't know anyone does anything like this so didn't think it'd be an issue. it's now worth chasing up with the appropriate kernel devs.

openSUSE tumbleweed now has kernel 4.11 and also hits the issue, we have some pretty responsive kernel devs so hopefully they can help although i'm traveling much of next week.

The original Author has committed a follow up patch that should fix the issue (I'm in the process of confirming)

For some reason I didn't include a link to that patch https://bugzilla.suse.com/attachment.cgi?id=726016

ApB added a subscriber: ApB.May 23 2017, 12:47 PM

On wayland you cant unlock E after it locks. Fun stuff ?

davek added a subscriber: davek.May 23 2017, 8:24 PM
In T5470#87631, @ApB wrote:

On wayland you cant unlock E after it locks. Fun stuff ?

Well that sounds like a different bug that probably deserves its own ticket.

TwoD added a subscriber: TwoD.May 24 2017, 5:13 AM
In T5470#87631, @ApB wrote:

On wayland you cant unlock E after it locks. Fun stuff ?

Well that sounds like a different bug that probably deserves its own ticket.

Maybe, but I have the same issue under X after updating to kernel 4.11 and EFL-git and E-git today.

In T5470#87668, @TwoD wrote:
In T5470#87631, @ApB wrote:

On wayland you cant unlock E after it locks. Fun stuff ?

Well that sounds like a different bug that probably deserves its own ticket.

Maybe, but I have the same issue under X after updating to kernel 4.11 and EFL-git and E-git today.

Yeah it could be related, I still can but i'm also running a kernel with that bug fixed.

In T5470#87631, @ApB wrote:

On wayland you cant unlock E after it locks. Fun stuff ?

Well that sounds like a different bug that probably deserves its own ticket.

Most systems are configured to use PAM to unlock (though E can be configured otherwise). PAM uses suid binaries, which *is* the issue/symptom at hand

fanf42 added a subscriber: fanf42.May 30 2017, 3:31 AM

I can confirm that with kernel linux 4.11:

  • I have the su/sudo problem,
  • I can't unlock my locked screen if the configuration in "sceen -> lock screen" is set to "use system authentication"

And that reverting to linux 4.10 solve both problems.

A patch for next release of kernel 4.11 is likely going to be backported and would solve this issue. We should let this task open until next release of kernel 4.11. In the mean time if you have a broken kernel, you can try to use this patch.

https://www.spinics.net/lists/stable/msg173879.html

ak closed this task as Resolved.Jun 15 2017, 6:36 AM
ak claimed this task.

This issue has been fixed in linux kernel 4.11.5 by commit ff6c1649b4a15065474adc9b2590ba20c0a62238 ("ptrace: Properly initialize ptracer_cred on fork").