perlbot-blog/blog/tag/seccomp.atom

<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>https://perlbot.pl/blog/tag/seccomp/</id>
    <title>Perlbot.pl pastebin</title>
    <updated>2018-03-16T00:00:00Z</updated>
    <link href="https://perlbot.pl/blog/tag/seccomp.atom" rel="self" />
    <link href="https://perlbot.pl/blog/tag/seccomp/" rel="alternate" />
    <generator version="0.086">Statocles</generator>

    <entry>
        <id>https://perlbot.pl/blog/2018/03/16/seccomp-and-us/</id>
        <title>Seccomp and Us</title>
        <link href="https://perlbot.pl/blog/2018/03/16/seccomp-and-us/" rel="alternate" />
        <content type="html"><![CDATA[
            <p>Back in october I wrote an article about how I was redesigning the seccomp system inside App::EvalServerAdvanced, a few months ago I finally finished that
and have gotten it ready to document it here.  I ended up writing most of it as part of the module/project documentation and you can view it at https://metacpan.org/pod/App::EvalServerAdvanced::Seccomp so that it&#39;ll always be up to date.
What I didn&#39;t document there, were the plugins to enable more advanced behavior, since the API there hasn&#39;t fully been fleshed out, but I don&#39;t see them changing much in the future.</p>

<h2>Plugin Types</h2>

<h1>Constant Plugins</h1>

<p>These ones are pretty well defined and not likely to actually change.  There&#39;s two provided by default, ::Seccomp::Plugin::Constant::POSIX and ::Seccomp::Plugin::Constant::LinuxClone
POSIX provides most of the constants from POSIX and some specific to the clone(2) syscall.</p>

<pre><code>constants:
  plugins:
    - &#39;POSIX&#39;
    - &#39;LinuxClone&#39;
  values:
    TCGETS: 0x5401
    FIOCLEX: 0x5451
    FIONBIO: 0x5421
    TIOCGPTN: 0x80045430
</code></pre>

<p>An example of the YAML above, that pulls in the two plugins, and here&#39;s how you use them:</p>

<pre><code>  file_readonly:
    include:
      - file_open
    permute:
      open_modes:
    - &#39;O_NONBLOCK&#39;
    - &#39;O_EXCL&#39;
    - &#39;O_RDONLY&#39;
    - &#39;O_NOFOLLOW&#39;
    - &#39;O_CLOEXEC&#39;

  lang_ruby:
    include:
      - default
    rules:
      - syscall: clone
    tests:
      - [0, &#39;==&#39;, &#39;CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID&#39;]
      - syscall: sigaltstack
</code></pre>

<p>So now the rules you write don&#39;t need to have strange magic numbers in them, like 0x80045430, or having to worry so much about portability among architectures.</p>

<h1>Rule generating plugins</h1>

<p>These are useful if you need to generate a rule a runtime, either because you need to look up some information that will change
or you otherwise need to know about what&#39;s being generated.  The API for these plugins is very likely going to change, to add in
some more information that the plugins can use to make rules, things like the code and files being passed in, and other information
about the whole setup.</p>

<p>https://github.com/perlbot/App-EvalServerAdvanced/blob/master/lib/App/EvalServerAdvanced/Seccomp/Plugin/ExecWrapper.pm</p>


                <p>Tags:
                    <a href="https://perlbot.pl/blog/tag/perlbot/">perlbot</a>
                    <a href="https://perlbot.pl/blog/tag/seccomp/">seccomp</a>
                    <a href="https://perlbot.pl/blog/tag/plugins/">plugins</a>
                </p>

        ]]></content>
        <updated>2018-03-16T00:00:00Z</updated>
        <category term="perlbot" />
        <category term="seccomp" />
        <category term="plugins" />
    </entry>
    <entry>
        <id>https://perlbot.pl/blog/2017/10/23/seccomp-and-you/</id>
        <title>Seccomp and you</title>
        <link href="https://perlbot.pl/blog/2017/10/23/seccomp-and-you/" rel="alternate" />
        <content type="html"><![CDATA[
            <p>So one of the big goals for App::EvalServerAdvanced is to make creating and maintaining a
sandbox for arbitrary code easier.  The biggest way it does this is via Seccomp-bpf
(heretofore refered to as seccomp).</p>

<pre><code>seccomp-bpf is an extension to seccomp[8] that allows filtering of system calls using
a configurable policy implemented using Berkeley Packet Filter rules. It is used by
OpenSSH and vsftpd as well as the Google Chrome/Chromium web browsers on Chrome OS and
Linux. (In this regard seccomp-bpf achieves similar functionality to the older
systrace—which seems to be no longer supported for Linux).
-- https://en.wikipedia.org/wiki/Seccomp
</code></pre>

<p>Right now this is all handled in App::EvalServerAdvanced::Seccomp, with a large set of
predefined rules, organized into &#39;profiles&#39;.  Each profile is intended to represent a
single kind of action that a program could do, such as open a file for reading, open a
file for writing, etc.</p>

<p>I&#39;ve created a few profiles to start with</p>

<ul>
<li><p>stdio
Allow reading from STDIN, and writing to STDOUT/STDERR.</p></li>
<li><p>file_open
Allows calling some file related system calls, such as: open, openat, close, select,
read (on any descriptor), pread64, lseek, fstat, lstat, stat, fcntl, and ioctl with flags to detect if it&#39;s a
tty.  The flags that are allowed to go to a opening a file are defined in the &quot;open_modes&quot;
rules that will be covered later</p></li>
<li><p>file_opendir
Allows opening a directory to get a list of files, and also includes the file_open
profile to allow interacting with the handle.  Essentially allows the behavior of /bin/ls
or similar programs</p></li>
<li><p>file_tty
Adds O_NOCTTY to the allowed flags passed to open() and similar calls</p></li>
<li><p>file_readonly
Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and
similar calls</p></li>
<li><p>file_write
Adds O_CREAT, O_WRONLY, O_TRUNC, O_RDWR to be passed to open() and similar calls.
Also allows the use of write, pwrite64, mkdir, and chmod syscalls.</p></li>
<li><p>time_calls
Allows calling nanosleep, clock_gettime, and clock_getres syscalls.  For perl this
means allowing time(), and similar calls, and sleep() along with Time::HiRes.</p></li>
<li><p>ruby_timer_thread
This one is a special ruby specific profile.  It allows ruby to create a thread that
it uses internally, and only allows that thread creation with a specific set of flags,
<code>CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID</code>
This prevents it from doing arbitrary fork() calls, while still allowing the interpreter
to run.  It also allows for pipe2 to be called to create communication between the two
threads.</p></li>
<li><p>perl_file_temp
This was added specifically for behavior of File::Temp, and might get folded into a
more generic profile.  It allows chmod with a mode of 0600 and unlink to be called.</p></li>
<li><p>exec_wrapper
This one is seriously special.  It&#39;s not a predefined set of rules, but in fact
generates the rules at runtime.  This is because of limitations of seccomp.  Since
seccomp can&#39;t inspect inside of pointers, there&#39;s no way to verify the contents of a
string being passed to execve(), instead we create a white-list of strings that can be
passed to it, and only allow calls to execve that are passed pointers to this syscall.
This isn&#39;t perfectly secure since someone could overwrite the contents at a later point
but it&#39;s safe enough because an attacker can&#39;t view the generated BPF to extract the
addresses, and the strings themselves should be gone from memory by the time their code
runs, preventing them from recreating the original addresses.  This requires ASLR in order
to be effective at preventing an attacker from derriving the address of the strings from
previous runs.</p></li>
</ul>

<p>There&#39;s also some other profiles like ruby_timer_thread specifically for allowing node.js
to do similar things to ruby (create a thread, use epoll, etc.).</p>

<h1>Handling flags to syscalls</h1>

<p>The way the rules are defined allow syscalls like open() to not need special handling.
Since many syscalls can take flags, it&#39;s useful to be able to limit the flags they can
take.</p>

<pre><code>{syscall =&gt; &#39;openat&#39;, permute_rules =&gt; [[&#39;2&#39;, &#39;==&#39;, \&#39;open_modes&#39;]]},
</code></pre>

<p>Inside A::ESA::Seccomp you can define a syscall like the above, to take a set of
automatically generated rules from a permutation.  In this cases it&#39;s called &#39;open_modes&#39;.
A profile can add (but not remove) values to the permutation rules, and then when the
whole BPF program gets compiled it&#39;ll generate all the applicable rules for you.  This
makes setting up calls like open much much simpler since you don&#39;t have to write out all
possible modes yourself.  This is also an area where I could be doing better to optimize
the whole thing, but have not done so yet.  Seccomp itself supports doing some bitwise
operations that could make this more effective but they were not well exposed through
Linux::Seccomp when this was originally designed.</p>

<p>In the second part of this blog I&#39;ll document the proposed configuration
scheme using YAML 1.2 and the perl modules located in the sandbox root.</p>


                <p>Tags:
                    <a href="https://perlbot.pl/blog/tag/evalserver/">evalserver</a>
                    <a href="https://perlbot.pl/blog/tag/seccomp/">seccomp</a>
                </p>

        ]]></content>
        <updated>2017-10-23T00:00:00Z</updated>
        <category term="evalserver" />
        <category term="seccomp" />
    </entry>
</feed>