On Thu, 20 Feb 2020 15:33:25 -0500 "Greg Reagle" <greg.rea...@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
