Cyrus Sieve futures

[Bron Gondwana]

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






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/20170207/d98bfd87/attachment.html>