On Fr, 30.11.18 19:57, Marek Howard (marek...@gmail.com) wrote:
> > Well, you don't know what libraries and code you use do in the
> > background. You know, what you you are doing is simply not how you do
> > security. When you do security you restrict access as much as you can,
> > you limit
Lennart Poettering píše v Pá 30. 11. 2018 v 18:16 +0100:
> On Fr, 30.11.18 17:04, Marek Howard (marek...@gmail.com) wrote:
> > I understand, but that's by design and there's nothing wrong with that.
> > It's even useful for the case where you want wrap a thing with a
> > script.
> >
> > I still
On Fr, 30.11.18 17:04, Marek Howard (marek...@gmail.com) wrote:
> Lennart Poettering píše v Pá 30. 11. 2018 v 14:53 +0100:
> > On Fr, 30.11.18 14:25, Marek Howard (marek...@gmail.com) wrote:
> >
> > > - Lennart keeps repeating that passing secrets via environment variable
> > > is insecure
Lennart Poettering píše v Pá 30. 11. 2018 v 14:53 +0100:
> On Fr, 30.11.18 14:25, Marek Howard (marek...@gmail.com) wrote:
>
> > - Lennart keeps repeating that passing secrets via environment variable
> > is insecure because they are passed down the process tree. They are, if
> > you choose so in
On Fr, 30.11.18 14:25, Marek Howard (marek...@gmail.com) wrote:
> - Lennart keeps repeating that passing secrets via environment variable
> is insecure because they are passed down the process tree. They are, if
> you choose so in execve(), they are also readable by other processes
> running
Marek Howard píše v Pá 30. 11. 2018 v 14:25 +0100:
> Give me one solid reason why it's insecure to pass passwords via
> environment variables please. So far it seems that systemd just broke
> this concept for no valid reason and now you try to defend with
> completely unrelated reasons. There were
David Parsley píše v St 14. 11. 2018 v 08:45 -0500:
>
> On Wed, Nov 14, 2018 at 3:43 AM Lennart Poettering
> wrote:
> > I mean, seriously, people do lots of stuff. It doesn't mean that all
> > what people do is actually a good idea or just safe.
>
> Certainly agreed on this point. It is my
Yes, sadly https://12factor.net/ has a lot of currency.
The first time I read that config section I thought
1. it doesn't answer the question; how/where/when do those env vars get
defined?
2. it's not secure
Matt
On Tue, 13 Nov 2018 at 21:20, Tomasz Torcz wrote:
> On Wed, Nov 14, 2018 at
On Wed, Nov 14, 2018 at 3:43 AM Lennart Poettering
wrote:
> I mean, seriously, people do lots of stuff. It doesn't mean that all
> what people do is actually a good idea or just safe.
>
Certainly agreed on this point. It is my belief, however, that system
software, where possible, should
On Mi, 14.11.18 02:17, Marek Howard (marek...@gmail.com) wrote:
> > It is not *that* common to pass secrets via environment variable but
> > it's nothing unusual, and many programs offer this interface. OpenVPN
> > comes to bind. Where such interface is offered, propagating down the
> > process
On Tue, 13 Nov 2018, David Parsley wrote:
> 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//environ.
I'm a bit hesitent to enter this
FWIW Kubernetes also supports mounting files containing secrets, which I've
personally found to be easier to work with than environment variables.
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
On Tue, Nov 13, 2018, 11:20 PM Tomasz
On Wed, Nov 14, 2018 at 02:17:02AM +0100, Marek Howard wrote:
> Marek Howard píše v St 14. 11. 2018 v 01:35 +0100:
> > Lennart Poettering píše v Út 13. 11. 2018 v 15:17 +0100:
> > > On Di, 13.11.18 07:49, David Parsley (pars...@linuxjedi.org) wrote:
> > > Well, you are of course welcome to ignore
Am 14.11.18 um 02:17 schrieb Marek Howard:
>> It's quite handy way to pass secrets and as I said above, there's
>> really no risk if it's done in cases where it makes sense. Of course
>> systemd leaking it to everyone makes it not usable with systemd, but
>> that's not really a problem with
Marek Howard píše v St 14. 11. 2018 v 01:35 +0100:
> Lennart Poettering píše v Út 13. 11. 2018 v 15:17 +0100:
> > On Di, 13.11.18 07:49, David Parsley (pars...@linuxjedi.org) wrote:
> > Well, you are of course welcome to ignore whatever I say, but again,
> > environment blocks are leaky, they
Lennart Poettering píše v Út 13. 11. 2018 v 15:17 +0100:
> On Di, 13.11.18 07:49, David Parsley (pars...@linuxjedi.org) wrote:
>
> > I disagree; privacy of environment variables to individual users on the
> > system is as fundamental as Unix file permissions. If a privileged process
> > (systemd)
On Di, 13.11.18 12:55, Kenneth Porter (sh...@sewingwitch.com) wrote:
> The Unit file documentation should also discourage putting secrets in those
> files.
True. Here's the PR:
https://github.com/systemd/systemd/pull/10764
Lennart
--
Lennart Poettering, Red Hat
--On Tuesday, November 13, 2018 6:59 PM +0100 Lennart Poettering
wrote:
Maybe following "random articles" blindly is not really the best
approach to computer security...
OTOH, most of us learned from reading the writings of others in the
industry. So perhaps the wisdom of this thread
El 13-11-2018 a las 9:49, David Parsley escribió:
I disagree; privacy of environment variables to individual users on the
system is as fundamental as Unix file permissions.
Please find us ONE reference to a relevant, current *nix standard that
says environment variables are either secret,
On Di, 13.11.18 07:49, David Parsley (pars...@linuxjedi.org) wrote:
> I disagree; privacy of environment variables to individual users on the
> system is as fundamental as Unix file permissions. If a privileged process
> (systemd) is configured to start a service and provide environment
>
I disagree; privacy of environment variables to individual users on the
system is as fundamental as Unix file permissions. If a privileged process
(systemd) is configured to start a service and provide environment
variables to an unprivileged service account, it is a reasonable
expectation that
On Mo, 12.11.18 19:53, aleivag (alei...@gmail.com) wrote:
> 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
On Mo, 12.11.18 17:41, aleivag (alei...@gmail.com) wrote:
> 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
Don't do this. This is only partially
On Mo, 12.11.18 14:49, David Parsley (pars...@linuxjedi.org) wrote:
> It's a fairly common practice to configure services and provide secrets
> with environment variables.
Passing secrets through env vars is marginally better than passing
them in via cmdline params, but still bad, bad, bad
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
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//environ. I'm fleshing out a
solution where the process consumes the environment then scrubs it from
proc
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 stores the
Slack
27 matches
Mail list logo
