Hacker News Reader

Comment by lelanthran | Hacker News Reader

> Run nothing as root, unless absolutely required.

Good advice, to be sure. Especially anything getting network input[1].

In a reddit thread once, I pointed out that there is no need for any server/service program to have any access to the file holding the startup configuration. There really isn't.

If the user needs to write that configuration, use a different program with elevated privileges that do nothing but write that file.

When the server starts up and needs to read config, it should start up as a user with elevated privileges, read the entire file in the first 3 lines of `main()`, then drop privileges and continue execution as normal. It will never be able to access that file during the rest of its execution.

I don't think I've ever had a comment downvoted on reddit so hard!

[1] No need to say "untrusted network input" - all input is untrusted unless you are literally in control of both parties.

View on HN

This would add complexity and in particular couple the application to a specific combination of operating system/privileges model/file system. How great is the benefit, really? How many things are exploited by the application writing to its own startup config?

> This would add complexity

It would add fair bit of code, sure, but nicely isolated and not complex: It's three extra lines of code in the main function, and a separate utility to write the config.

Balance that against the fact that the server then never writes its own config - that code is moved into the configuration-writing application, which removes complexity from the server application.

> and in particular couple the application to a specific combination of operating system/privileges model/file system.

It does indeed couple it to those systems that are sufficiently POSIX-like; however if you are writing a server that doesn't run on a Linux or BSD-derived system, you are out in the left field anyway.

> How great is the benefit, really? How many things are exploited by the application writing to its own startup config?

Well, the comment I made was in a thread discussing a vulnerability in the Microsoft Teams application[1] which was exploitable to retrieve the user's secrets[2] from their config file.

So, that particular comment was very much on-topic and in-context.

[1] Not sure if it was on all platforms or not.

[2] Or something - I forget exactly what was leaked.

most methods of getting persistence involve writing to some config file somewhere. Having your app not have rights to write to any sort of config or code files probably is fairly beneficial.

How much is probably going to depends on how everything is configured, what your threat model is, what service it is, and a million other things.

Interesting idea, I quite like it. At the same time we have things like kubernetes, where most people store secrets in the environment variables that every single process in the container can read.

This is what HAProxy does. At least the reading then dropping privileges. The admin writes the config themselves (or uses their own tool).

Reply on news.ycombinator.com