Re: Multiple disputed issues in util-vserver

[Fiedler Roman <Roman.Fiedler () ait ac at>]

> Von: Fiedler Roman [mailto:Roman.Fiedler () ait ac at]
>
> [Snip]
>
> > > Issue 3: It seems that handling of open tty FDs on enter, that allows
to
> > > inject arbitrary keyboard input to be read by the parent process, also
> > > affects the tool to start the guest container. This seems to be the
same
> > > issue with "vserver start" as reported in [2] for vserver enter, which
> > > was classified as less relevant back than. My rating would be little
lower
> > > than 2 but still quite high for mass hosting: manual restart, e.g.
during
> > > maintenance, seems quite common to me.
> >
> > If I understand correctly, this (and the previous one) are
> > CVE-2005-4890, isn't it?.
> >
> > http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation
>
> Yes, this is the stuff about the general problem, this issue is quite a
> similar one for su. In both cases (su and vserver), a tool used to enter
an
> possibly compromised, lower privileged context from a higher privileged
one
> fail.
>
> The CVE is only for su. For su it seems, that the issue is treated more a
> bug than expected feature, but it seems, that it is still not fixed for
> current Ubuntu release.
>
> For vserver ...
>
> > > From my point of view, those issues might be expected behavior as
claimed by
> > > the developers, ....>
> > > this is the state of discussion, so no bug.
> > > ... but if so it should be at least stated more clearly in
> > > documentation:
> > >
> > > a) never use any tools except vserver stop (to terminate the
container)
> to
> > > interact with a running and possibly compromised container from the
host
> > > b) only use network/socket-based tools to connect to processes inside
a
> > > possibly compromised guest, e.g. SSH.
> > > c) never start a possibly compromised container from interactive shell
> to
> > > avoid injection of shell commands
> > >
> > > Regarding documentation I would even vote for a solution d), that all
> those
> > > tools get a mandatory argument like
> > > '--i-know-entering-insecure-container-may-kill-my-host' so that it is
> not
> > > very likely, that someone will use those tools for something else then
> > > testing or nice-world administration.
> > >
> > > Opinions to issues 1-3?
> > >
> > > What about solutions?
> >
> > Halfdog (CC'ed) already suggested some possible solutions:
> > http://www.paul.sladen.org/vserver/archives/201211/0011.html
>
> This should handle the pty issues. But since it requires the admin not to
> forget to use the manual workaround EVERY TIME, therefore man page update
> should be done in any case. Fix with pty allocation (or detaching from pty
> for vserver start) would be best solution. Without technical fix a
> "--do-it-insecure" parameter would make it clear on command line, that I
> want to proceed knowing the risks.

As there was not really much feedback from the vserver side and as there are
quite more issues with vserver I hoped to get rid of all those issues using
LXC. At least issue 3 is also with lxc-attach is quite the same, but
documentation of lxc-attach does not mention the risks either (at least on
Ubuntu). Calling

# lxc-attach --name buildhost-trusty -- /bin/ls

will create file outside when e.g. /bin/ls was replaced with

/root/TtyPushbackSignaling --NoSignal -- "touch /xxx"

So I guess one should not use attach to run e.g. automatic updates in the
guest or something alike.

Attachment: smime.p7s
Description: