Re: Environment-variable security?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 30.11.18 19:57, Marek Howard (marekhwd@xxxxxxxxx) 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 propagation. Env vars are the opposite of that.
> > 
> > But anyway, I think this discussion is pointless. I get the impression
> > that whatever I tell you you'll ignore it anyway, and keep asking
> > "why, why?".
> 
> I get the same impression of you. I've repeated several times that
> having libraries read environment variables is least sever concern if
> you really expect code you execute to be malicious.

Well, there's a lot more shades between "not malicious" and
"malicious". Come on, read a book about computer security. It will
tell you that everything should get as little access to stuff as
reasonably possible. Least privileges and things. UNIX isn't really
designed with that too much in mind, but we do intend to do things
that way today. The opposite of doing things like that is placing
secrets in env vars and giving anything you start or any of the libs,
helpers, child processes you start free access to those, because you
are lazy.

> If using dedicated configuration file with secrets is supposed to
> remedy it, then please explain to me how please. Because I've the
> impression that if a malicious library can read environment variables,
> it can pretty much read that configuration file as well.

it's very easy: getenv() makes no access check. open() does. Files
have access modes, i.e. those rwxrwxrwx things, and
selinux/smack/apparmor on top. Environment variables do not. Whenever
you open a file for reading the kernel hence checks for you whether
you actually are allowed to have access. For environment blocks that
doesn't happen, everybody gets the full thing dropped on its feet, by
default, for free, without *any* restrictions.

Again, let me compare this for you in a pretty table:

               | propagation control | life-cycle control | access control
---------------+---------------------+--------------------+----------------
kernel keyring | YES YES YES YES YES | YES YES YES YES YE | YES YES YES YE
files          | NO NO NO NO NO NO N | NO NO NO NO NO NO  | YES YES YES YE
environment    | NO NO NO NO NO NO N | NO NO NO NO NO NO  | NO NO NO NO NO

of course, you could extend this table, and mention paging control
(i.e. whether passwords can be swapped out or not), and other
concepts, but let's keep things simple.

> And if you're that security conscious that you restrict system calls,
> what are the odds that you forget to clean the environment?

We do that in systemd. All services invoked by systemd start with a
clean environment, and don't inherit things from the invoking client
(which is very different from sysvinit btw, where the env block for
daemons was inherited from the user session that ran
"/etc/init.d/foobar start").

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel