Project

General

Profile

Actions

Feature #2895

closed

OpenBSD pledge support

Added by Emmanuel Roullit almost 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Target version:
Effort:
Difficulty:
Label:

Description

Currently, on OpenBSD, Suricata runs with unrestricted access to the available system operation.
The amount of allowed system operations can be restricted to a minimum without hindering Suricata operation by leveraging the pledge(2) [1] syscall.

So far, Suricata can run with the following promises:
  • "stdio" to allow read(2) on IPS rules and write(2) on log file
  • "rpath wpath cpath" to allow log rotation
  • "unix" to operate the control unix socket and log unix sockets
  • "dns" to retrieve DNS from recvfrom(2)/sento(2) in IPFW mode
  • "bpf" as suricata uses libpcap, which uses the BIOCGSTATS operation

If you know a use case which requires an extension on the promises list, let me know.

[1]: https://man.openbsd.org/pledge.2

Actions #1

Updated by Victor Julien almost 6 years ago

  • Target version changed from 4.1.4 to TBD

Not sure if it is relevant, but the rule reload requires read access to the config and rule files after Suricata has been started up.

Actions #2

Updated by Emmanuel Roullit almost 6 years ago

It is relevant. The rule reload command via the control unix socket is functional and would require the promises "rpath stdio" listed above.

Actions #3

Updated by Victor Julien almost 6 years ago

Another thought: we have lua scripting support, and the lua scripts can do pretty much whatever they like (also after a reload). Not sure how to integrate this, although seems to actually be a great reason to use something like pledge.

Actions #4

Updated by Emmanuel Roullit almost 6 years ago

I am going to check this out.

Actions #6

Updated by Emmanuel Roullit almost 6 years ago

I dug into the LUA script handling and they remains usable after pledge though doing system operations out of the promised operations would SIGABRT.
However, LUA script initialization step occurs before pledge, meaning that the user can still use all the system operation he deems fit at that stage.

Actions #7

Updated by Victor Julien almost 6 years ago

I think it would mean that during a rule reload the detection lua scripts would not initialize though. Or can the pledge be done per thread? Then the thread(s) that reload the rules could perhaps be excluded?

Actions #8

Updated by Emmanuel Roullit almost 6 years ago

Pledge does not interfere with the initialization process after a reload unless it performs an operation out of the promised system operations.
Could you point me out which detection LUA script you refer so that I can see what they are doing ?

Pledge is done on a process basis meaning that once a pledge is performed, it applies to all present and future threads at once.

Actions #9

Updated by Victor Julien almost 6 years ago

With a reload I mean an internal rule reload in a running Suricata process, either triggered by the USR2 signal or a unix socket command. It will create a new detection engine, initialize the rules (incl any lua scripts) and when it's ready swap the old and new detection engines.

The other way this can happen is with the delayed detect support, which is pretty much the same, except Suricata starts with an empty ruleset, starts processing packets and triggers a rule reload immediately while also already processing packets.

Actions #10

Updated by Emmanuel Roullit almost 6 years ago

I have setup a suricata from master with suggested pledge changeset build with:

./configure --disable-gccmarch-native --enable-ipfw --disable-rust --enable-luajit

With the vanilla suricata.yaml with the following changes:

[...]
  - lua:
      enabled: yes
      scripts-dir: /home/emma/suricata/lua/
      scripts:
         - fast.lua
[...]

I start an instance of suricata listening to live interface em0 and issued those commands:

----
obsd1$ uname -a              
OpenBSD obsd1 6.4 GENERIC.MP#748 amd64
obsd1$ ps ax | grep suricata
 5974 p6  S+p     0:05.59 ./src/.libs/suricata -i em0 -l logs -c suricata.yaml # the 'p' show this process has called pledge
  843 p8  R+/0    0:00.00 grep suricata
obsd1$ doas kill -USR2 95277
obsd1$ doas suricatasc
>>> ruleset-reload-rules
Success:
"done" 

The suricata log file look like that:

obsd1$ doas ./src/.libs/suricata -i em0 -l logs -c suricata.yaml                                                                                                                                                                                                                   
[5974] 25/3/2019 -- 15:52:58 - (suricata.c:1058) <Notice> (LogVersion) -- This is Suricata version 5.0.0-dev (rev 71ef7902d)                                                                                                                                                                                                  
[5974] 25/3/2019 -- 15:52:58 - (counters.c:264) <Warning> (StatsInitCtxPreOutput) -- [ERRCODE: SC_WARN_DEFAULT_WILL_CHANGE(318)] - in 5.0 the default for decoder event stats will go from 'decoder.<proto>.<event>' to 'decoder.event.<proto>.<event>'. See ticket #2225. To suppress this message, set stats.decoder-events-prefix in the yaml.                                                                                                                                                                                                                                                                                                            
[5974] 25/3/2019 -- 15:52:58 - (output-json-dns.c:1285) <Warning> (JsonDnsParseVersion) -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - eve-log dns version not found, forcing it to version 1                                                                                                                                    
[5974] 25/3/2019 -- 15:52:58 - (output-json-dns.c:1285) <Warning> (JsonDnsParseVersion) -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - eve-log dns version not found, forcing it to version 1                                                                                                                                    
[5974] 25/3/2019 -- 15:52:58 - (output-json-stats.c:468) <Warning> (OutputStatsLogInitSub) -- [ERRCODE: SC_WARN_EVE_MISSING_EVENTS(319)] - eve.stats will not display all decoder events correctly. See #2225. Set a prefix in stats.decoder-events-prefix. In 5.0 the prefix will default to 'decoder.event'.                
[5974] 25/3/2019 -- 15:53:04 - (tm-threads.c:2157) <Notice> (TmThreadWaitOnThreadInit) -- all 3 packet processing threads, 4 management threads initialized, engine started.                                                                                                                                                  
[5974] 25/3/2019 -- 15:53:39 - (detect-engine.c:3620) <Notice> (DetectEngineReload) -- rule reload starting
[5974] 25/3/2019 -- 15:53:46 - (detect-engine.c:3691) <Notice> (DetectEngineReload) -- rule reload complete # Rule reload triggered by SIGUSR2
[5974] 25/3/2019 -- 15:58:02 - (detect-engine.c:3620) <Notice> (DetectEngineReload) -- rule reload starting
[5974] 25/3/2019 -- 15:58:08 - (detect-engine.c:3691) <Notice> (DetectEngineReload) -- rule reload complete # Rule reload triggered by 'ruleset-reload-rules' via UDS

Actions #11

Updated by Emmanuel Roullit over 5 years ago

I am using a pledged suricata since then for my day to day use/development and it works without a hitch.

Actions #12

Updated by Emmanuel Roullit over 5 years ago

We are using a pledged suricata on OpenBSD more than a month without hitch. If there are some questions hindering the merge of this changeset, I would gladly discussing. Otherwise, I have no further change to bring to this PR.

Actions #13

Updated by Victor Julien over 5 years ago

  • Status changed from New to Closed
  • Target version changed from TBD to 5.0beta1
  • Effort deleted (low)
  • Difficulty deleted (low)
Actions

Also available in: Atom PDF