4 ms·

> and may have security implications too While it's certainly true that leaving around files with sensitive data is a security problem, you probably don't want

> and may have security implications too While it's certainly true that leaving around files with sensitive data is a security problem, you probably don't want to put sensitive data in /tmp to begin with.

vbezhenar 3y ago
Why not?
- armchairhacker 3y ago
  The program could get paused mid-execution. Moreover, I’m pretty sure a malicious process can put file watchers in /tmp and read all written contents.
  - ericbarrett 3y ago
    If your script calls umask 077 ...before creating temp files then they won't be world-readable. Still lots of pitfalls. (What user are you running as, and who else is running as that user? What's the mount point file system, and does it have POSIX permissions? Why are you persisting secrets to disk in the first place? Etc.)
- dredmorbius 3y ago
  It's possible to gather some information from a directory to which an attacker has write access, though I'd have to look up details. In general, this can usually be mitigated to some extent by creating a directory to which only the owner has access. There are a number of ... interesting ... other circumstances which you might want to consider: - /tmp is mounted as a ramdisk / memory-only filesystem. This is guaranteed not to persist over reboots, though there may be residual artefacts in memory even after a power-off. That last isn't a significant concern for many people, though it may turn up for others. - /tmp is a network share. This is uncommon, but NFS + sudo across shared systems means that a user on a remote system may be able to assume your credentials and access or modify your data. rootsquash means that root isn't available, but sudo means that any UID can be defined. - Various filesystem permissions or limitations may or may not apply to /tmp. I tend to prefer mounting /tmp as its own filesystem, with nodev and nosuid set. There might also be noexec, which can foul up a lot of temporary installation scripts. An alternative is for users to define their own preferred temporary directory. I usually include ~/tmp under $HOME.

vbezhenar 3y ago

Why not?

armchairhacker 3y ago
The program could get paused mid-execution. Moreover, I’m pretty sure a malicious process can put file watchers in /tmp and read all written contents.
- ericbarrett 3y ago
  If your script calls umask 077 ...before creating temp files then they won't be world-readable. Still lots of pitfalls. (What user are you running as, and who else is running as that user? What's the mount point file system, and does it have POSIX permissions? Why are you persisting secrets to disk in the first place? Etc.)
dredmorbius 3y ago
It's possible to gather some information from a directory to which an attacker has write access, though I'd have to look up details. In general, this can usually be mitigated to some extent by creating a directory to which only the owner has access. There are a number of ... interesting ... other circumstances which you might want to consider: - /tmp is mounted as a ramdisk / memory-only filesystem. This is guaranteed not to persist over reboots, though there may be residual artefacts in memory even after a power-off. That last isn't a significant concern for many people, though it may turn up for others. - /tmp is a network share. This is uncommon, but NFS + sudo across shared systems means that a user on a remote system may be able to assume your credentials and access or modify your data. rootsquash means that root isn't available, but sudo means that any UID can be defined. - Various filesystem permissions or limitations may or may not apply to /tmp. I tend to prefer mounting /tmp as its own filesystem, with nodev and nosuid set. There might also be noexec, which can foul up a lot of temporary installation scripts. An alternative is for users to define their own preferred temporary directory. I usually include ~/tmp under $HOME.