If you use EnvironmentFile the only thing a user could do is systemctl show, and that will tell them that what environment file was used , but not it's content...
As long as you unset the env, you should be fine (but I'm not a expert on this) El lun., 12 de noviembre de 2018 7:18 p. m., David Parsley < pars...@linuxjedi.org> escribió: > 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. > > 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. > > 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. > > Regards, > -David > > On Mon, Nov 12, 2018 at 4:23 PM aleivag <alei...@gmail.com> wrote: > >> hi Reindl: 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). >> >> El 12 nov. 2018 5:54 p. m., "Reindl Harald" <h.rei...@thelounge.net> >> escribió: >> >> >> >> Am 12.11.18 um 21:41 schrieb aleivag: >> >> > You can define those secrets on /etc/robotsecret.txt, and then on your >> > unit you do `EnvironmentFile=/etc/robotsecret.txt` >> > >> > then you protect /etc/robotsecret.txt as you would normally do >> >> and how does that protect anything? >> >> on a webserver running php it's just a one-liner to get $_ENV which is >> why sensitive data don't belong there and should never exposed that way >> like passwords in teh commandline are plain wrong >> >> >> > On Mon, Nov 12, 2018 at 4:49 PM David Parsley <pars...@linuxjedi.org >> > <mailto:pars...@linuxjedi.org>> wrote: >> > >> > It's a fairly common practice to configure services and provide >> > secrets with environment variables. For instance, both Hubot (made >> > by Github) and Gopherbot (made by me) can get their Slack token from >> > an environment variable. In my case, >> > github.com/lnxjedi/ansible-role-gopherbot >> > <http://github.com/lnxjedi/ansible-role-gopherbot> stores the Slack >> >> > bot token with "Environtment=GOPHER_SLACK_TOKEN=xxx" in the systemd >> > unit file. I had hoped to keep this info to the robot user by >> > marking the unit file world-inaccessible. I was dismayed to see the >> > log warning about values being accessible via the API, though super >> > glad that my unprivileged user couldn't fetch it with a >> > simple |systemctl cat gopherbot|. I know very little about DBUS or >> >> > any APIs for systemd, so wanted to ask - is there some means by >> > which a non-privileged user can access the values provided with >> > "Environment=..." lines? Can I disable this by disabling dbus-daemon >> > on server systems? >> _______________________________________________ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel >> >> >> _______________________________________________ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel >> >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
