5 ms·

The Hello World example shows echoing to stdout from the duress script. Seems like a bad idea. I don't want to get beaten or shot when some rm -rf fails with an

The Hello World example shows echoing to stdout from the duress script. Seems like a bad idea. I don't want to get beaten or shot when some rm -rf fails with an I/O error, alerting the attacker to what's going on. It seems like it would be more sensible for the module to suppress all output by design.

nuvious 5y ago
Hey, saw this as mentioned earlier and incorporated your feedback and one other commenter that pointed out a privilege escalation vulnerability. If you have a spare moment would appreciate your critique on the resolution to your concern and/or any other issues you see generally with the codebase. Just a request though, regardless thanks for your feedback! https://github.com/nuvious/pam-duress/pull/19 https://github.com/nuvious/pam-duress/pull/19
dheera 5y ago
Just do this in your script rm -rf /secret/files > /dev/null 2>&1 That pipes STDOUT to /dev/null and redirects STDERR to STDOUT.
- sleavey 5y ago
  Seems like this should be baked in to the module. There don't seem to be any circumstances where you would want stdout/stderr from duress.d scripts to appear.
  - wowaname 5y ago
    You have the freedom to do whatever you want with the script. It's trivial to `exec >/dev/null 2>/dev/null` first thing in a script if you want it to be silent.
    - sleavey 5y ago
      Do you want to first find that out when you're under duress? Sensible defaults matter.
      - wowaname 5y ago
        Are you seriously writing a script when the cops are at your door? No, you aren't. You always need to verify that your protective mechanisms work before actually relying on them.
        sleavey 5y ago
        As I alluded to in my original comment, you might not pick up on a transient error like an I/O error during testing. This is exactly the sort of thing a sensible default setting in the program should cover.
        wowaname 5y ago
        I'm sorry but error handling and testing requirements are true for any software or script a person writes. The application should not give a shit, and a simple execve() is the best way to go about it. It's the principle of least surprise, and people have had to keep in mind fork/exec semantics for decades.
- nuvious 5y ago
  I may actually incorporate that into the system() call in the module itself now that I think about it. The Hello World implementation was just a quick way for me to debug while I developed it and it's probably smarter to dump it to /dev/null by default.

nuvious 5y ago

Hey, saw this as mentioned earlier and incorporated your feedback and one other commenter that pointed out a privilege escalation vulnerability. If you have a spare moment would appreciate your critique on the resolution to your concern and/or any other issues you see generally with the codebase. Just a request though, regardless thanks for your feedback! https://github.com/nuvious/pam-duress/pull/19 https://github.com/nuvious/pam-duress/pull/19

dheera 5y ago

Just do this in your script rm -rf /secret/files > /dev/null 2>&1 That pipes STDOUT to /dev/null and redirects STDERR to STDOUT.

sleavey 5y ago
Seems like this should be baked in to the module. There don't seem to be any circumstances where you would want stdout/stderr from duress.d scripts to appear.
- wowaname 5y ago
  You have the freedom to do whatever you want with the script. It's trivial to `exec >/dev/null 2>/dev/null` first thing in a script if you want it to be silent.
  - sleavey 5y ago
    Do you want to first find that out when you're under duress? Sensible defaults matter.
    - wowaname 5y ago
      Are you seriously writing a script when the cops are at your door? No, you aren't. You always need to verify that your protective mechanisms work before actually relying on them.
      - sleavey 5y ago
        As I alluded to in my original comment, you might not pick up on a transient error like an I/O error during testing. This is exactly the sort of thing a sensible default setting in the program should cover.
        wowaname 5y ago
        I'm sorry but error handling and testing requirements are true for any software or script a person writes. The application should not give a shit, and a simple execve() is the best way to go about it. It's the principle of least surprise, and people have had to keep in mind fork/exec semantics for decades.
nuvious 5y ago
I may actually incorporate that into the system() call in the module itself now that I think about it. The Hello World implementation was just a quick way for me to debug while I developed it and it's probably smarter to dump it to /dev/null by default.