On ti, 19 joulu 2017, Ronald Wimmer via FreeIPA-users wrote:
On 2017-12-19 12:05, Jakub Hrozek via FreeIPA-users wrote:
>I think the best practice is to restrict the commands the users can run
>to a bare minimum. Letting them only through sudo (as opposed to sudo
>su) has the advantage that sudo sends all commands to the audit
>subsystem. Also, if someone walks away from a root terminal, it will
>still be a root terminal an hour later, sudo at least forces you to
Thanks a lot for your reply. It seems that I might not have been
specific enough. The users who have ALL sudo permissions are linux
admins who should have ALL rights because they usually know what they
are doing. My concern is some kind of traceability. I need to keep
track of what a user did when he switched to root. (or prohibit
switching to root)
What are my options here?
What I see regularly at various customer sites is a
setup where no wide-open root shell is granted but instead explicit
operations allowed. This is admittedly harder to maintain both from
security point of view and from the perspective of in-application shell
availability, but that's what many admins keep investing their time
Another approach is pushing more and more towards automated execution of
playbooks, using Ansible or other tools, with no direct ability to
execute anything but triggering execution through commits to a git repo
or a similar store. This moves auditing to a centralized versioning
system but makes harder to perform out-of-order operations.
I will have a look at tlog and session recording. Are you referring to
sssd-session-recording or to a different solution? I was also pointed
to rootsh (https://www.linux.com/news/rootsh-terminal-logger-keeps-watch-root-users
). What about that?
tlog is promising.
/ Alexander Bokovoy