[lxc-users] lxc-usernsexec completely unexpected behaviour, reproducible on trunk?
serge.hallyn at ubuntu.com
Fri Oct 16 16:00:40 UTC 2015
Quoting Fiedler Roman (Roman.Fiedler at ait.ac.at):
> > 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.
So would adding a check to isatty() before calling opentty() on each descriptor
> 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)"
> [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"]
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
More information about the lxc-users