Bad permissions/rules when Suricata is invoked by Brimcap outside of Brim

[philrz]

Repro is with prerelease Brim build https://storage.googleapis.com/brimsec-releases/brim/v0.25.0-prerelease-a6d1e12b.0/linux/Brim-0.25.0-prerelease-a6d1e12b.0.deb on Ubuntu 18.04.

The user's intent in this case is to take advantage of the ability to do automated/scripted brimcap load operations outside of the Brim app. They install the app as usual and launch it for the first time. Then they create a new Pool and try to load some data.

$ /opt/Brim/resources/app.asar.unpacked/zdeps/zapi create -p wrccdc
pool created: wrccdc

$ /opt/Brim/resources/app.asar.unpacked/zdeps/brimcap load -p wrccdc -root "$HOME/.config/Brim/data/lake" ~/Downloads/wrccdc.pcap
  0.0% 96KiB/476MiB858KiB604B records=0 
Post "http://localhost:9867/pool/1tdBhRmj2VM67P3HMmqg2PZlmWH/log": suricatarunner exited with code 1
stdout: (no output)
stderr:
cp: cannot create regular file '/opt/Brim/resources/app.asar.unpacked/zdeps/suricata/brim-conf-run.yaml': Permission denied
/opt/Brim/resources/app.asar.unpacked/zdeps/suricata/suricatarunner: line 24: /opt/Brim/resources/app.asar.unpacked/zdeps/suricata/brim-conf-run.yaml: Permission denied
7/6/2021 -- 11:06:49 - <Error> - [ERRCODE: SC_ERR_FATAL(171)] - failed to open file: /opt/Brim/resources/app.asar.unpacked/zdeps/suricata/brim-conf-run.yaml: No such file or directory

The permissions issue is caused by how suricatarunner currently works. On Linux it looks like:

#!/usr/bin/env bash

dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" >/dev/null 2>&1 && pwd)"

if [ -z "$BRIM_SURICATA_USER_DIR" ]; then
    userdir="$dir"
    ruledir="$dir/var/lib/suricata/rules"
else
    userdir="$BRIM_SURICATA_USER_DIR"
    ruledir="$userdir/rules"
    if [ ! -d "$ruledir" ]; then
        mkdir -p "$ruledir"
    fi
    if [ ! -f "$ruledir/suricata.rules" ]; then
        cp "$dir/var/lib/suricata/rules/suricata.rules" "$ruledir"
    fi
fi

cp "$dir/brim-conf.yaml" "$userdir/brim-conf-run.yaml"

echo "
rule-files:
  - $ruledir/suricata.rules
" >> "$userdir/brim-conf-run.yaml"

LD_LIBRARY_PATH="$dir/bin" exec "$dir/bin/suricata" -c "$userdir/brim-conf-run.yaml" --set classification-file="$dir/etc/suricata/classification.config" --set reference-config-file="$dir/etc/suricata/reference.config" --set threshold-file="$dir/etc/suricata/threshold.config" -r -

When brimcap is invoked by the Brim app, the lines at https://github.com/brimdata/brim/blob/60788403eb0ad0f454278571e45a68b971a9379f/ppl/lake/lake.ts#L101-L103 avoid this problem because the $BRIM_SURICATA_USER_DIR gets set to a spot below the user-owned Electron data dir ($HOME/config/Brim on Linux), which is separate from the root-owned directory tree where the app gets unpacked (below /opt/Brim on Linux). Since I invoked brimcap outside the app, that $dir variable in the suricatarunner script ended up set to /opt/Brim/resources/app.asar.unpacked/zdeps/suricata, so the cp line fails because the non-root user lacks the permissions to write to to that location.

I'd only expect to see this specific permissions problem on Linux, since on Windows or macOS the user likely has write permission to the directory where the app was upacked. However, having stared at this for a bit, I realize the problem is a bit wider than just permissions, since the Suricata rules are also a factor. Right now the update of the Suricata rules is triggered whenever the Brim app launches. But if the user executes brimcap outside the app like we've done here, they'll be running against the rules in the unpacked app directory, which are the ones that shipped originally with the app, and hence are old. That means the user would get different alerts for pcaps imported directly into the app vs. from outside, which I expect would create confusion. It seems this problem would affect all platforms, not just Linux.

I'm not sure how to best go about addressing this. The one idea I've come up with thus far would be to ensure that the suricatarunner and suricataupdater that get packaged with Brim effectively have the $BRIM_SURICATA_USER_DIR baked into them such that they find & use the location below the Electron user dir even when invoked outside the app (maybe we could modify them as part of the build procedure?) It doesn't seem like our installers currently prompt the user to select alternate install locations, so I sense it would be ok to assume the locations:

• Windows - %APPDATA%\Brim\suricata
• macOS - $HOME/Library/Application Support/Brim/suricata
• Linux - $HOME/.config/Brim/suricata

...and check whether the directory exists. If it doesn't, we could fall back on the current behavior.

For Brimcap users that work entirely outside the Brim app (a minority, but I expect it will come up) I don't see the exposure as being the same. If someone were to manually unpack a Brimcap artifact they download from https://github.com/brimdata/brimcap/releases, they should have write permission in whatever directory tree they unpack it. As for rules, in the "custom Brimcap" article currently under review at brimdata/brimcap#72, I've set expectations that in this case the user would be responsible for doing the rules updates themselves (via cron, etc.) since there's no app that'll do it for them.

[philrz]

Note that there's a link to this issue from the "Remote Workspaces (v0.25.0+)" article in the Brim wiki. If/when this issue gets addressed, that should be updated.