[systemd-devel] Environment-variable security?

[aleivag]

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 <
parsley at 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 <aleivag at 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.reindl at 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 <parsley at linuxjedi.org
>> > <mailto:parsley at 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>>
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20181112/36674326/attachment.html>