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

[Serge Hallyn]

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
suffice?

> 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



> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users