Cyrus Sieve futures

Tue Feb 7 23:48:36 EST 2017

I'm pretty sure there's no IO handling inside the sieve bytecode
processing, though it makes callbacks to perform the actual actions - so
the impure bits are very clearly defined.

On Wed, 8 Feb 2017, at 13:05, Anatoli via Cyrus-devel wrote:

> Bron, do you mean Sieve is separated from the rest of the Cyrus code
> or that inside Sieve code there's separation for pure data processing
> (without syscalls) and I/O & other resources handling,
> processes/threads management, etc.? I my previous mail I was meaning
> the later.
> 

>  If it's already done, that's great and everything is ready to define
>  the format for the "results" file and proceed with the seccomp
>  implementation, if all agree that this is a needed change.
> 

> *From:* Bron Gondwana Via Cyrus-devel

> *Sent:* Tuesday, February 07, 2017 07:01

> *To:* Cyrus-devel

> *Subject:* Re: Cyrus Sieve futures

> Actually, that's pretty much already done, the separation.  Sieve,
> more than any other part of the Cyrus code, is very decoupled.  It
> used to be a separate CVS repository once upon a time.
> 

> Bron.

> 

> 

> On Tue, 7 Feb 2017, at 18:36, Anatoli via Cyrus-devel wrote:

>> Hi Ken,

>> 

>> I don't have any special uses for Sieve apart from the most basic
>> ones, but I would like to ask you if you see it feasible, as part of
>> this work, to separate the "numbers crunching" (e.g. rules matching,
>> transformations, etc.) code from the I/O code (that is responsible
>> for manipulating files, communicating with other processes, etc.)?
>> 

>> My idea is to isolate and safeguard Sieve's "numbers crunching" code
>> with[1] seccomp[2], which basically only allows to execute userland
>> code (i.e. no syscalls, etc.) and read/write to already-open file
>> descriptors. This should reduce currently broad attack surface to
>> some really exotic bugs in the Linux kernel (up to now just one
>> significant bug for strict seccomp bypass was discovered (CVE-2009-
>> 0835 in 2.6 kernel 8 years ago), soon after this functionality was
>> implemented).
>> 

>> One of possible architectures could be described this way (similar to
>> Postfix architecture[3]):
>>
>>  1. Sieve daemon receives an incoming data for processing and stores
>>     it in a memory buffer (without touching it)
>>  2. It creates a new "results" file and opens it for writing
>>  3. It forks a process
>>  4. The newly created child process switches to seccomp
>>  5. It processes the data and writes the results (in a special
>>     format) to the "results" file, then exits
>>  6. Sieve daemon detects the exit of the child process and reads the
>>     "results" file to perform the requested actions, then deletes the
>>     file
>>  7. If the child is killed (as the result of seccomp restrictions
>>     violation) or something is wrong with the format of the "results"
>>     file, Sieve daemon quarantines the data and writes an error to
>>     the logs
>> 

>> The format for the "results" file should be simple and well defined,
>> and the code to interpret it should be carefully written. This could
>> be started as a mere adaptation for the new architecture of the
>> current actions processing logic and be progressively improved later.
>> This would be much easier than making the entire Sieve code base and
>> the libraries it uses (e.g. PCRE) reasonably safe (PCRE alone is a
>> huge bag ofvulnerabilities[4], including lots of RCEs).
>> 

>> 

>> Another question (just wondering if it's in your (or other devs)
>> plans and its feasibility): is it practically possible to implement
>> for Sieve something like "run the rules on X folder (+ subfolders)"
>> same way as local rules in most MUAs could be applied to already
>> stored mails? I find lack of this feature as the only (but notable)
>> downside to Sieve vs local rules.
>> 

>> Regards,

>> Anatoli

>> 

>> *From:* Ken Murchison Via Cyrus-devel

>> *Sent:* Monday, February 06, 2017 19:34

>> *To:* Cyrus-devel

>> *Subject:* Cyrus Sieve futures

>>> All, 

>>> 

>>> I'm in the process of rewriting the Sieve parser and adding new
>>> extensions for what will become part of Cyrus v3.1.  We currently
>>> support deprecated and non-standardized extensions "imapflags"
>>> (standardized as "imap4flags) and "notify" (standardized as
>>> "enotify").  I'd like to rip out the parser and bytecode generator
>>> for these extensions, and leave just the bytecode executing code for
>>> the deprecated actions "mark", "unmark", and "denotify".
>>> 

>>> Any existing scripts using these actions (or the older "notify"
>>> syntax) would continue to run.  New/updated scripts would have to
>>> switch to using the updated "notify" syntax and replace "mark" and
>>> "unmark" with "setflag"/"addflag" and "removeflag".  Does anyone
>>> have an issue with these changes?
>>> 

>>> Does anyone have any requests for standard extensions that we don't
>>> currently support?  Note that "variables", "mailbox" and "*metadata"
>>> will be in Cyrus 3.0 and "ereject", "editheader", and "extlists" are
>>> already in what will be the 3.1 branch.
>>> 

>>> Extensions that I'm looking at implementing (pretty much because
>>> they are low-hanging fruit) are "duplicate", "environment", and
>>> "ihave".  I may also look at "replace" and "extracttext" which would
>>> be useful if we add handling of calendar events to Sieve.
>>> 

> 

> --

>   Bron Gondwana

>   brong at fastmail.fm

> 

> 

--

  Bron Gondwana

  brong at fastmail.fm

Links:

  1. https://en.wikipedia.org/wiki/Seccomp
  2. http://man7.org/linux/man-pages/man2/seccomp.2.html
  3. http://www.postfix.org/OVERVIEW.html
  4. https://web.nvd.nist.gov/view/vuln/search-results?query=pcre&search_type=all&cves=on
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20170208/42ceff60/attachment.html>