Misleading information in README.md

[p-himik]

In the env section it states: "[...] it is very easy for anyone to read a process's environment (e.g. via ps -ef)".
First of all, it's supposed to be ps ef, or probably even ps e -f, and not ps -ef.
And please correct me if I'm wrong but I think with ps ef you can only see environment variables of the processes that have been started by your user (or all users if you're root). More info: https://security.stackexchange.com/questions/14000/environment-variable-accessibility-in-linux/14009#14009

[SevereOverfl0w]

I think the invocation is correct, you can find it listed in the manpage https://linux.die.net/man/1/ps

The "anyone" is a fair challenge though, and can be dropped without losing the intention of the sentence.

[p-himik]

I'm afraid the invocation is not correct:

• -e - Select all processes.
• e - Show the environment after the command.
  With -e and without just e you won't see the environment variables at all.

If anyone is dropped, the sentence does not help distinguishing between using #env and using #include for confidential information. In fact, that's because I think it's true - it is no difference whatsoever if you store something in an environment variable or in a local file. It all depends on the uid that started the process.

[SevereOverfl0w]

I understand the error now, thanks for elaborating that point for me.

I think the sentence that follows helps clarify why environment variables are inferior to an include:

Environment variables are also commonly dumped out in a debugging sessions.

[p-himik]

I don't think I've ever stumbled upon such behavior so it's hard for me to judge how common that really is, let alone compare it to, say, frequency of incorrect access rights assignments to files with confidential information.
But nevertheless, that's a fair point.

[SevereOverfl0w]

https://gist.github.com/telent/9742059 is a good reference on this too. They include your point about files:

2. It provides the "illusion of security": env vars are really no more
   secure than files, in that if you can read someone's files you can also
   (quite easily in Linux) read the environment variables of their running
   processes. This is not to say that files are better, just that they
   don't pretend to be.

[p-himik]

Oh yeah, I have read that whole thing, with comments. I don't quite agree with this particular point though.

1. Anything can provide any sort of illusion if a user doesn't know enough specifics about that something. If the user doesn't know how access rights work in Linux, there can be an illusion of security just as well.
2. "[...] if you can read someone's files you can also [...] read the environment variables of their running processes" - that's an incorrect statement. Apart from the owner, files also have a group - someone can be able to read something of which you're the owner, but at the same time not be able to read env vars of the processes you start.