"Michael D. Adams" <mdmko...@gmail.com> writes: > On Thu, Oct 1, 2009 at 4:24 PM, Ger Hobbelt <g...@hobbelt.com> wrote: >> A note about your mention of 'security leak': when you are worried >> about adversaries who can run 'ps -l' on your machine, then you're >> essentially worried about adversaries with plenty of access to your >> machine, so they'll quite probably be able to 'cat' that keyfile > > Any normal user on a Linux machine would be able to see 'ps -f'. But > to 'cat' the keyfile or coredump the app, they would need to either > (1) have root access, or (2) have cracked the machine. In my mind > there is a large leap between 'normal users could get this secret > info' and 'user's with root access could get this secret info'.
To get a bit off-topic from this: This is a problem that people run into on a pretty regular basis, that ps reveals information they don't really want it to reveal. I have run into it myself with the environment, where an environment variable was the only straightforward channel I could find to communicate a secret between a Web server and a CGI program. Apart from tradition, is there an inherent reason that ps has to reveal things like command-line arguments and the environment to all users? Modern Linux systems get it from proc files, which by tradition have permissions which allow access to this information, but whose permissions could be more restrictive with a small kernel change. IIRC, other Unix systems use a setuid ps that reads the process's memory directly, so changing ps to not reveal the information would be sufficient. It seems that some flexibility is possible; I notice the Linux system I'm on right now doesn't allow access to the environment via ps, while the Solaris machines I used several years back did. ----Scott. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
