234 lines
12 KiB
XML
234 lines
12 KiB
XML
<?xml version="1.0"?>
|
|
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
|
<channel>
|
|
<title>Perlbot.pl pastebin</title>
|
|
<link>https://perlbot.pl/blog/</link>
|
|
<atom:link href="https://perlbot.pl/blog/index.rss" rel="self" type="application/rss+xml" />
|
|
<description>Blog feed of Perlbot.pl pastebin</description>
|
|
<generator>Statocles 0.086</generator>
|
|
<item>
|
|
<title>Seccomp and Us</title>
|
|
<link>https://perlbot.pl/blog/2018/03/16/seccomp-and-us/</link>
|
|
<guid>https://perlbot.pl/blog/2018/03/16/seccomp-and-us/</guid>
|
|
<description><![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'll always be up to date.
|
|
What I didn't document there, were the plugins to enable more advanced behavior, since the API there hasn't fully been fleshed out, but I don'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'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:
|
|
- 'POSIX'
|
|
- 'LinuxClone'
|
|
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's how you use them:</p>
|
|
|
|
<pre><code> file_readonly:
|
|
include:
|
|
- file_open
|
|
permute:
|
|
open_modes:
|
|
- 'O_NONBLOCK'
|
|
- 'O_EXCL'
|
|
- 'O_RDONLY'
|
|
- 'O_NOFOLLOW'
|
|
- 'O_CLOEXEC'
|
|
|
|
lang_ruby:
|
|
include:
|
|
- default
|
|
rules:
|
|
- syscall: clone
|
|
tests:
|
|
- [0, '==', 'CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID']
|
|
- syscall: sigaltstack
|
|
</code></pre>
|
|
|
|
<p>So now the rules you write don'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'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>
|
|
|
|
]]></description>
|
|
<pubDate>
|
|
Fri, 16 Mar 2018 00:00:00 +0000
|
|
</pubDate>
|
|
</item>
|
|
<item>
|
|
<title>Seccomp and you</title>
|
|
<link>https://perlbot.pl/blog/2017/10/23/seccomp-and-you/</link>
|
|
<guid>https://perlbot.pl/blog/2017/10/23/seccomp-and-you/</guid>
|
|
<description><![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 'profiles'. 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'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's a
|
|
tty. The flags that are allowed to go to a opening a file are defined in the "open_modes"
|
|
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'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't inspect inside of pointers, there'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't perfectly secure since someone could overwrite the contents at a later point
|
|
but it's safe enough because an attacker can'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'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's useful to be able to limit the flags they can
|
|
take.</p>
|
|
|
|
<pre><code>{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},
|
|
</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's called 'open_modes'.
|
|
A profile can add (but not remove) values to the permutation rules, and then when the
|
|
whole BPF program gets compiled it'll generate all the applicable rules for you. This
|
|
makes setting up calls like open much much simpler since you don'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'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>
|
|
|
|
]]></description>
|
|
<pubDate>
|
|
Mon, 23 Oct 2017 00:00:00 +0000
|
|
</pubDate>
|
|
</item>
|
|
<item>
|
|
<title>New old perls</title>
|
|
<link>https://perlbot.pl/blog/2017/10/02/new-old-perls/</link>
|
|
<guid>https://perlbot.pl/blog/2017/10/02/new-old-perls/</guid>
|
|
<description><![CDATA[
|
|
<p>So as part of my own insanity I've managed to port/compile some old perl versions on linux and get the running in the eval sandbox.
|
|
Earlier today I completed this goal and there's now an available version of every major stable perl release: 1, 2, 3, 4, 5.000, 5.001, 5.002, 5.003, 5.004, 5.005, 5.6, 5.8, 5.10, 5.12, 5.14, 5.16, 5.18, 5.20, 5.22, 5.24, and 5.26.</p>
|
|
|
|
<p>Now that I've completed this goal, I've decided to bundle up all the seriously old perls into an
|
|
easy to download file for anyone else who has decided to go a little insane and try out some
|
|
ancient perl. You can find the file here, <a href="https://perlbot.pl/bstatic/newoldperls.tar.xz">https://perlbot.pl/bstatic/newoldperls.tar.xz</a>.
|
|
They're all expecting to live in /langs/ on a modernish linux system. That's actually a /langs
|
|
directory on the root filesystem. This was done to make getting them to work in the sandbox for the pastebin much easier.</p>
|
|
|
|
<p>Also available as a download in <a href="https://perlbot.pl/bstatic/newoldperls.tar.gz">.tar.gz</a> and <a href="https://perlbot.pl/bstatic/newoldperls.tar.zst">.tar.zst</a></p>
|
|
|
|
<p>ps. .tar.zst is compressed with zstandard/zstd, i wanted to try it out.</p>
|
|
|
|
|
|
|
|
]]></description>
|
|
<pubDate>
|
|
Mon, 02 Oct 2017 00:00:00 +0000
|
|
</pubDate>
|
|
</item>
|
|
<item>
|
|
<title>new blog</title>
|
|
<link>https://perlbot.pl/blog/2017/09/28/new-blog/</link>
|
|
<guid>https://perlbot.pl/blog/2017/09/28/new-blog/</guid>
|
|
<description><![CDATA[
|
|
<p>I'm going to try to post here with real updates about both perlbot and App::EvalServerAdvanced.
|
|
I'll start posting updates and other interesting things I'm planning to do with App::EvalServerAdvanced
|
|
to make get feedback on how to make both projects more useful to everyone. I'm hoping I can turn App::EvalServerAdvanced
|
|
into a more generalized ephemeral container system, that lets you securely and quickly spin up a container containing user content
|
|
and perform an action on it.</p>
|
|
|
|
|
|
|
|
]]></description>
|
|
<pubDate>
|
|
Thu, 28 Sep 2017 00:00:00 +0000
|
|
</pubDate>
|
|
</item>
|
|
</channel>
|
|
</rss>
|
|
|