-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 1/23/18 9:04 AM, Mark H. Wood wrote: > Well, there are several layers of problems here, with different > ways of addressing them. > > Command lines are available using 'ps', so any secrets written on > the command line are visible to anyone able to get a session on > that host, for the duration of the command. There's no way around > this that I know of. > > Process environment variables may also be visible to all and > sundry, so moving secrets from the command line to the environment > just makes slightly more work for the snooper. Removing them from > the shell's environment after use may not help, because typically > the environment is cloned when a process is forked, so the service > process will have copies that aren't removed. I would argue that environment variables are more secure than system properties (when passed on the command-line) because accessing a process's environment variables usually requires some appropriate level of access, whereas 'ps' is open to everyone, of course. But of course there are even better solutions... > The people who wrote the Servlet spec. seem to me to have been > thinking that the context for an instance of an app. would be > generated by an installer program or by the container's management > tools. You could write a simple script to generate a context > declaration which is customized for a specific instance. Unlike > the command line or the process environment, files (such as a > free-standing context declaration) can be protected by the > filesystem. This is your best noninteractive bet. +1 > As mentioned by another, the way to limit availability of > machine-readable secrets to the greatest extent is to require an > operator to type them in at startup. However, you'll need to > consider the consequences of this if your container is > automatically started at system startup -- you may need a way to > let an individual context's startup wait for an operator to appear > without hanging the whole system startup procedure. (Automatic > startup is another common thing that the spec. authors seem to have > believed to be Somebody Else's Problem.) I have a few machines with encrypted filesystems on them and, because I understand that having the fs password in a startup script is tantamount to not having an encrypted filesystem at all, I have to enter the password for the crypto fs every time the machine is restarted. This happens maybe once per quarter (3 mos... more often when kernel patches are coming out several times per day like recently) and it's a giant pain in my neck. Unless it's absolutely required, don't put a human process in where an automated process will d o. > For completeness: in your own code, you'll also wish to ensure > that you obliterate (not just discard) secrets as soon as you have > no further need for them. That means that, within the JVM, they > should only ever exist in mutable objects (not String, for > example). I disagree. There is almost no way to scrub memory in a JVM process. Hell, it's almost impossible to scrub memory even in a native process due to the way that the OS virtualizes memory regions. The OS can write a page to disk without you even knowing about it, and not your secret is on the disk. Yes, there are ways to tell the OS not to swap that memory, but at some point you end up writing more scrubbing code than anything else. Take the JVM example. Let's say that you have a secret that is only required for a short amount of time. You read it in from somewhere and put it into a char[] object. That char[] object is mutable and sure, you can write 0x00 to all of the char values before you discard the object and allow it to be collected by the GC. But before you have the chance to scrub it, the memory manager can relocate the char[] object to another place within the current (or even a different) heap region. Without native code, there is no way to prevent that from happening. The GC can even run during your scrubbing-operation and you end up with a copy of a half-scrubbed secret sitting around in an unpredictable memory location. Let's say you decide it's super-important to scrub that memory and you understand that you have to pin the object in memory to scrub it properly. So you write a native method to pin/scrub/unpin the object. Well, what was the history of that object *before* you tried to pin it? Okay, now we have to go 100% native and pin our char[] object, read the data from wherever, use it for authentication/signing/whatever, then scrub and unpin the object. Oh, and don't forget to tell the OS not to swap-out that page of memory in the meantime. Bullet-proof, right? Sorry, no. In the process of using that secret to authentication/sign/whatever, you may find that the authentication/signing/whatevering library makes a copy of the secret. Say... for easy-access. Is that library scrubbing the memory? Not sure. Let's say that library either doesn't make any copies or does a good job scrubbing their copy... What about the memory buffer used by the OS to read the secret from wherever it came from (file, network, keyboard)? Is that being scrubbed? Can you prevent that from being swapped-out? It's turtles all the way down with memory-scrubbing, too. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpnYn0dHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhIWg//bG/FNwnfGx5GZglp rtli15wuWBLpO6D/4slGOulFGyybpAuJevjizc5b8lRYAbMQ4xWeyPw3o6sOEUGQ fM5yJqhwHamPKzQK7dv3NcA3mgjdJjmEHppRlotZllOrczhoIQHQfppayK5koNgt N+9DVfBUaIB/seF3AXKplIv6uKaGBl0AG1ARUAjwTYV0q/CBtElaVhqrS9ScLJQP K9MXeOmA1PY1Oww12EmQytABQgT86ZqjkZogUCf5oF8v8NJcOAXjLvmtM0xn+bl1 G1SUhdlUCWCL7vHu3g0ly7W05zIyUG9FUfd4i2phgRnBiQl7B3aHS9kdHhE7SXEm dVy+QA0Fl3/K98xzD9ERABZGxAhlYUBj8K1jujBNhG/BGvLP/vVPePC3bSn6Nnlc XRYQujRgzt4RaKdMWC1gJQYeZRC82/KyjyuXZ6SFDAGpCX48OOZyxLZVVweJVKIt jjb6mzG8v9qQvLlXlQrRiiEALbvMyGV5u5uQjjP3WKjrtQaHNXAl10N/gQoeEQ4m mSX+aUH0TYsVj2jnBrP8uPPEwcN/I2w9BqrYZsXgPJ1a+mtC7ktXoThzhySRBtuN QbPJqRrEQv91TspkE5cBYmlnntlK0gu1dxzVZSKUogR7meMU1aoqDvr6hDI1gpuN Zn2b6k5Ag0Q3TuEvn6CV/Rl0s3g= =WI8G -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
