Figured it might be interesting to see a few tasks happening behind the scenes:
Reducing dependencies
Supply chain attacks can be seen everywhere. Modern software development seems to mandate adding a ton of dependencies to your product and then mostly hoping no direct or transitive dependency get maliciously changed. Solving this is difficult (or impossible?), but there’s an alternative to greatly reduce the risk: Removing dependencies and careful evaluation (by actually inspecting the source code) for every dependency included. Recently a few have been removed from info-beamer’s backend. The largest one being GitPython/gitdb/smmap:
This trio of packages allows interaction with git repositories. info-beamer uses those to either directly pull packages from git sources like github or allow developers to directly push package source code. This is an essential feature as available package are not strictly part of the info-beamer platform but features that are provided on-top of it either by info-beamer itself or by other developers.
Those git libraries provide a ton of features info-beamer doesn’t use. Basically the only feature needed is querying available branches, listing files within a branch and streaming individual content. All of those features have been reimplemented in around 400 lines of code with the only dependency being the git binary itself (which was already used by GitPython previously). The new code is now less complex than before and allows easier integration with sandboxing…
Sandboxing
Speaking of sandboxes: Enforcing a security boundary between the info-beamer’s backend and user provided content (like images/videos) or those git repositories is very important. For images, videos and other uploaded asset types an earlier blog post already goes into a lot of details. Sandboxing git is a bit more complex as multiple tools need to work together. For example ssh could be used to establish network connections in case source code is pulled from private repositories. git and ssh are executed in a locked down environment and further restricted by a seccomp policy. This greatly reduces the attack surface of the kernel itself as most syscall are actually not needed for them to work. And those that are required can be further restricted. For example this is the policy for ioctl which itself is a huge attack surface as every device driver provides various ioctl possibilities when left unrestricted:
policy_add(p, CALL(ioctl), ACT_EPERM, pred_equal(1, TCGETS));
policy_add(p, CALL(ioctl), ACT_ALLOW, pred_equal(1, FIONREAD));
Similar measures can be used to restrict which type of socket can be created. Being a white list, this would prevent the recent copy.fail vulnerability as that requires socket of domain AF_ALG.
policy_add(p, CALL(socket), ACT_ALLOW,
pred_equal(0, AF_INET),
pred_has_any(1, SOCK_DGRAM),
pred_equal(2, IPPROTO_IP));
...
policy_add(p, CALL(socket), ACT_EPERM, pred_equal(0, AF_NETLINK));
When just reading repository data, of course creating new sockets (or accepting connections) is entirely forbidden.
A new API endpoint
Recently a customer created an internal content management dashboard utilizing the info-beamer API. There are various ways to integrate info-beamer with another content management system (expect a future post about this). In this case the customer mainly utilized a single setup per device as well as native playlists for organizing content per device. While developing their dashboard, it became clear that it would be quite helpful to have a quicker way to see which playlist is used by each setup without iterating over either each playlist or each setup individually. The result is now a new reference list API call. It allows very fast queries about various types of object references within your account. In their case a list of setups and the playlists each of them references.