Cyrus Sieve futures
brong at fastmail.fm
Tue Feb 7 05:01:18 EST 2017
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.
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 seccomp, 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
> One of possible architectures could be described this way (similar to
> Postfix architecture):
> 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
> 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
> 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, 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.
> *From:* Ken Murchison Via Cyrus-devel
> *Sent:* Monday, February 06, 2017 19:34
> *To:* Cyrus-devel
> *Subject:* Cyrus Sieve futures
>> 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.
brong at fastmail.fm
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cyrus-devel