Re: Environment-variable security?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 13.11.18 12:22, David Parsley (parsley@xxxxxxxxxxxxx) wrote:

> Google "twelve-factor app". Excerpt from a random article on medium.com:

Maybe following "random articles" blindly is not really the best
approach to computer security...

> You're correct that's not a Unix security standard, and I couldn't find one
> - it's just a fairly common practice because environment variables are easy
> to use. Other systems engineers that I work with also rely on their
> environment being private from other users on large, multi-user research
> computing systems like the ones we manage. It's also a reasonable
> expectation that an unprivileged process can't trivially obtain the
> contents of a 0600:root:root file under /etc, or that a user-level exploit
> of an unrelated service could also trivially obtain that data.

Well, if you place the secrets in files with proper access modes, then
that's excellent, that's exactly what I suggested you to do.

I am just saying that then converting these then to env vars is a
really bad idea. Make the relevant tools read the files directly
instead of expecting them in an env var.

> I'll just go ahead and concede that I'm wrong, and that GOPHER_SLACK_TOKEN
> and HUBOT_SLACK_TOKEN shouldn't be in an env var, and that my co-workers
> are also wrong to store a particular password in their environment.
> Regardless, that doesn't make it OK for systemd to hand out the contents of
> of that file or make service environment vars available to unprivileged
> users. You can think I'm a stubborn damned ignoramus if you like - but I'd
> be surprised if you think I'm the *only* damned ignoramus who thinks that
> environment data should be private to the process owner and root. I'm just
> one of the few who happened to notice the warning in the logs and
> investigated it.

Well, it's not as easy as you suggest. it's not just the dbus
interface that is built like this, it's all over the place. in
systemd, and other tools too.

I am sorry, but that ship has sailed. You can try to close all the
holes you can find, but you started out with a very leaky concept
which is env vars, that have been around since the 1970s, and are used
all over the placein a myriad of ways, and exposed in gazillions
programs. You don't get to redefine them the way you need them to,
they are already used in ways incompatible with what you are trying to
do.

Or let's say this differently, let's talk again when you convinced the
kernel folks that they flush out all env vars whenever there's a
security transition, i.e. setuid, setgid, selinux context, ….

> I think the real point here is the information disclosure vulnerability.
> I'm going to suggest to my team that we consider making
> /run/dbus/system_bus_socket 440 or 400 - no reason for these non-privileged
> users to have access to that, anyway.

I mean, knock yourself out, but uh, oh. This is not how this all works.

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel