Suricata

These are my notes after looking into packaging Suricata as a Snap.

Why
Packaging Suricata as a Snap would allow us to create one single package that can be used across all popular Linux distributions. While I only tested x86_64 distributions, I believe the Snap store is capable of hosting packages for multiple architectures.

Confinement Mode
Snaps provide 2 confinement modes. Classic and strict. Classic gives the snap full access to the system. This would be required to give the Snap package a default Suricata feel of configuration in "/etc/suricata", logs in "/var/log/suricata", etc. This also increases the chances of the Snap package clashing with Suricata installed by other means (source, system package, etc). As Snaps appear to provide everything Suricata needs under strict confinement (af-packet, libpcap access), I only looked into strict confinement as that is the desired way to ship a Snap if possible.

Building
Building a snap is relatively simple using a YAML based configuration file. Example:
https://github.com/jasonish/suricata-snap/blob/master/snap/snapcraft.yaml#L21
This is mostly a standard build/install process with the following notable changes:

• The configuration files "/etc/suricata" are moved to "/usr/share/suricata/etc" as "/etc" is not really available at runtime, or read-only not allowing the user to edit the configuration
• A copy of the "/usr/lib/file/magic.mgc" is copied from the build image to a location that is part of the Suricata package as this file when provided by the system is not available under strict confinement

Multiple Versions
Snap appears to support multiple "tracks". I believe this would allow us to define a "5.0" and a "4.1" track. There is also the "latest" track which for Suricata at this time would be the same as "5.0". This would allow a user to stay on the "4.1" track and get "4.1" patches without a surprise upgrade to "5.0". A request has to be made to the Snap Store management for multiple tracks.

Installation
When Suricata is fully released to the Snap Store, a user could install Suricata like:

snap install suricata

On install, the configuration files that were copied to /usr/share/suricata/etc would be copied to the "confined" "/etc/suricata". On the host system this would be visible at a location like "/var/snap/suricata/current/etc/".

Running Interactively
All the Suricata commands are installed in "/var/lib/snapd/snap/bin" as:

• suricata
• suricata.sc
• suricata.update
  Unfortunately due to Snap naming conventions we can't have "suricatasc" and "suricata-update".

Other notes:

• To edit the configuration file one must edit "/var/snap/suricata/current/etc/suricata.yaml". But to run Suricata using this configuration file you still call it like "suricata -c /etc/suricata/suricata.yaml".
• Suricata-Update "just" works with "sudo suricata.update".
• Logs end up in /var/snap/suricata/current/log/eve.json.
• The user can also direct logs to their home directory with the usual "-l" command line parameter.
• Rule files and configuration files can also be specified on the command line, provided they live under the users home directory

Suricata as a Service
Snap provides the ability to define an application as a service. Under the hood it uses systemd, but lacks some configuration that you find on Ubuntu and CentOS (the /etc/{default,sysconfig}/suricata file). Instead it provides a way to set some configuration parameters. The test snap uses a wrapper script for the service that reads the command line arguments to use from a file. For example, to start the Suricata snap as a service:

snap set suricata service-args="-i eno1 -vvv" 
snap start suricata

• The "set" command above used the "configure" hook to create the file "/var/snap/suricata/current/etc/service-args" which the "service.sh" wrapper reads to set the command line variables
• The "set" feature of Snap allows setting any "key=val" pair which then calls your Snap defined configure hook, the above example was kept simple.

Unix Socket Control
Currently seeing issues with Suricata creating the control socket. It works fine on Fedora, but fails on Ubuntu. This is also one example of where the confinement can be slightly different between Linux distributions. This should be solvable by moving the socket location outside of "/var/run" or "/run".

Upgrading
Something to note about Snaps is they automatically upgrade in the background. I'm not sure if this can be stopped.

Final Thoughts
It appears that Suricata could run well package as a snap with the main issues being:

• The command names for suricatasc and suricata-update will be different
• The configuration, state data and log directories are different

We could get rid of most of that using classic confinement which would allow the Snap package to use /etc/suricata and /var/log/suricata.