[lxc-users] lxc-usernsexec completely unexpected behaviour, reproducible on trunk?

[Fiedler Roman]

> Von: lxc-users [mailto:lxc-users-bounces at lists.linuxcontainers.org] Im 
> Auftrag
> von Serge Hallyn
>
> Quoting Fiedler Roman (Roman.Fiedler at ait.ac.at):
>
>> I've accidentally destroyed some files due to following unexpected
>> behaviour. Is this also reproducible on trunk?
>
> It is.
> [Snip]
>
>> readlink("/proc/self/fd/0", "/tmp/file", 256) = 40  # don't know why, but
>> stdin link is copied
>
> Because we explicitly opentty(ttyname) on the result (ttyname) of
> readlink on /proc/self/fd/0, where opentty re-opens the tty for
> fds 0-2.
>
> I guess we should open fds 1 and 2 separately, as I can certainly see
> "... < script" as something you'd want to do without wiping out script.

Reopening TTY might make sense, when stdin at the beginning was really a TTY. 
It might make sense to note in the man-pages, that due to that behaviour, 
lxc-usernsexec must NEVER be called via a SUID binary (hoping no one is doing 
that yet), otherwise it is very likely to give local-root privilege 
escalation. The code may somehow fail to detect/handle TTY readlink correctly 
(bug/undefined behaviour like here or TOCTOU while checking). Consider 
following hypothetical (untested) sequence:

cd /tmp
touch ls
ln -s "/bin/ls" "ls (deleted)"
open("ls")
unlink("ls")
[do something to make embedded lxc-usernsexec be more likely to fail, e.g. 
using ulimit, causing memory pressure]
[Call some SUID wrapping lxc-usernsexec with fd to deleted "ls"]

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6344 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20151014/c91105e8/attachment.bin>