<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div style="font-family:Arial;">Sorry, I've been traveling and didn't get back to this.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Ken has been doing most of the work on sieve recently. Realistically, I'd say we don't have much time to work on it right now either. The best thing would be to integrate anything into our qa build chain, since otherwise the testing only holds until someone touches the code again.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Bron</div>
<div><br></div>
<div><br></div>
<div>On Fri, 10 Feb 2017, at 09:42, Anatoli via Cyrus-devel wrote:<br></div>
<blockquote type="cite"><div><div style="font-size:10pt;font-family:Verdana, Arial;"><span class="font" style="font-family:Verdana">Bron,<br> <br> That's good. Do you see this change (safeguarding Sieve with
seccomp) necessary? Would someone from your team help with its
implementation? To be realistic, most likely I won't be able
to find enough time to refactor Sieve alone (i.e. to adapt it
to the described architecture), but I could help with the
architecture/logic, </span><span class="font" style="font-family:Verdana"><span class="font" style="font-family:Verdana">the "results" file format,</span> seccomp
part, processes, passing the data to and from and related
aspects.<br> <br> You said in one issue at github that you have plans to replace
PCRE with RE2. This one, plus Ken's work, I believe, could
have an opportunity to refactor Sieve for the seccomp change
without dedicating it significant extra resources.<br> <br> If you find it appropriate we could start another discussion
(in github?) to outline the implementation details.<br> </span> </div>
<div style="border-right-width:initial;border-bottom-width:initial;border-left-width:initial;border-right-style:none;border-bottom-style:none;border-left-style:none;border-right-color:initial;border-bottom-color:initial;border-left-color:initial;border-image-source:initial;border-image-slice:initial;border-image-width:initial;border-image-outset:initial;border-image-repeat:initial;border-top-width:1pt;border-top-style:solid;border-top-color:rgb(181, 196, 223);padding-top:3pt;padding-right:0cm;padding-bottom:0cm;padding-left:0cm;font-size:10pt;font-family:Tahoma, sans-serif;"><div style="font-family:Arial;"><b>From:</b> Cyrus Devel<br></div>
<div style="font-family:Arial;"> <b>Sent:</b> Wednesday, February 08, 2017 01:48<br></div>
<div style="font-family:Arial;"> <b>To:</b> Cyrus Devel<br></div>
<div style="font-family:Arial;"> <b>Subject:</b> Re: Cyrus Sieve futures<br></div>
</div>
</div>
<blockquote type="cite"><div style="font-family:Arial;">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.<br></div>
<div><br></div>
<div><br></div>
<div>On Wed, 8 Feb 2017, at 13:05, Anatoli via Cyrus-devel wrote:<br></div>
<blockquote type="cite"><div><div style="font-size:10pt;font-family:Verdana, Arial;"><div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><br></div>
</div>
<div style="border-right-width:medium;border-bottom-width:medium;border-left-width:medium;border-right-style:none;border-bottom-style:none;border-left-style:none;border-image-source:none;border-image-slice:100%;border-image-width:1;border-image-outset:0;border-image-repeat:stretch;border-top-width:1pt;border-top-style:solid;border-top-color:rgb(181, 196, 223);padding-top:3pt;padding-right:0cm;padding-bottom:0cm;padding-left:0cm;font-size:10pt;font-family:Tahoma, sans-serif;"><div style="font-family:Arial;"><b>From:</b> Bron Gondwana
Via Cyrus-devel<br></div>
<div style="font-family:Arial;"><b>Sent:</b> Tuesday,
February 07, 2017 07:01<br></div>
<div style="font-family:Arial;"><b>To:</b> Cyrus-devel<br></div>
<div style="font-family:Arial;"><b>Subject:</b> Re: Cyrus
Sieve futures<br></div>
</div>
</div>
<div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Bron.<br></div>
</div>
<div><br></div>
<div><br></div>
<div>On Tue, 7 Feb 2017, at 18:36, Anatoli via Cyrus-devel
wrote:<br></div>
<blockquote type="cite"><div><div style="font-size:10pt;font-family:Verdana, Arial;"><div style="font-family:Arial;">Hi Ken,<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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.)?<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">My idea is to isolate and
safeguard Sieve's "numbers crunching" code <a href="https://en.wikipedia.org/wiki/Seccomp">with</a> <a href="http://man7.org/linux/man-pages/man2/seccomp.2.html">seccomp</a>,
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).<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">One of possible
architectures could be described this way (similar to <a href="http://www.postfix.org/OVERVIEW.html">Postfix
architecture</a>):<br></div>
<div style="font-family:Arial;"><br></div>
<ol><li>Sieve daemon receives an incoming data for
processing and stores it in a memory buffer (without
touching it)<br></li><li>It creates a new "results" file and opens it for
writing<br></li><li>It forks a process<br></li><li>The newly created child process switches to seccomp<br></li><li>It processes the data and writes the results (in a
special format) to the "results" file, then exits<br></li><li>Sieve daemon detects the exit of the child process
and reads the "results" file to perform the requested
actions, then deletes the file<br></li><li>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<br></li></ol><div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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 of<a href="https://web.nvd.nist.gov/view/vuln/search-results?query=pcre&search_type=all&cves=on">vulnerabilities</a>,
including lots of RCEs).<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Regards,<br></div>
<div style="font-family:Arial;">Anatoli<br></div>
<div style="font-family:Arial;"><br></div>
</div>
<div style="border-right-width:medium;border-bottom-width:medium;border-left-width:medium;border-right-style:none;border-bottom-style:none;border-left-style:none;border-image-source:none;border-image-slice:100%;border-image-width:1;border-image-outset:0;border-image-repeat:stretch;border-top-width:1pt;border-top-style:solid;border-top-color:rgb(181, 196, 223);padding-top:3pt;padding-right:0cm;padding-bottom:0cm;padding-left:0cm;font-size:10pt;font-family:Tahoma, sans-serif;"><div style="font-family:Arial;"><b>From:</b> Ken Murchison
Via Cyrus-devel<br></div>
<div style="font-family:Arial;"><b>Sent:</b> Monday,
February 06, 2017 19:34<br></div>
<div style="font-family:Arial;"><b>To:</b> Cyrus-devel<br></div>
<div style="font-family:Arial;"><b>Subject:</b> Cyrus
Sieve futures<br></div>
</div>
</div>
<blockquote type="cite"><div style="font-family:Arial;">All, <br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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". <br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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? <br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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. <br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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. <br></div>
<div style="font-family:Arial;"><br></div>
</blockquote></blockquote><div style="font-family:Arial;"><br></div>
<div><div>--<br></div>
<div> Bron Gondwana<br></div>
<div> <a href="mailto:brong@fastmail.fm">brong@fastmail.fm</a><br></div>
<div><br></div>
</div>
<div style="font-family:Arial;"><br></div>
</blockquote><div style="font-family:Arial;"><br></div>
<div><div>--<br></div>
<div> Bron Gondwana<br></div>
<div> <a href="mailto:brong@fastmail.fm">brong@fastmail.fm</a><br></div>
<div><br></div>
</div>
<div style="font-family:Arial;"><br></div>
</blockquote></blockquote><div style="font-family:Arial;"><br></div>
<div id="sig567075"><div class="signature">--<br></div>
<div class="signature"> Bron Gondwana<br></div>
<div class="signature"> brong@fastmail.fm<br></div>
<div class="signature"><br></div>
</div>
</body>
</html>