<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><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;"><br>Bron.<br></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-right-color:-moz-use-text-color;border-bottom-color:-moz-use-text-color;border-left-color:-moz-use-text-color;-moz-border-top-colors:none;-moz-border-right-colors:none;-moz-border-bottom-colors:none;-moz-border-left-colors:none;border-image-source:none;border-image-slice:100% 100% 100% 100%;border-image-width:1 1 1 1;border-image-outset:0 0 0 0;border-image-repeat:stretch 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 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>
<div style="font-family:Arial;"><br></div>
</body>
</html>