On Thu, 20 Feb 2020 15:33:25 -0500
"Greg Reagle" <greg.reagle_AT_umbc.edu> wrote:
Dear Greg,
> Thank you Laslo Hunhold for your feedback.
sure, happy to give it! :)
> Based on your other comments, I assume that when you stress the
> importance of the "interface", you are not referring to end-user
> interface (like command line, or curses, or GTK, etc.) but more of a
> lower level interface, like the way that ii works with files and
> directories and FIFOs?
yes, exactly. If you do that right and work out good, solid, data
structures, higher interfaces are easy to implement on top of this
interface.
With chat clients, you mostly deal with state changes. If you manage to
represent them properly in your interface, you are fine. I wouldn't
probably do it with files, even though ii shows how easy it is to write
chatbots and stuff. Instead, I'd go the route of popular OpenBSD
projects like OpenSMTPD or httpd which have multiple "worker" threads
that communicate over a form of IPC. This greatly reduces the attack
surface, allows you to implement things like unveil and pledge easily,
and is very unixy but does not limit you to just the filesystem.
> Are you referring to https://git.2f30.org/ratox/file/README.html.
> Are you suggesting that I use it as a template for the interface
> (along with ii).
See above. :) To be honest, we struggled a lot with state changes
within toxcore and really hit a wall when they implemented video
conferences on top of the protocol in a really ugly way. Ratox is full
of finite state machines, but maybe another approach is better (e.g.
the one I give above for security and resiliency reasons). The popular
Riot client is literally one big blob where everything accesses
everything. Concerns need to be separated to really have a solid
application. If the only thing an attacker can use is your IPC
mechanism and you are pretty strict with your parsing in this regard,
you are already in a good direction.
Make up your mind in this regard, but to just give you an idea: Matrix
fundamentally builds on top of JSON that is served via HTTP. Thus, one
of the aforementioned "threads" could just have the task to do the
HTTP-dispatching and JSON-parsing and -creating. When it has parsed and
"categorized" the type of request, it can then use IPC to send it off
to another component.
The dispatcher itself doesn't need to have file system access. It only
needs to listen on a socket, so if an attacker manages to use a
vulnerability in the IP-stack and gain full control of that process,
with proper pledge/unveil in effect, they cannot read any of the file
system or do any syscalls other than networking syscalls. If you then
have properly sealed off the IPC mechanism and filter off malformed
stuff properly (YMMV), you are relatively safe.
> I am certainly open to suggestions to other languages. If using a
> different language can get me more contribution from others, that
> would be very valuable to me indeed. But I do want something higher
> level than C.
I understand that. However, I often see that people are just scared of
breaking their projects up into multiple sub-modules. Higher level
languages invite you to do it all in one process or at least
permission-level. In the end, everything is as unsafe as C once you
have control over the process, so it's best, in my opinion, to adapt
the coding style to the language rather than trying to solve more
complex problems with more elaborate paradigms.
With best regards
Laslo
Received on Tue Feb 25 2020 - 13:47:43 CET