11 ms·

$ cat /proc/3791/mem cat: /proc/3791/mem: Permission denied $ ps aux | grep 3791 ntp 3638 0.0 0.0 24440 1480 ? Ss ntp 3638 0.0

by orib 18y ago

$ cat /proc/3791/mem cat: /proc/3791/mem: Permission denied $ ps aux | grep 3791 ntp 3638 0.0 0.0 24440 1480 ? Ss ntp 3638 0.0 0.0 24440 1480 ? Ss Jul30 0:01 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 110:116 -g Sorry, what? The memory isn't available to all users. The process name and arguments are.

ajross 18y ago
Is your security analysis assuming that the attacker is running under a different uid than the web server? Why on earth would you do that? I'm not sure where all these security discussions are going. My point was simply that taking the passwords out of the command line of gpg was woefully insufficient to secure them (note, again, that they're going to be stored in a database whose password is stored locally in a file), so using "security" as a reason to avoid perl's elaborate and very robust IPC facilities was a poorly grounded argument. Nitpicking about whether one (!) of my examples matches the original author's security assumptions is very much missing the point. To get back to perl: note that you can feed the password to GPG via stdin if you want with just one extra byte to the open string, and a call to autoflush() and print().
- bretthoerner 18y ago
  Is your security analysis assuming that the attacker is running under a different uid than the web server? Well, that's just what my example question above said. Why on earth would you do that? To avoid them reading the memory? It's pretty common for shared hosting to have each user running on their own local port and a reverse proxy listening on 80, just so that each user gets the benefit of the basic UNIX security model (we assume trust in the admin, of course). I guess I don't understand the whole password in a file thing, either. If those have proper permissions then the only person who have to trust other than yourself is root. Seems better than nothing to me.
- orib 18y ago
  Plenty of people use shared hosting. The unix security model isn't amazing, but it does a reasonable job of protecting you from users other than root -- putting cleartext passwords in command line arguments is one way of throwing that away. Then again, as you seem to be saying, manipulating cleartext passwords are usually a bad idea in the first place
- SwellJoe 18y ago
  Is your security analysis assuming that the attacker is running under a different uid than the web server? Why on earth would you do that? In a secure shared hosting environment applications do not run as the web server UID. They run as the owner of the virtual host. Apache does this with mod_suexec. Are you doing it differently? Why on earth would you do that?
mr_excellent 18y ago
Please put some line breaks in there -- your post fouls up the rendering of the whole page of comments (it makes the page too wide).

by orib 18y ago

ajross 18y ago

Is your security analysis assuming that the attacker is running under a different uid than the web server? Why on earth would you do that? I'm not sure where all these security discussions are going. My point was simply that taking the passwords out of the command line of gpg was woefully insufficient to secure them (note, again, that they're going to be stored in a database whose password is stored locally in a file), so using "security" as a reason to avoid perl's elaborate and very robust IPC facilities was a poorly grounded argument. Nitpicking about whether one (!) of my examples matches the original author's security assumptions is very much missing the point. To get back to perl: note that you can feed the password to GPG via stdin if you want with just one extra byte to the open string, and a call to autoflush() and print().

bretthoerner 18y ago
Is your security analysis assuming that the attacker is running under a different uid than the web server? Well, that's just what my example question above said. Why on earth would you do that? To avoid them reading the memory? It's pretty common for shared hosting to have each user running on their own local port and a reverse proxy listening on 80, just so that each user gets the benefit of the basic UNIX security model (we assume trust in the admin, of course). I guess I don't understand the whole password in a file thing, either. If those have proper permissions then the only person who have to trust other than yourself is root. Seems better than nothing to me.
orib 18y ago
Plenty of people use shared hosting. The unix security model isn't amazing, but it does a reasonable job of protecting you from users other than root -- putting cleartext passwords in command line arguments is one way of throwing that away. Then again, as you seem to be saying, manipulating cleartext passwords are usually a bad idea in the first place
SwellJoe 18y ago
Is your security analysis assuming that the attacker is running under a different uid than the web server? Why on earth would you do that? In a secure shared hosting environment applications do not run as the web server UID. They run as the owner of the virtual host. Apache does this with mod_suexec. Are you doing it differently? Why on earth would you do that?

mr_excellent 18y ago

Please put some line breaks in there -- your post fouls up the rendering of the whole page of comments (it makes the page too wide).