[lxc-users] lxc-usernsexec completely unexpected behaviour, reproducible on trunk?
Roman.Fiedler at ait.ac.at
Wed Oct 14 07:57:06 UTC 2015
> Von: lxc-users [mailto:lxc-users-bounces at lists.linuxcontainers.org] Im
> 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.
>> 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:
ln -s "/bin/ls" "ls (deleted)"
[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"]
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6344 bytes
Desc: not available
More information about the lxc-users