From 82a2d5f717cd8f28beae375f6c13b2481b071e2a Mon Sep 17 00:00:00 2001 From: Ryan Voots Date: Mon, 23 Oct 2017 12:25:27 -0700 Subject: [PATCH] Site update --- blog/2017/09/28/new-blog/index.html | 2 + blog/2017/10/02/new-old-perls/index.html | 6 +- blog/2017/10/10/seccomp-and-you/index.html | 184 +++++++++++++++++++ blog/index.atom | 108 ++++++++++- blog/index.html | 112 +++++++++++ blog/index.rss | 106 +++++++++++ blog/tag/evalserver.atom | 117 ++++++++++++ blog/tag/evalserver.rss | 117 ++++++++++++ blog/tag/evalserver/index.html | 204 +++++++++++++++++++++ blog/tag/seccomp.atom | 117 ++++++++++++ blog/tag/seccomp.rss | 117 ++++++++++++ blog/tag/seccomp/index.html | 204 +++++++++++++++++++++ sitemap.xml | 24 ++- 13 files changed, 1412 insertions(+), 6 deletions(-) create mode 100644 blog/2017/10/10/seccomp-and-you/index.html create mode 100644 blog/tag/evalserver.atom create mode 100644 blog/tag/evalserver.rss create mode 100644 blog/tag/evalserver/index.html create mode 100644 blog/tag/seccomp.atom create mode 100644 blog/tag/seccomp.rss create mode 100644 blog/tag/seccomp/index.html diff --git a/blog/2017/09/28/new-blog/index.html b/blog/2017/09/28/new-blog/index.html index f61ae83..9872df0 100644 --- a/blog/2017/09/28/new-blog/index.html +++ b/blog/2017/09/28/new-blog/index.html @@ -76,6 +76,8 @@ and perform an action on it.

diff --git a/blog/2017/10/02/new-old-perls/index.html b/blog/2017/10/02/new-old-perls/index.html index 9fb0077..4381f69 100644 --- a/blog/2017/10/02/new-old-perls/index.html +++ b/blog/2017/10/02/new-old-perls/index.html @@ -67,9 +67,9 @@ directory on the root filesystem. This was done to make getting them to work in @@ -83,6 +83,8 @@ directory on the root filesystem. This was done to make getting them to work in diff --git a/blog/2017/10/10/seccomp-and-you/index.html b/blog/2017/10/10/seccomp-and-you/index.html new file mode 100644 index 0000000..1c4f4f8 --- /dev/null +++ b/blog/2017/10/10/seccomp-and-you/index.html @@ -0,0 +1,184 @@ + + + + + + + + + + Seccomp and you - Perlbot.pl pastebin + + + + +
+ + +
+
+
+
+
+
+

Seccomp and you

+ + + +

Tags: + + +

+ + +
+
+

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).

+ +
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
+
+ +

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.

+ +

I've created a few profiles to start with

+ +
    +

  • stdio +Allow reading from STDIN, and writing to STDOUT/STDERR.

    • +

  • 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

    • +

  • 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

    • +

  • file_tty +Adds O_NOCTTY to the allowed flags passed to open() and similar calls

    • +

  • file_readonly +Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and +similar calls

    • +

  • 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.

    • +

  • 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.

    • +

  • 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, +CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID +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.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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.).

+ +

=== Handling flags to syscalls

+ +

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.

+ +

{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},

+ +

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.

+ +

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.

+ +
+ + + + + +
+
+ +
+ + + + +
+
+
+ + + + + diff --git a/blog/index.atom b/blog/index.atom index b28f4c8..f6b12c7 100644 --- a/blog/index.atom +++ b/blog/index.atom @@ -2,11 +2,117 @@ https://perlbot.pl/blog/ Perlbot.pl pastebin - 2017-10-02T00:00:00Z + 2017-10-10T00:00:00Z Statocles + + https://perlbot.pl/blog/2017/10/10/seccomp-and-you/ + Seccomp and you + + 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).

