Return to Answer

##Confidentiality

##Integrity

##Availability

Confidentiality

Integrity

Availability

This depends on what you mean by "secure". Security is composed of the CIA triad, which stands for Confidentiality, Integrity, and Availability. Violation one or more of those properties is a violation of security. However depending on your threat model, some of those may be more important than others. You might not care if an attacker can delete the logs, as long as they can't tamper with them. Or maybe you don't care about modification at all, and only want to prevent someone from finding sensitive information in them. Specifying that is important in answering this question.

Anyone running as your user or a more privileged user will be able to read your shell history. If the history contains anything sensitive, then they can read that as well. The practice you mention of not passing passwords to commands in arguments is a good practice. Not only does this prevent it from being logged in your shell history, but it also ensures that it will not be visible in the process tree.

While systemd does not keep shell history logs, this same general technique can, in theory, be applied to shell history as well. I am not aware of any extant implementations of this. Additionally, the sealing is done immediately, and an attacker may be able to modify the last 15 minutes (in the case of systemd) of logs. It is theoretically possible to have each line individually signed, but that would add more overhead.

This depends on what you mean by "secure". Security is composed of the CIA triad, which stands for Confidentiality, Integrity, and Availability. Violating one or more of those properties is a violation of security. However depending on your threat model, some of those may be more important than others. You might not care if an attacker can delete the logs, as long as they can't tamper with them. Or maybe you don't care about modification at all, and only want to prevent someone from finding sensitive information. Specifying that is important in answering this question.

Anyone running as your user or a more privileged user will be able to read your shell history. If the history contains anything sensitive, then they can read that as well. The practice you mention of not passing passwords to commands in arguments is a good practice. Not only does this prevent it from being logged in your shell history, but it also ensures it will not be visible in the process tree.

While systemd does not keep shell history logs, this same general technique can, in theory, be applied to shell history as well. I am not aware of any extant implementations of this. Additionally, the sealing is done immediately, and an attacker may be able to modify the last 15 minutes (in the case of systemd) of logs. It is theoretically possible to have each line individually signed, but that would add overhead.

Integrity is the assurance that the information you are seeing is what was originally saved, and that nothing has been tampered with. Note that integrity often provides only a limited subset of this guarantee, even if it is formally defined in ISO 27000 as the property of protecting the accuracy and completeness of information. Information with protected integrity may still be modified, have lines selectively redacted, etc., but it will be impossible for an attacker to convince you that the file is genuine. In other words, integrity is often closer to tamper-evidence than it is to tamper-resistance. Like availability, no shells I am aware of which are capable of preserving integrity.

This refers to the availability of information to be accessed on demand. Destruction of any of the data (selectively or haphazardly) or denying access to it would violate this property. I am not aware of any shell which goes to any lengths to ensure availability of the logs.

Integrity is the assurance that the information you are seeing is what was originally saved.

Integrity often provides only a limited subset of this guarantee, even if it is formally defined in ISO 27000 as the property of protecting the accuracy and completeness of information. Information with protected integrity may still be modified, have lines selectively redacted, etc., but it will be impossible for an attacker to convince you that the file is genuine. In other words, integrity is often closer to tamper-evidence than it is to tamper-resistance. No shells I am aware of which are capable of preserving integrity.

Availability is the ability of information to be accessed on demand. 

Destruction of any of the data (selectively or haphazardly) or denying access to it would violate this property. Like with integrity, I am not aware of any shell which goes to any lengths to ensure availability of the logs.