<div dir="ltr">I already scrub the environment when executing external scripts, and I've found that even after os.Unsetenv(...) the full environment is available to all processes owned by the robot in /proc/<pid>/environ. I'm fleshing out a solution where the process consumes the environment then scrubs it from proc w/ execve before starting the main loop that can run external scripts.<div><br></div><div>I don't know what mechanism made the environment available via API, so I wasn't sure if using an EnvironmentFile protected against that same mechanism. If effective, that would be a nice solution that parallels operation of the dockerized version.</div><div><br></div><div>So, anybody know what API calls an unprivileged user can make to get that information from the unit file? It'd be nice to test before and after to make sure the measure is effective.</div><div><br></div><div>Regards,</div><div>-David</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 12, 2018 at 4:23 PM aleivag <<a href="mailto:aleivag@gmail.com">aleivag@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>hi <span style="color:rgb(32,33,36);font-size:0.875rem;font-weight:bold;letter-spacing:0.2px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;white-space:nowrap">Reindl: </span>I was protecting against "systemctl cat/show" disclosure of information, as stated in the question; but i agree with you, and there are always risk in passing credential in env variables, but you can always try to mitigate them (e.g. the main process can read the variables and then remove them from the env). </div></div><div class="gmail_extra"><br><div class="gmail_quote">El 12 nov. 2018 5:54 p. m., "Reindl Harald" <<a href="mailto:h.reindl@thelounge.net" target="_blank">h.reindl@thelounge.net</a>> escribió:<br type="attribution"><blockquote class="m_1421339063491951893m_-2215618378718853811quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> <br> Am 12.11.18 um 21:41 schrieb aleivag:<div class="m_1421339063491951893m_-2215618378718853811quoted-text"><br> > You can define those secrets on /etc/robotsecret.txt, and then on your<br> > unit you do `EnvironmentFile=/etc/robotsecret.txt`<br> > <br> > then you protect /etc/robotsecret.txt as you would normally do<br> <br></div> and how does that protect anything?<br> <br> on a webserver running php it's just a one-liner to get $_ENV which is<br> why sensitive data don't belong there and should never exposed that way<br> like passwords in teh commandline are plain wrong<div class="m_1421339063491951893m_-2215618378718853811quoted-text"><br> <br> > On Mon, Nov 12, 2018 at 4:49 PM David Parsley <<a href="mailto:parsley@linuxjedi.org" rel="noreferrer" target="_blank">parsley@linuxjedi.org</a><br> > <mailto:<a href="mailto:parsley@linuxjedi.org" rel="noreferrer" target="_blank">parsley@linuxjedi.org</a>>> wrote:<br> > <br> > It's a fairly common practice to configure services and provide<br> > secrets with environment variables. For instance, both Hubot (made<br> > by Github) and Gopherbot (made by me) can get their Slack token from<br> > an environment variable. In my case,<br> > <a href="http://github.com/lnxjedi/ansible-role-gopherbot" rel="noreferrer noreferrer" target="_blank">github.com/lnxjedi/ansible-role-gopherbot</a><br></div> > <<a href="http://github.com/lnxjedi/ansible-role-gopherbot" rel="noreferrer noreferrer" target="_blank">http://github.com/lnxjedi/ansible-role-gopherbot</a>> stores the Slack<div class="m_1421339063491951893m_-2215618378718853811quoted-text"><br> > bot token with "Environtment=GOPHER_SLACK_TOKEN=xxx" in the systemd<br> > unit file. I had hoped to keep this info to the robot user by<br> > marking the unit file world-inaccessible. I was dismayed to see the<br> > log warning about values being accessible via the API, though super<br> > glad that my unprivileged user couldn't fetch it with a<br></div> > simple |systemctl cat gopherbot|. I know very little about DBUS or<div class="m_1421339063491951893m_-2215618378718853811quoted-text"><br> > any APIs for systemd, so wanted to ask - is there some means by<br> > which a non-privileged user can access the values provided with<br> > "Environment=..." lines? Can I disable this by disabling dbus-daemon<br> > on server systems?<br></div><div class="m_1421339063491951893m_-2215618378718853811elided-text"> _______________________________________________<br> systemd-devel mailing list<br> <a href="mailto:systemd-devel@lists.freedesktop.org" rel="noreferrer" target="_blank">systemd-devel@lists.freedesktop.org</a><br> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br> </div></blockquote></div><br></div> _______________________________________________<br> systemd-devel mailing list<br> <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br> </blockquote></div>