[llvm-dev] LLDB security and the use of an IPC library

[Demi Obenour via llvm-dev]

Those are all bu

On Apr 27, 2017 8:00 AM, "David Chisnall" <David.Chisnall at cl.cam.ac.uk>
wrote:

On 26 Apr 2017, at 20:26, Demi Marie Obenour via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> LLDB currently uses a client-server architecture.  That appears fine,
> but runs into an annoying security problem: other users on the same
> machine can connect to the TCP socket and take over LLDB and thus the
> user’s system.  This means that LLDB is useless in multiuser
> enviromnents on Linux, such as academic computer labs.
>
> The immediate problem can be solved by using either HMAC authentication
> of all messages or by using Unix domain sockets.  However, it might be
> simpler to use a 3rd party library for the purpose:
> https://github.com/DemiMarie/SlipRock (Disclaimer: I wrote SlipRock).
>
> Questions:
>
> - Would you be interested in using SlipRock?

A cursory glance at SlipRock raises a few concerns:

- It depends on libsodium (I like libsodium, but it adds another external
dependency).

I plan on removing this dependency by copying the code.


- It doesn’t appear to have been tested on non-Linux *NIX systems (LLDB is
the default debugger on macOS / iOS, is about to be on FreeBSD, and is used
on NetBSD, OpenBSD and Solaris).  I include build testing in this, as the
build system only looks for sodium.h in the default location on Linux.

Do you know of any ways I can do CI on those systems?  That it fails to
build on any *nix platform (with libsodium installed) is a bug.  I am
working on improving the CMake build system to help with that.


- The Windows support is not yet done (at least, there’s no tick in the
‘compiles on Windows’ status item).

I plan on doing a refactoring that should make that much easier.

- Attempting to compile it on FreeBSD gives 9 warnings and 8 errors, with
several warnings referring to playing fast and loose with pointer aliasing
rules.  This makes me very nervous in code that’s intended for security.

Not following the pointer aliasing rules is definitely a bug.  Would you
mind posting the log?


- It uses assert() instead of real error handling, which is inappropriate
in a library, and requires that the file be compiled without -DNDEBUG,
which makes it annoying to integrate into other build systems.

That’s certainly a bug.  I will fix it.


- The APIs appear to be entirely undocumented.

The documentation is in sliprock.h, but the fact that that is not easy to
find is a bug.


- The error handling does not match the lexical scoping and so is very
difficult a to follow (and therefore potentially error prone).  I was
unable to run the static analyser on the code because it doesn’t compile on
FreeBSD or macOS.

That’s definitely a bug, at least in my opinion.  SlipRock should be very
easy to follow.  I was inspired by the Linux kernel’s “goto fail” but
obviously things didn’t work as expected.


David


Thanks,

Demi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170427/f1a4daad/attachment.html>