+ +
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
+
+ +

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.

+ +

I've created a few profiles to start with

+ +
    +

  • stdio +Allow reading from STDIN, and writing to STDOUT/STDERR.

    • +

  • 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

    • +

  • 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

    • +

  • file_tty +Adds O_NOCTTY to the allowed flags passed to open() and similar calls

    • +

  • file_readonly +Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and +similar calls

    • +

  • 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.

    • +

  • 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.

    • +

  • 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, +CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID +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.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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.).

+ +

=== Handling flags to syscalls

+ +

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.

+ +

{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},

+ +

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.

+ +

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.

+ + +

Tags: + evalserver + seccomp +

+ + ]]> + 2017-10-10T00:00:00Z + + + https://perlbot.pl/blog/2017/10/02/new-old-perls/ New old perls diff --git a/blog/index.html b/blog/index.html index 77f8af5..1b204e4 100644 --- a/blog/index.html +++ b/blog/index.html @@ -34,6 +34,116 @@
+
+
+

Seccomp and you

+ + + +

Tags: + + +

+ +
+ +

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).

+ +
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
+
+ +

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.

+ +

I've created a few profiles to start with

+ +
    +

  • stdio +Allow reading from STDIN, and writing to STDOUT/STDERR.

    • +

  • 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

    • +

  • 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

    • +

  • file_tty +Adds O_NOCTTY to the allowed flags passed to open() and similar calls

    • +

  • file_readonly +Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and +similar calls

    • +

  • 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.

    • +

  • 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.

    • +

  • 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, +CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID +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.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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.).

+ +

=== Handling flags to syscalls

+ +

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.

+ +

{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},

+ +

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.

+ +

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.

+ + + +

New old perls

@@ -114,6 +224,8 @@ and perform an action on it.

diff --git a/blog/index.rss b/blog/index.rss index 4e8c0dc..16ffaf7 100644 --- a/blog/index.rss +++ b/blog/index.rss @@ -6,6 +6,112 @@ Blog feed of Perlbot.pl pastebin Statocles 0.086 + + Seccomp and you + https://perlbot.pl/blog/2017/10/10/seccomp-and-you/ + https://perlbot.pl/blog/2017/10/10/seccomp-and-you/ + 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).

+ +
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
+
+ +

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.

+ +

I've created a few profiles to start with

+ +
    +

  • stdio +Allow reading from STDIN, and writing to STDOUT/STDERR.

    • +

  • 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

    • +

  • 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

    • +

  • file_tty +Adds O_NOCTTY to the allowed flags passed to open() and similar calls

    • +

  • file_readonly +Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and +similar calls

    • +

  • 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.

    • +

  • 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.

    • +

  • 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, +CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID +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.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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.).

+ +

=== Handling flags to syscalls

+ +

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.

+ +

{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},

+ +

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.

+ +

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.

+ + +

Tags: + evalserver + seccomp +

+ + ]]> + + Tue, 10 Oct 2017 00:00:00 +0000 + + New old perls https://perlbot.pl/blog/2017/10/02/new-old-perls/ diff --git a/blog/tag/evalserver.atom b/blog/tag/evalserver.atom new file mode 100644 index 0000000..cea576a --- /dev/null +++ b/blog/tag/evalserver.atom @@ -0,0 +1,117 @@ + + + https://perlbot.pl/blog/tag/evalserver/ + Perlbot.pl pastebin + 2017-10-10T00:00:00Z + + + Statocles + + + https://perlbot.pl/blog/2017/10/10/seccomp-and-you/ + Seccomp and you + + 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).

+ +
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
+
+ +

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.

+ +

I've created a few profiles to start with

+ +
    +

  • stdio +Allow reading from STDIN, and writing to STDOUT/STDERR.

    • +

  • 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

    • +

  • 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

    • +

  • file_tty +Adds O_NOCTTY to the allowed flags passed to open() and similar calls

    • +

  • file_readonly +Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and +similar calls

    • +

  • 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.

    • +

  • 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.

    • +

  • 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, +CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID +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.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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.).

