Configuration discussion

[bluejekyll]

Some principles:

• We don't want a new DSL, choose something off the shelf, KISS
  • Choose a simple and clear config language, TOML?
• We want to lean on declarative configuration where it makes sense
• For imperative support, just rely on external scripting languages being called.
  • Does this expose potential issues for privileged execution?
• Let's make it obvious what all dependencies are in a system
  • Discovery of services should be easy
  • Services should register the types of services they offer
  • Service types are probably mostly mutually exclusive, do we support service types that can be provided by more than one tool?

[bluejekyll]

example TOML, let's assume this lives in a directory: /etc/verm.rc/named/Verm.toml

All config loads would assume default path in that directory, so start executables would be siblings of the toml. All of them can be optional, except for the toml file. We should provide a CLI to create a new rc directory.

Should we allow a naked toml as well: /etc/verm.rc/named.toml?

name = "Trust DNS"
provides = "dns"

# command line arguments, etc.
#   perhaps this is rooted in the config path of like /etc/vermilion.rc
#   aka start?
[command]
path = "named"
arguments = ["--debug", "--config_path=/etc/named"]

# defaults to look for stop executable in directory
[stop]
path = "stop"

# we should bake smoke tests in directly to test the service after it starts (non-destructive obviously).
[smoke_test]
path = "/test/bin/host"
# ...

# Are there default dependencies? or globs? like `posix = ["network", "fs", ...]`
[dependencies]
network = [version = "API version?", optional = "false"]
fs = "*"

obviously not fully fleshed out...

[tarcieri]

All config loads would assume default path in that directory, so start executables would be siblings of the toml.

This is okay if done carefully. I'd recommend always using canonical paths internally.

If you want an application framework with a built-in TOML configuration loader, I'll self-plug Abscissa as something that fits the bill (and also is engineered to support things like hot config reloads).

[bluejekyll]

This is okay if done carefully.

To be clear here, I think it might be cool to try and achieve some amount of defaults that just work, where config isn't necessarily needed. I agree that we need to be careful here.

[dckc]

Where in named.toml is access to UDP port 53 granted?

That is: I hope all access is granted explicitly, so that the system is secure by default. Alternatives include Docker, where I gather that the state-of-the-art is a to write a seccomp security profile specifying which system calls are allowed and which are not. And even after all that tedium, I don't think I can specify that port 53 is allowed but others are not.

[tarcieri]

@dckc seccomp is good to lean on. In the particular case of network ports, there's a number of other things to potentially lean on (on Linux at least), including cap_net_bind, iptables/BPF (the latter being what seccomp is based on as well), and SELinux port labels

[bluejekyll]

I like this idea. I worry that we’ll reimplement apparmor and other tools, but maybe we should? Should we perform that configuration in this config or in a separate file? The benefit of a separate file would be to keep this one focused on startup options, and the other to be centered on capability grants. But maybe that would be annoying.

[dckc]

... I worry that we’ll reimplement apparmor and other tools,

yeah; well... indeed, starting with linux, where processes get a bunch of authority / access by default and plugging all the holes is a thankless game of whack-a-mole.

The capsicum-linux folks eventually ran out of steam, as did cloudABI for linux.

It would almost be easier to start over with WASI.

but maybe we should?

Somebody should, please!

Not only that, but I'd like you to re-consider IPC as a non-goal. At least: the part of systemd that sets up sockets seems pretty important. I'd love to see bus1 pick up steam.

For more background, see My Capability Security 2017 Wish-List.

[bluejekyll]

It would almost be easier to start over with WASI.

Sorry in what sense do you mean with WASI? Meaning this system would be built in WASI? That might be far to restrictive in working with some of the OS primitives that will be needed here.

re-consider IPC as a non-goal

in #2 I call out IPC as something needed. I'm more stating that we don't think we want to create a general purpose IPC like dbus, but we can discuss it. I would much prefer that we rely on the OS here.

For more background, see My Capability Security 2017 Wish-List.

sweet, thanks. good reading.

[dckc]

... Meaning this system would be built in WASI?

Yes (in a hypothetical sense).

That might be far to restrictive in working with some of the OS primitives that will be needed here.

Of course.