<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><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-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> 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-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><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 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>