+ +

=== Handling flags to syscalls

+ +

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.

+ +

{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},

+ +

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.

+ +

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.

+ + +

Tags: + evalserver + seccomp +

+ + ]]> + 2017-10-10T00:00:00Z + + + + + diff --git a/blog/tag/evalserver.rss b/blog/tag/evalserver.rss new file mode 100644 index 0000000..109aa2d --- /dev/null +++ b/blog/tag/evalserver.rss @@ -0,0 +1,117 @@ + + + + Perlbot.pl pastebin + https://perlbot.pl/blog/tag/evalserver/ + + Blog feed of Perlbot.pl pastebin + Statocles 0.086 + + Seccomp and you + https://perlbot.pl/blog/2017/10/10/seccomp-and-you/ + https://perlbot.pl/blog/2017/10/10/seccomp-and-you/ + 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).

+ +
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
+
+ +

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.

+ +

I've created a few profiles to start with

+ +
    +

  • stdio +Allow reading from STDIN, and writing to STDOUT/STDERR.

    • +

  • 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

    • +

  • 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

    • +

  • file_tty +Adds O_NOCTTY to the allowed flags passed to open() and similar calls

    • +

  • file_readonly +Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and +similar calls

    • +

  • 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.

    • +

  • 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.

    • +

  • 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, +CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID +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.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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.).

+ +

=== Handling flags to syscalls

+ +

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.

+ +

{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},

+ +

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.

+ +

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.

+ + +

Tags: + evalserver + seccomp +

+ + ]]> + + Tue, 10 Oct 2017 00:00:00 +0000 + + + + + diff --git a/blog/tag/evalserver/index.html b/blog/tag/evalserver/index.html new file mode 100644 index 0000000..a6e3d7e --- /dev/null +++ b/blog/tag/evalserver/index.html @@ -0,0 +1,204 @@ + + + + + + + + + + Perlbot.pl pastebin + + + + + + +
+ + +
+
+
+
+
+ + +
+
+

Seccomp and you

+ + + +

Tags: + + +

+ +
+ +

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).

+ +
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
+
+ +

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.

+ +

I've created a few profiles to start with

+ +
    +

  • stdio +Allow reading from STDIN, and writing to STDOUT/STDERR.

    • +

  • 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

    • +

  • 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

    • +

  • file_tty +Adds O_NOCTTY to the allowed flags passed to open() and similar calls

    • +

  • file_readonly +Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and +similar calls

    • +

  • 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.

    • +

  • 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.

    • +

  • 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, +CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID +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.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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.).

+ +

=== Handling flags to syscalls

+ +

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.

+ +

{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},

+ +

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.

+ +

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.

+ + + +
+ +
    + + +
+ + + + +
+
+ +
+ + + +

Feeds

+ + +
+
+
+ + + + + diff --git a/blog/tag/seccomp.atom b/blog/tag/seccomp.atom new file mode 100644 index 0000000..5b9fa01 --- /dev/null +++ b/blog/tag/seccomp.atom @@ -0,0 +1,117 @@ + + + https://perlbot.pl/blog/tag/seccomp/ + Perlbot.pl pastebin + 2017-10-10T00:00:00Z + + + Statocles + + + https://perlbot.pl/blog/2017/10/10/seccomp-and-you/ + Seccomp and you + + 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).

+ +
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
+
+ +

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.

+ +

I've created a few profiles to start with

+ +
    +

  • stdio +Allow reading from STDIN, and writing to STDOUT/STDERR.

    • +

  • 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

    • +

  • 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

    • +

  • file_tty +Adds O_NOCTTY to the allowed flags passed to open() and similar calls

    • +

  • file_readonly +Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and +similar calls

    • +

  • 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.

    • +

  • 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.

    • +

  • 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, +CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID +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.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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.).

