10 ms·

> If you want to remove a sensitive command from your history, you can simply edit your $HISTFILE history file and remove it. It’s already too late at this poi

by jpxw 6y ago

> If you want to remove a sensitive command from your history, you can simply edit your $HISTFILE history file and remove it. It’s already too late at this point. Anybody on your machine can read the commands you are running, for example with ps. You should instinctively avoid entering anything in plaintext into a terminal which you don’t want other people to see. Any command line tool worth its salt will provide alternative ways of passing secrets (using configuration files for example).

cassiet 6y ago
How exactly?
- jedimastert 6y ago
  I think what OP meant was closer to "if it could have been entered into the bash history than there's other ways it could be seen". Most CLI programs that need sensetive information as input should either do it interactively (a la sudo), as standard input, or configuration file. If worst comes to very worst, you can put the sensitive info in a text file and use backticks. For example: some-command --username=jedimastert --password=`cat secret.txt`
  - lmz 6y ago
    How would backticks help with hiding it from ps?
    - jedimastert 6y ago
      I thought that's how it would show up in ps. Apparently I was incorrect. :(
  - fooblat 6y ago
    > some-command --username=jedimastert --password=`cat secret.txt` This will not work in the way that you suggest. The output of ps will show the result of `cat secret.txt` and thus reveal the password.
    - jedimastert 6y ago
      Would it? Poo. That's my bad.
tyingq 6y ago
Not a real solution, but you can assign new values to argv/argc to hide things from ps. With Perl, for example, assign to $0. $0="what /bin/ps will see";
rrmm 6y ago
The worst is when you expect a password prompt so you type the password and hit enter, but you mistyped the original command and you end up typing your password in plaintext onto the command line. oops.
- McKayDavis 6y ago
  If you're using `bash`, A quick remedy for this is: unset HISTFILE exit This prevents `bash` from updating the `~/.bash_history` file on exit with the command you don't want memorialized. (assuming you don't also have some hook that updates your history file after every command)
fitzn 6y ago
I understand what you're saying but if anybody on your machine can read the commands, can't they also read your configuration files? Or are you saying a different user on the machine can run `ps` and see my processes but not necessarily my portion of the file system? My thought is if the file is not encrypted on the disk, then any desktop application can read it. So, while I agree that preventing a user from reading bash history is not worth it if they can read your processes, aren't configuration files (if unencrypted) just as insecure?
- mturmon 6y ago
  In a Unix system, files have 3 levels of permissions — for the user who owns the file, the group-of-users that owns the file, and any system user. So, a given config file can have permissions so that the file owner can read and write, but other users cannot. Like your ssh keys. But ‘ps’ can be run by anyone, and it can typically access the whole command line you used.
  - gvjddbnvdrbv 6y ago
    This is true but in a typical desktop usecase there is one user.
  - fitzn 6y ago
    Ah, right. This makes a lot of sense. Thank you!
jlgaddis 6y ago
> Anybody on your machine can read the commands you are running, for example with ps. This is why I always mount /proc with the "hidepid=2" option (as well as the "gid=<n>" option to ensure that doesn't apply to the members of a specific group, such as the "admins" of the box).
perlgeek 6y ago
This doesn't have to be true. You can mount /proc with hidepid to prevent users from seeing other users' processes: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/ch-proc https://access.redhat.com/documentation/en-us/red_hat_enterp...
capableweb 6y ago
Indeed! One thing that at least works on zsh is to prefix the command with a space, then the command doesn't go into the history file. So if you do `date`, it'll end up in the history file but if you do ` date` (one space prefixed), it won't. One `clear` later and it's like the command was never run.

by jpxw 6y ago

cassiet 6y ago

How exactly?

jedimastert 6y ago
I think what OP meant was closer to "if it could have been entered into the bash history than there's other ways it could be seen". Most CLI programs that need sensetive information as input should either do it interactively (a la sudo), as standard input, or configuration file. If worst comes to very worst, you can put the sensitive info in a text file and use backticks. For example: some-command --username=jedimastert --password=`cat secret.txt`
- lmz 6y ago
  How would backticks help with hiding it from ps?
  - jedimastert 6y ago
    I thought that's how it would show up in ps. Apparently I was incorrect. :(
- fooblat 6y ago
  > some-command --username=jedimastert --password=`cat secret.txt` This will not work in the way that you suggest. The output of ps will show the result of `cat secret.txt` and thus reveal the password.
  - jedimastert 6y ago
    Would it? Poo. That's my bad.

tyingq 6y ago

Not a real solution, but you can assign new values to argv/argc to hide things from ps. With Perl, for example, assign to $0. $0="what /bin/ps will see";

rrmm 6y ago

The worst is when you expect a password prompt so you type the password and hit enter, but you mistyped the original command and you end up typing your password in plaintext onto the command line. oops.

McKayDavis 6y ago
If you're using `bash`, A quick remedy for this is: unset HISTFILE exit This prevents `bash` from updating the `~/.bash_history` file on exit with the command you don't want memorialized. (assuming you don't also have some hook that updates your history file after every command)

fitzn 6y ago

I understand what you're saying but if anybody on your machine can read the commands, can't they also read your configuration files? Or are you saying a different user on the machine can run `ps` and see my processes but not necessarily my portion of the file system? My thought is if the file is not encrypted on the disk, then any desktop application can read it. So, while I agree that preventing a user from reading bash history is not worth it if they can read your processes, aren't configuration files (if unencrypted) just as insecure?

mturmon 6y ago
In a Unix system, files have 3 levels of permissions — for the user who owns the file, the group-of-users that owns the file, and any system user. So, a given config file can have permissions so that the file owner can read and write, but other users cannot. Like your ssh keys. But ‘ps’ can be run by anyone, and it can typically access the whole command line you used.
- gvjddbnvdrbv 6y ago
  This is true but in a typical desktop usecase there is one user.
- fitzn 6y ago
  Ah, right. This makes a lot of sense. Thank you!

jlgaddis 6y ago

> Anybody on your machine can read the commands you are running, for example with ps. This is why I always mount /proc with the "hidepid=2" option (as well as the "gid=<n>" option to ensure that doesn't apply to the members of a specific group, such as the "admins" of the box).

perlgeek 6y ago

This doesn't have to be true. You can mount /proc with hidepid to prevent users from seeing other users' processes: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/ch-proc https://access.redhat.com/documentation/en-us/red_hat_enterp...

capableweb 6y ago

Indeed! One thing that at least works on zsh is to prefix the command with a space, then the command doesn't go into the history file. So if you do `date`, it'll end up in the history file but if you do ` date` (one space prefixed), it won't. One `clear` later and it's like the command was never run.