From: Stanislav Brabec <sbrabec@suse.cz>
To: "Ángel González" <ingenit@zoho.com>, util-linux@vger.kernel.org
Cc: up201407890@alunos.dcc.fc.up.pt
Subject: Re: Fixing su + runuser vulnerability CVE-2016-2779
Date: Tue, 8 Mar 2016 17:33:37 +0100 [thread overview]
Message-ID: <56DEFEE1.1080507@suse.cz> (raw)
In-Reply-To: <56DA1F2A.5040104@zoho.com>
On Mar 5, 2016 at 00:50 Ángel González wrote:
> I was thinking about this and the problem is actually that runuser
> returns (and control is returned to the privileged parent) while there's
> an unprivileged descendant with a handle to the tty.
> Thus, it seems that it could be solved by having runuser run the child
> into a new cgroup and refusing to return while there's any remaining
> process there.
In general, it is a good idea.
But from compatibility aspect, it is a bad idea to change it to the
default behavior. Imagine all those poorly written legacy helpers that
run daemons without proper disconnecting from the terminal. All those
will be stalled.
I can imagine new --term-wait option, eventually --term-kill. But I am
not sure, whether it is no over-complicated.
> Although depending on the exact way that people is expecting to use job
> control, that might still interefere despite not changing the session
> leader. Do we know actual usages that should continue working?
>
There is not exact list what will will break.
But imagine that many users use daily things like simple example below.
(In a real life, you will not want to run sleep, but something more
sophisticated (e. g. build process inside chroot that needs sudo).)
# sudo -u nobody sleep 10 &
[1] 28327
~ # fg
sudo -u nobody sleep 10
^Z
[1]+ Stopped sudo -u nobody sleep 10
~ # bg
[1]+ sudo -u nobody sleep 10 &
~ #
~ #
[1]+ Done sudo -u nobody sleep 10
~ #
It will be not possible any more with setsid().
You will get:
# sudo -u nobody sleep 10 &
[1] 28390
~ # fg
sudo -u nobody sleep 10
^Z^Z^Z^Z^Z^Z^Z^Z
You are stuck, ^Z does not work, and you cannot switch the task back to
background. You can only press ^C.
Exactly the same will affect
runuser --command "sleep 10"
Additionally, both su and runuser already offer two variants. You can
test the difference yourself:
Without job control:
su nobody --command "sleep 10" &
vs.
With job control:
su nobody --session-command "sleep 10" &
After calling it, type:
fg
and then Control-Z.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com
Lihovarská 1060/12 tel: +49 911 7405384547
190 00 Praha 9 fax: +420 284 084 001
Czech Republic http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
next prev parent reply other threads:[~2016-03-08 16:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 19:35 Fixing su + runuser vulnerability CVE-2016-2779 Stanislav Brabec
2016-03-02 23:39 ` Ángel González
2016-03-03 0:37 ` up201407890
2016-03-03 16:21 ` Stanislav Brabec
2016-03-04 16:13 ` Stanislav Brabec
2016-03-04 18:03 ` up201407890
2016-03-04 23:50 ` Ángel González
2016-03-08 16:33 ` Stanislav Brabec [this message]
2016-03-07 13:13 ` Karel Zak
2016-03-08 16:02 ` Stanislav Brabec
2016-09-29 14:40 ` Karel Zak
2016-10-02 13:16 ` Florian Weimer
2016-10-03 10:28 ` Karel Zak
2016-10-03 13:29 ` Karel Zak
2016-10-09 11:09 ` Florian Weimer
2016-10-03 15:04 ` Karel Zak
2016-10-03 15:48 ` Pádraig Brady
2016-10-03 16:25 ` Karel Zak
2016-10-11 14:19 ` Karel Zak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56DEFEE1.1080507@suse.cz \
--to=sbrabec@suse.cz \
--cc=ingenit@zoho.com \
--cc=up201407890@alunos.dcc.fc.up.pt \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.