339 lines
14 KiB
HTML
339 lines
14 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta content="width=device-width, initial-scale=1" name="viewport">
|
|
<link href="/theme/css/normalize.css" rel="stylesheet">
|
|
<link href="/theme/css/skeleton.css" rel="stylesheet">
|
|
<link href="/theme/css/statocles-default.css" rel="stylesheet">
|
|
<link href="//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css" rel="stylesheet">
|
|
<title>Perlbot.pl pastebin</title>
|
|
<meta content="Statocles 0.086" name="generator">
|
|
<link href="/blog/index.atom" rel="alternate" type="application/atom+xml">
|
|
<link href="/blog/index.rss" rel="alternate" type="application/rss+xml">
|
|
|
|
</head>
|
|
<body>
|
|
<header>
|
|
<nav class="navbar">
|
|
<div class="container">
|
|
<a class="brand" href="/">Perlbot.pl pastebin</a>
|
|
<ul>
|
|
<li>
|
|
<a href="/blog">Blog</a>
|
|
</li>
|
|
</ul>
|
|
|
|
</div>
|
|
</nav>
|
|
|
|
</header>
|
|
<div class="main container">
|
|
<div class="row">
|
|
<div class="nine columns">
|
|
<main>
|
|
|
|
|
|
<article>
|
|
<header>
|
|
<h1><a href="/blog/2018/03/16/seccomp-and-us/">Seccomp and Us</a></h1>
|
|
|
|
<aside>
|
|
<time datetime="2018-03-16">
|
|
Posted on 2018-03-16
|
|
</time>
|
|
</aside>
|
|
|
|
<p class="tags">Tags:
|
|
<a href="/blog/tag/perlbot/" rel="tag">perlbot</a>
|
|
<a href="/blog/tag/seccomp/" rel="tag">seccomp</a>
|
|
<a href="/blog/tag/plugins/" rel="tag">plugins</a>
|
|
</p>
|
|
|
|
</header>
|
|
|
|
<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>
|
|
|
|
|
|
|
|
</article>
|
|
<article>
|
|
<header>
|
|
<h1><a href="/blog/2017/10/23/seccomp-and-you/">Seccomp and you</a></h1>
|
|
|
|
<aside>
|
|
<time datetime="2017-10-23">
|
|
Posted on 2017-10-23
|
|
</time>
|
|
</aside>
|
|
|
|
<p class="tags">Tags:
|
|
<a href="/blog/tag/evalserver/" rel="tag">evalserver</a>
|
|
<a href="/blog/tag/seccomp/" rel="tag">seccomp</a>
|
|
</p>
|
|
|
|
</header>
|
|
|
|
<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>
|
|
|
|
|
|
|
|
</article>
|
|
<article>
|
|
<header>
|
|
<h1><a href="/blog/2017/10/02/new-old-perls/">New old perls</a></h1>
|
|
|
|
<aside>
|
|
<time datetime="2017-10-02">
|
|
Posted on 2017-10-02
|
|
</time>
|
|
</aside>
|
|
|
|
<p class="tags">Tags:
|
|
</p>
|
|
|
|
</header>
|
|
|
|
<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>
|
|
|
|
|
|
|
|
</article>
|
|
<article>
|
|
<header>
|
|
<h1><a href="/blog/2017/09/28/new-blog/">new blog</a></h1>
|
|
|
|
<aside>
|
|
<time datetime="2017-09-28">
|
|
Posted on 2017-09-28
|
|
</time>
|
|
</aside>
|
|
|
|
<p class="tags">Tags:
|
|
</p>
|
|
|
|
</header>
|
|
|
|
<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>
|
|
|
|
|
|
|
|
</article>
|
|
|
|
<ul class="pager">
|
|
<li class="prev">
|
|
<button disabled>
|
|
← Older
|
|
</button>
|
|
</li>
|
|
<li class="next">
|
|
<button disabled>
|
|
Newer →
|
|
</button>
|
|
</li>
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
</main>
|
|
</div>
|
|
|
|
<div class="three columns sidebar">
|
|
|
|
<nav id="tags">
|
|
<h1>Tags</h1>
|
|
<ul class="list-inline">
|
|
<li><a href="/blog/tag/evalserver/">evalserver</a></li>
|
|
<li><a href="/blog/tag/perlbot/">perlbot</a></li>
|
|
<li><a href="/blog/tag/plugins/">plugins</a></li>
|
|
<li><a href="/blog/tag/seccomp/">seccomp</a></li>
|
|
</ul>
|
|
</nav>
|
|
|
|
<h1>Feeds</h1>
|
|
<ul class="list-inline">
|
|
<li>
|
|
<a href="/blog/index.atom" rel="alternate" type="application/atom+xml">
|
|
Atom
|
|
</a>
|
|
</li>
|
|
<li>
|
|
<a href="/blog/index.rss" rel="alternate" type="application/rss+xml">
|
|
RSS
|
|
</a>
|
|
</li>
|
|
</ul>
|
|
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<footer>
|
|
|
|
<div class="container tagline">
|
|
<a href="http://preaction.me/statocles">Made with Statocles</a><br>
|
|
<a href="http://www.perl.org">Powered by Perl</a>
|
|
</div>
|
|
</footer>
|
|
|
|
|
|
</body>
|
|
</html>
|