Quoting Fiedler Roman (roman.fied...@ait.ac.at):
> > Von: lxc-users [mailto:lxc-users-boun...@lists.linuxcontainers.org] Im
> > Auftrag
> > von Serge Hallyn
> >
> > Quoting Fiedler Roman (roman.fied...@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@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
_______________________________________________
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
