> Von: Alexander Wuerstlein [mailto:arw@xxxxxxxxx] > > On 2016-01-15T09:53, Fiedler Roman <Roman.Fiedler@xxxxxxxxx> 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] ..
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
