Hardening

[ElieDeloumeau]

Hello,

Here is an issue to talk about users hardening.

I think that we should add this in profile :

shopt -s histappend
readonly PROMPT_COMMAND=”history -a”
readonly HISTFILESIZE
readonly HISTSIZE
readonly HISTCMD
readonly HISTCONTROL
readonly HISTIGNORE

Do you have other suggestions?

[pdecat]

Isn't the chattr +a applied to the users' .bash_history files going to cause issues when HISTFILESIZE or HISTSIZE is reached?

[ElieDeloumeau]

Sure, we need to increase these variables

[pdecat]

Just increasing these variables will only postpone issues.
Maybe a system service triggered by cron or inotify could truncate users' history files in the background to avoid hitting the limits.

[ElieDeloumeau]

OK so, that is really overkill 🤣 Should we go this far?

[xp-1000]

in my opinion, hardening on user is overkill.

what is crucial to handle is the privilege escalation case (e.g. sudo access). for the rest, if you don't trust the user so don't create it :)

There are several solutions aiming to restrict or jail users like rbash and lshell and all fail because generic purpose solution cannot work with security, only very specific tools like smrsh or rssh can work.

Here you can protect bash history file as much as you want, while your user has a true shell so he ca simply define HISTCONTROL=ignoreboth and prefix his command with a space to prevent to store it in the history which become "corrupted" without the need to modify it a posteriori.

so, in short, I would not invest too much time in this because it is doomed to fail. Especially when direct access to resources should be avoided as much as possible (pet vs cattle). It seems better to not give access to an instance but instead provide rich tooling to fully delete this need (log access from kibana, real time metrics, ci/cd ..)