Provide a sandboxed pipe-to-program (CGI) bot host on each chatmail server

Bots
,
1

Goals

The goal would be to allow hobbyists to fork existing DC bots and implement new one without having to bother, pay for or trust a reliable non-stop third party hosting service. All while maintaining chatmail as a single-click install by ensuring that operators are not exposed to additional liability, instability or expenses.

Restrictions

Bots would thus be limited to strike the above balance

Installation

Every chatmail account had a way through which it could install a bot, such as by including its code and metadata in a special IMAP folder.

The bot should carry metadata about how to contact the author in case of problems.

Let the bot author to specify in the metadata a rate limit for how many times each user is allowed to trigger the bot and how much bandwidth they may use (e.g., 60 mails per hour, 120 mails per day, 60 seconds per hour or 60MB/hour)

As the chatmail server could already access the private key of the bot user anyway while running the bot, it is best serialized at a dedicated place so chatmail had direct access to it. This allows combating abuse by only running the program if encryption on the incoming mail is valid.

Computation

The bot would not be resident in memory as a daemon, but rather was only invoked for each incoming email similar to procmail (also how the CGI and PHP model serves single-shot web requests)

The bot would run in a sandbox (e.g., LXC container) that limited its usage of disk IO, memory, CPU and wall clock timeout per invocation to what is sufficient for simple scripts (e.g., 1MB/s, 100 IOPS, 128MB RAM, 1% CPU/hour, 0.1% CPU/day, 30 seconds timeout per mail)

The bot may additionally specify sparse scheduled execution (e.g., once per hour) with comparable limits.

The chatmail host could decouple bot startup from mail delivery, while still serializing execution of the bot processes themselves, so that up to 1 (or a few) bot would be running in parallel to avoid peaks in host IO, memory or CPU.

Network access

The bot would have no other network access than IMAP & SMTP to the local chatmail instance and to optionally manually whitelisted origins. The operator may optionally whitelist origins globally across the server.

The incoming new email itself that triggered this execution may be copied to the standard input of the program similarly to how it is done by “Pipe to program” email forwarding (~/.forward in Postfix, sendmail and many cPanel providers)

Even without any network access at all, various useful bots could already be hosted, such as:

Storage

No durable storage would be provided other than its own chatmail account itself and optionally a folder of its own with quota comparable to what a chatmail account receives.

Platform

It is an open question which architectures and platforms to support, but multi-platform scripts which do not need to be compiled are preferred, such as via LLRT (QuickJS) that has millisecond-grade execution times.

Delta Chat protocol integration

It is an open question how to handle encryption & DC extensions, but in case of LLRT, Chatmail Rust Core could simply be compiled to WebAssembly.

The host may also choose to temporarily start up a separate JSON RPC server for each bot instead as a proof of concept. This allows for easily restricting communication through the DC API. Enforce per contact sending rate limits. Limit size of sent data items. Only allow actions with lesser abuse potential:

  • accept chat invitations
  • read message
  • send message
  • resend message
  • delete message
  • add contact to group, but only if they have sent the bot a direct message in the past (consent can be revoked with /stop)
  • read webxdc update
  • send webxdc update
  • store state in private draft messages

Security concerns

Prior art:

Technologies:

Frameworks:

Packaging:

Legacy:

1 Like
2

This is remote code execution with untrusted input, therefore a security nightmare.