+ +

=== Handling flags to syscalls

+ +

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.

+ +

{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},

+ +

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.

+ +

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.

+ + +

Tags: + evalserver + seccomp +

+ + ]]> + 2017-10-10T00:00:00Z + + + + + diff --git a/blog/tag/seccomp.rss b/blog/tag/seccomp.rss new file mode 100644 index 0000000..a402eda --- /dev/null +++ b/blog/tag/seccomp.rss @@ -0,0 +1,117 @@ + + + + Perlbot.pl pastebin + https://perlbot.pl/blog/tag/seccomp/ + + Blog feed of Perlbot.pl pastebin + Statocles 0.086 + + Seccomp and you + https://perlbot.pl/blog/2017/10/10/seccomp-and-you/ + https://perlbot.pl/blog/2017/10/10/seccomp-and-you/ + 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).

+ +
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
+
+ +

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.

+ +

I've created a few profiles to start with

+ +
    +

  • stdio +Allow reading from STDIN, and writing to STDOUT/STDERR.

    • +

  • 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

    • +

  • 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

    • +

  • file_tty +Adds O_NOCTTY to the allowed flags passed to open() and similar calls

    • +

  • file_readonly +Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and +similar calls

    • +

  • 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.

    • +

  • 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.

    • +

  • 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, +CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID +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.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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.).

+ +

=== Handling flags to syscalls

+ +

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.

+ +

{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},

+ +

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.

+ +

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.

+ + +

Tags: + evalserver + seccomp +

+ + ]]> + + Tue, 10 Oct 2017 00:00:00 +0000 + + + + + diff --git a/blog/tag/seccomp/index.html b/blog/tag/seccomp/index.html new file mode 100644 index 0000000..ece6f55 --- /dev/null +++ b/blog/tag/seccomp/index.html @@ -0,0 +1,204 @@ + + + + + + + + + + Perlbot.pl pastebin + + + + + + +
+ + +
+
+
+
+
+ + +
+
+

Seccomp and you

+ + + +

Tags: + + +

+ +
+ +

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).

+ +
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
+
+ +

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.

+ +

I've created a few profiles to start with

+ +
    +

  • stdio +Allow reading from STDIN, and writing to STDOUT/STDERR.

    • +

  • 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

    • +

  • 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

    • +

  • file_tty +Adds O_NOCTTY to the allowed flags passed to open() and similar calls

    • +

  • file_readonly +Adds O_NONBLOCK, O_EXCL, O_RDONLY, O_NOFOLLOW, O_CLOEXEC to be passed to open() and +similar calls

    • +

  • 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.

    • +

  • 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.

    • +

  • 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, +CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID +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.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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.).

+ +

=== Handling flags to syscalls

+ +

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.

+ +

{syscall => 'openat', permute_rules => [['2', '==', \'open_modes']]},

+ +

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.

+ +

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.

+ + + +
+ +
    + + +
+ + + + +
+
+ +
+ + + +

Feeds

+ + +
+
+
+ + + + + diff --git a/sitemap.xml b/sitemap.xml index 01b8f9e..33f4b1e 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -4,13 +4,13 @@ https://perlbot.pl/ weekly 0.5 - 2017-10-02 + 2017-10-23 https://perlbot.pl/blog/ daily 0.3 - 2017-10-02 + 2017-10-10 https://perlbot.pl/blog/2017/09/28/new-blog/ @@ -24,11 +24,29 @@ 0.5 2017-10-02 + + https://perlbot.pl/blog/2017/10/10/seccomp-and-you/ + weekly + 0.5 + 2017-10-10 + + + https://perlbot.pl/blog/tag/evalserver/ + daily + 0.3 + 2017-10-10 + + + https://perlbot.pl/blog/tag/seccomp/ + daily + 0.3 + 2017-10-10 + https://perlbot.pl/page/seccomp/ weekly 0.5 - 2017-10-02 + 2017-10-23