AW: Proposal: always handle keys in separate process

[Fiedler Roman]

> Von: Alexander Wuerstlein [mailto:arw at cs.fau.de]
> 
> On 2016-01-15T09:53, Fiedler Roman <Roman.Fiedler at ait.ac.at> wrote:
> > > Von: openssh-unix-dev [mailto:openssh-unix-dev-
> > >
> > > Hello,
> > >
> > > in light of the recent CVE-2016-0777, I came up with the following
idea,
> > > that would have lessened its impact. Feel free to ignore or flame me,
> > > maybe its stupid or I missed something :)
> >
> > What do you think of a following procedure?
> >
> > * On startup, at first management process is created. This process is
> > somehow privileged, as it still can execute all operating system calls
> > without special restrictions. This management process may connect to an
> > agent or launch agent process by itself (if needed) to have access to
key
> > material.
> >
> > * From the management process, have network/terminal process forked,
> reexec
> > itself (thus get rid of any virtual memory information shared with
> > management process, e.g. address space layout, strings already loaded -
e.g.
> > host name, user name, config parameters, ... thus eradicating any
> > information present in the management process)
> 
> So, effectively you propose to also split up the ssh client into three
> processes.
> 
> While it sounds like a good idea in general, I think one should try the
> easier split-up into two first. For why I think it is far easier to
> first separate out the ssh-agent/key-handling, see below.

I agree. I just brought it up, so that those really deep in the code could
decide, how hard it would be to implement such a split. Perhaps there are
other things left out, that make such a model hard, if not impossible.

> > * Let management process seccomp secure the network/terminal process
> to
> > allow only file descriptor read/write operations, ..., that what is
really
> > needed but no other syscalls (especially no open/exec,.../xxxxat style
of
> > calls). Thus the terminal process efficiently loses all capabilities to
> > access key material by himself, which is enforced by the OS (this will
work
> > only on platforms, that support it, others will have to leave out this
> > step).
> >
> > * Use the socket from the network/terminal process to the management
> process
> > only to query (search for) keys, request signing of material.
> 
> Those separations and restrictions are the really hairy part here:
> Pulling out the key handling is small compared to the amount of
> functionality that is e.g. X11-forwarding, agent-forwarding or
> (potentially dynamic) proxy/socket-forwarding which would need to be
> handled when splitting the management from the connection/terminal part.

You are right, those would have to be handled too. If SCM_RIGHTS is quite
common on many SSH client platforms, two additional messages would needed on
the mgmt link: Request-Connection and the response with the file descriptor
to use. Otherwise the management process would need to do multiplexing on
the connection, which seems much more effort.
 
> Another potential problem is the portability problem which seccomp
> poses, there is unfortunately no POSIX syscall filtering or sandboxing
> API. That makes things even more complicated.

It is really bad, that quite many security features as not commonly
supported. So for a first start, perhaps just separate the processes in a
way that one of them could be seccomped (does not need to perform privileged
operations), implement seccomp (or next generation method - perhaps USERNS
will be that stable one time?) when it becomes available to masses in
standardized manner.

> [Snip] ..



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6344 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160115/437e7c3a/attachment-0001.bin>