Bsrgvty

I have some admins that don't want their activity seen.

They cleverly run set +o history once they log in. Doing so means that commands they run don't get recorded in the history file.

Is there a way to set .bash_history attribute to not allow this?

TL;DR: No. There is no way to do this that cannot be worked around extremely easily. More generally, you cannot grant someone full control of a computer system and then succeed at preventing them from performing specific actions.

This answer is based on the following assumptions, which you appear to be indicating are the case. Note that although I've used a bit of legalistic-sounding wording here, what I'm talking about is technical and practical/social. This post is not about the law.

1. You are talking about a multi-user production system on which some users have been deliberately granted the ability to perform any action whatsoever, by running commands as root with sudo and/or Polkit. (Such an ability is what "administrator" or "admin" means in Ubuntu--and it is, in essence, what it means on any system.)


2. You are the actual and rightful owner of that system or systems. You are not obligated, contractually or otherwise, to refrain from imposing requirements on the way those users use their administrative powers. Really what I'm trying to capture here is that the problem is not you, it's them. If the problem is you, that's great, because it means you can address it directly by changing your own behavior. But I'm going to assume that this is unfortunately not the case.


3. You believe these users are using their administrative powers to perform actions that are not justified by their roles as administrators and that constitute a betrayal of your trust. Some or all of them have undertaken deliberate efforts to prevent you from knowing how they are using those powers.

If those assumptions hold, then the best possible situation is one in which you have not yet demanded that your administrators refrain from attempting to conceal their actions. In that scenario, it is imaginably possible that you could simply make this demand clear to them and that they would abide by it. If it turns out that this is feasible, then I recommend you ask your administrators why they have been concealing their actions. Perhaps they also use the system for non-administrative tasks that involve sensitive information about themselves or others that must be protected. If so, then either this is an inappropriate use of the system and you can tell them to stop doing it, or it's an appropriate use in which case that is something that can be solved with technical measures--specifically, they can be given separate non-admin accounts for such use.

Short of that, the only way to prevent them from continuing to conceal what actions they are performing with their elevated powers is to remove their elevated powers (as user535733 mentioned).

As you've described the situation, the system grants them the same technical abilities it grants you. Anything you could do to prevent bash from recording history is something they could easily undo. They could also make it hard for you to know they had undone it. As one example among many, they could let it record history but edit the history file, either automatically or manually. Also, they can use the history builtin to edit or delete history lines before they are written to a file.

Also, even when history is recorded, Bash is deliberately designed to permit the user to prevent any individual command from being recorded in the history. This is achieved by beginning the command with one or more spaces, and it is often useful for situations where one cannot avoid running a command whose arguments contain sensitive data, as well as to prevent commands that could easily cause harm under other circumstances (e.g., some rm -r commands) from being accidentally retrieved and run from the history.

Furthermore, users don't have to conceal or avoid writing to their Bash history to make it difficult or impossible to discover what actions they are performing. They don't need to use a shell, and if they do use a shell, it doesn't have to be bash, and if it is bash, it can be a separate instance of bash that is run with options like --norc to prevent it from reading configuration files. They can run a program like vim or emacs and use it to do just about whatever they want, including but not limited to starting a new shell, an interpreter like python3, or other powerful program like mc.

Looking at a user's ~/.history file is not a good way of auditing their administrative actions, since all of the techniques described above that can be used to circumvent this also have fairly frequent other uses. For example, many users perform non-trivial tasks outside of a shell. Shell history, when it is recorded at all, is recorded for the convenience of the user. It is not reliably useful for any other purpose.

There are logs you can look in to see what administrative actions have been performed, such as /var/log/auth.log. (See also man journalctl.) But any administrator can delete or modify logs. If you have administrators doing bad things, and telling them to stop doesn't work, you have no technical measure to prevent or even significantly mitigate this short of removing them as administrators. (If they are truly malicious, they may even have set up backdoors in the system to get back in even after their administrative powers are removed. Hopefully your situation is not this extreme.)

Finally, although this is not specifically about bash, shell history, or logging, I think it's worthwhile to take a moment to really think about what kinds of actions an administrator can perform. As I wrote in this answer to What stops someone from setting root password?:

You are a member of the sudo group. You can delete all the files on the system. You can write raw data to the hard disk, overwriting what is there irrecoverably. You can access other users' files, even if they have set restrictive permissions. You can install new firmware to your physical devices. You can dump users' passwords from the shadow database and attempt to crack them, or just reset them. You can install malware that infringes users' privacy or destroys data, including keyloggers and ransomware. You can do some really weird stuff with your network interfaces. You can make the system misinform users about the security of their communications. You can cover your tracks. You can hand all these powers, and others I haven't listed, over to people who will use them for evil. When it comes to misusing sudo or Polkit, those are the kinds of things you should be concerned about.

See also Panther's answer to that question.