Add systemd services

[Tachi107]

I'd be happy to send a patch for this! Could you please give me some pointers?

[lberrymage]

Absolutely!

The service files should have strict hardening options. A good template to start with is AttestationServer's systemd service. You can most likely add MemoryDenyWriteExecute=true to those options since we're not using Java. Further hardening options can be found with systemd-analyze security.

WorkingDirectory can be set to /var/lib/devportal and /var/lib/reposerver respectively. Neither devportal or reposerver need external network access since they're meant to be placed behind an nginx reverse proxy communicating over localhost.

Let me know if I can help with anything else.

[Tachi107]

Thanks for the reply :)

I've already contributed a few hardened systemd units to different projects like 1 and 2, so I think I won't have issues with that (hopefully!). My question was more about what the unit should be used for, as I don't fully understand how the devportal service behaves (e.g. the service should be a Type=simple one, right?).

I've been watching Accrescent for a while, and I'd really like to start helping from somewhere. So, sorry for my basic questions!

[lberrymage]

Oh okay. That's great!

The devportal is a Go web server which runs in the foreground and handles authentication for developers, accepts uploaded apps, and publishes them via the reposerver's REST API. It keeps track of state in ./devportal.db and will create and delete temporary directories with pseudorandom names in / to hold apps which haven't yet been published (of course we don't want them to actually be created in / in production, so that should be changed. I'm not sure why I didn't set that up as a relative path in the first place).

reposerver is also a Go web server that runs in the foreground, and it accepts apps via a REST API from devportal and publishes them in a directory tree located at PUBLISH_DIR (would it be easier to harden the unit if this path was static?). A static web server then serves the files at PUBLISH_DIR to make them available to the client app.

Is any of that helpful?

I appreciate the willingness to contribute by the way! Hopefully this will all be easier to digest once documentation is added.

[Tachi107]

The devportal is a Go web server which runs in the foreground and handles authentication for developers, accepts uploaded apps, and publishes them via the reposerver's REST API. It keeps track of state in ./devportal.db and will create and delete temporary directories with pseudorandom names in / to hold apps which haven't yet been published (of course we don't want them to actually be created in / in production, so that should be changed. I'm not sure why I didn't set that up as a relative path in the first place).

Using relative paths doesn't generally work well with systemd units, as services are supposed to write to the various standard Unix directories (see file-hierarchy(7)), but if you'd prefer not to make edits to the code it should be enough to set WorkingDirectory= to a subdirectory of /var/local/ or /var/lib/.

As for the temporary files written to /, could you point me to the piece of code that manages them? I can change that to use /tmp/ or $TMPDIR.

reposerver is also a Go web server that runs in the foreground, and it accepts apps via a REST API from devportal and publishes them in a directory tree located at PUBLISH_DIR (would it be easier to harden the unit if this path was static?). A static web server then serves the files at PUBLISH_DIR to make them available to the client app.

Dynamic paths should be fine; we could set the env var in the systemd unit itself, so that it knows which directories should be available to the service. systemd.exec(5) describes pretty well how env vars are handled in systemd units.

Is any of that helpful?

Yep :)

I appreciate the willingness to contribute by the way! Hopefully this will all be easier to digest once documentation is added.

Yeah, documentation would definitely make this easier

[lberrymage]

Using relative paths doesn't generally work well with systemd units, as services are supposed to write to the various standard Unix directories (see file-hierarchy(7)), but if you'd prefer not to make edits to the code it should be enough to set WorkingDirectory= to a subdirectory of /var/local/ or /var/lib/.

I'd prefer to use a relative path in tandem with WorkingDirectory= unless there's a good reason to do otherwise. Although this software is intended to be run on a typical systemd-based Linux distribution, I think it would be good to avoid platform-specific code as much as possible.

As for the temporary files written to /, could you point me to the piece of code that manages them? I can change that to use /tmp/ or $TMPDIR.

new_app.go and update_app.go (and yes, this duplication and fragmentation of file management is... subpar. I'm currently refactoring the entire developer portal to handle this better among other many other things. It's not exactly at a production stage yet :) ). I'm not sure if /tmp is the best place to put the APK sets though - they may be saved for longer than the host's uptime if submitted to the review process.

Dynamic paths should be fine; we could set the env var in the systemd unit itself, so that it knows which directories should be available to the service. systemd.exec(5) describes pretty well how env vars are handled in systemd units.

Great.

[lberrymage]

As of https://github.com/accrescent/devportal/commit/1c839fadc55d7a919b86bcd91a071631011fab0c the file storage backend is generic and so can easily point to wherever we like.