2

If you look at STIG reference V-230349 you will see the full text, which I am about to summarize.

The initial statement, or rule title, is RHEL 8 must ensure session control is automatically started at shell initialization.

It calls for:

# /etc/profile.d/tmux.sh

if [ "$PS1" ]; then
  parent=$(ps -o ppid= -p $$)
  name=$(ps -o comm= -p $parent)
  case "$name" in (sshd|login) tmux ;; esac
fi

In one instance there is only this information provided:

Discussion: Tmux is a terminal multiplexer that enables a number of terminals to be created, accessed, and controlled from a single screen. Red Hat endorses tmux as the recommended session controlling package.

There is no mention of reason or rationale there in regards to security, but if you web search on the rule you can read more detail that seems to attempt to justify it. In addition subsequent related security rules also call for

#  /etc/tmux.conf

set -g lock-command vlock
bind X lock-session
set -g lock-after-time 900 

So the reality of /etc/profile.d/tmux.sh causes tmux to run whenever a user does an ssh connection into Linux and also any open terminal window within a VNC session, and then the tmux.conf settings causes a password prompt to happen within any tmux session after 15 minutes of not entering a character in that tmux'd window.

My question is for those who use tmux [as intended] and who are knowledgeable about it (because I never use tmux) is this a good or bad way to use tmux? Other than what seems to impose a password prompt happening within any terminal window in Linux, that is if a user doesn't just type exit to kill the tmux to begin with and continue normally without it. However my experience has been that 99% of users are not linux savy and don't even know about tmux. and a first complaint is they type exit and now their window doesn't close.

But for tmux knowledge folks does imposing such a tmux usage everywhere like this create the risk of numerous open and forgotten about tmux sessions? ... because Tmux is a terminal multiplexer that enables a number of terminals to be created, accessed, and controlled from a single screen; so as an admin I don't want users having something running they know nothing about or know how to manage.

1
  • If you're enforcing security guidelines of any sort using technical measures, it follows that your users should be provided training on what those technical measure are and how their work would be impacted. Having people use tmux is a net good IMO, even if they need a 10 min crash course on using it.
    – muru
    Dec 5, 2023 at 1:23

2 Answers 2

0

The online version of STIG calls for exec tmux; this avoids the workaround of exiting tmux as soon as it starts, and also avoids users needing to exit twice.

Users who don’t know about tmux shouldn’t end up leaving tmux sessions around: they won’t start further windows inside tmux, so when they exit their shell, tmux will exit too.

With such a setup, there are some users who end up penalised: users who do know about tmux and use it for long-lived sessions. Such users will have to manually switch to their previous session whenever the system-mandated tmux is started for them (Ctrlb(). Those users might end up leaving tmux sessions lying around as a result, although the overhead will be small.

Personally I wouldn’t mind such a setup, as long as it was changed to automatically rejoin any detached session belonging to the user logging in. (Something like tmux has-session && exec tmux attach-session || exec tmux.)

2
  • so there is a discrepancy in their wording, the online version shows a [ -n "$PS1" -a -z "$TMUX" ] && exec tmux however the formal instructions I was given only states as a fix text to do the /etc/profile.d/tmux.sh as I described. And as such, we just type exit whenever we open a window now.
    – ron
    Dec 4, 2023 at 20:07
  • I was going by the online instructions. You could always change the tmux.sh script you have to use exec tmux... Dec 4, 2023 at 20:08
0

I have used a similar configuration with screen for a number of years, but one that can reattach my login to a previous session. (This was a convenience rather than a security measure, so there is no password applied to the session.)

Generally it works really well. Occasionally a session is left marked "active" rather than "detached", usually when the network connection breaks and the session was idle (no input/output). This could be resolved by setting and idle timeout either from the shell or (if it's supported) in tmux itself.

I use a version of exec screen that fails cleanly into a direct shell. Here's what the client (program) calls:

ssh -q -tt "$host" \
        "screen -dr $session || screen -S $session -l $* || screen -l $* || screen || bash -i || sh -i"

where $host references the remote target host, and $session is a session name formatted with a known prefix I use for matching disconnected sessions.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .