view release on metacpan or  search on metacpan

lib/App/EvalServerAdvanced/Seccomp.pm  view on Meta::CPAN

=back

=head1 Rule definitions

    file_open:
      rules:
        - syscall: open
          tests:
            - [1, '==', '{{open_modes}}']
        - syscall: openat
          tests:
            - [2, '==', '{{open_modes}}']
        - syscall: close

Rules consist of a few attributes that specify what you're allowed to do.

=over

=item syscall

The most important part of a rule, without it you will end up with a fatal error.  Best practice is to specify the syscall by name, i.e. C<open> or C<openat>.  It will be resolved at runtime using the syscall map of the system automatically, so that ...

=item action

=item tests

This is probably the least elegant part of the config file, but I couldn't come up with a better setup/syntax for it.  This is a list of tests, all of which must pass, for the given syscall.

Each test is an array of three things, [argument, operator, value].

=over

=item argument

Which argument to the syscall you want to test.  Starting from 0 being the first argument.

=item operator

What operator to use for the test: == != >= <= < > or =~

The =~ operator takes the C<argument> to the syscall and uses the C<value> as a bit mask.  It passes if all the bits from the mask are set in the argument, ignoring any not present in the mask.

=item value

This is the value you want to test for.  It can be either a literal integer value or it can be a string containing a set of constants and bitwise operations.  It uses L<App::EvalServerAdvanced::ConstantCalc> to do the math and you should look at that...

Some examples

    'O_CLOEXEC|O_EXCL|O_RDWR'

Also supported are using automatically permutated values by using a string like '{{ open_modes }}'.  In this case all possible values will be pre-generated and substituted into the rule to allow any valid set of flags in a syscall

=back

=back

=head1 SECURITY

This is an excercise in defense in depths.  The default rulesets
provide a bit of protection against accidentally running knowingly dangerous syscalls.

This does not provide absolute security.  It relies on the fact that the syscalls allowed
are likely to be safe, or commonly required for normal programs to function properly.

In particular there are two syscalls that are allowed that are involved in the Dirty COW
kernel exploit.  C<madvise> and C<mmap>, with these two you can actually trigger the Dirty COW
exploit.  But because the default rules restrict you from creating threads, you can't create the race
condition needed to actually accomplish it.  So you should still take some
other measures to protect yourself.

=head1 KNOWN ISSUES

=over

=item Compilation errors when loading plugins from the plugin base directory will result in it attempting to load the fully qualified module name.  This will be fixed in future versions to be a fatal error

=back

=head1 AUTHOR

Ryan Voots <simcop@cpan.org>

=cut