Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix-cat2.yml RHEL-08-020041 for tmux shell #232

Open
eday87 opened this issue Oct 4, 2023 · 2 comments
Open

fix-cat2.yml RHEL-08-020041 for tmux shell #232

eday87 opened this issue Oct 4, 2023 · 2 comments
Assignees
Labels
question Further information is requested

Comments

@eday87
Copy link

eday87 commented Oct 4, 2023

Why was exec tmux removed in favor of tmux for launching tmux shell for RHEL-08-020041 in fix-cat2.yml?

Commit: 20035added. tmux update and ruleid

This allows a user to exit the tmux shell without logging out of the system, which defeats the purpose of the STIG control. The user is able to exit tmux and drop into the parent shell outside of the STIG controls regarding tmux such as vlock for RHEL-08-020041. The exec tmux forces tmux into a shell of its own, which logs the user out of the system when a user exits the tmux shell.

Environment: RHEL 8

@eday87 eday87 added the question Further information is requested label Oct 4, 2023
@uk-bolly uk-bolly self-assigned this Oct 9, 2023
@uk-bolly
Copy link
Member

uk-bolly commented Oct 9, 2023

hi @eday87

Thank you for your feedback its always good to get an issue raised with a great explanation. Looking through it appears to have been changed in the STIG documentation itself between Dec 2022 and the April 2023 release. The change was made to align with what STiG specifies.
Although i do agree with your feedback. I'm not sure why this was removed.

Many thanks

uk-bolly

@BJSmithIEEE
Copy link

BJSmithIEEE commented Apr 11, 2024

We worked with Red Hat to come up with this solution (Case 03115293)

This code recognizes when there is other session management. Although it still, always, launches tmux for a root/privileged/superuser shell, regardless of other session management.

Our ISSM/ISSO has accepted this as our Red Hat approved solution. **

#
#       /etc/profile.d/tmux.sh
#       SCC 5.x looks for tmux in /etc/profile.d/

### Updated to recognize other session control per Red Hat Case 03115293
[ $( /bin/id -u ) -eq 0 ] && [ x$TMUX = x ] && exec tmux
[[ $( /bin/tty ) =~ '/dev/tty' ]] && [ -n "$PS1" -a -z "$TMUX" ] && exec tmux

DoD CyberX DISA STIG Ansible Playbook entry in /etc/bashrc

This is the simple line DISA STIG Ansible Playbooks from DoD CyberX creates, and is grossly problematic.

[ -n "$PS1" -a -z "$TMUX" ] && exec tmux

SCC 5.x expected entry

We did a lot of testing, and apparently the NAVWAR SCC 5.x (at least 5.7 - 5.8) scanner expects an utterly broken stanza.

### SCC expected entry -- utterly broken ($parent environment won't be set in name= line)
if [ "$PS1" ]; then
        parent=$(ps -o ppid= -p $$)
        name=$(ps -o comm= -p $parent)
        case "$name" in
               sshd|login)
                       exec tmux
                       ;;
        esac
fi

This is actually the corrected code that works, but doesn't recognize some of the other session management, or even skips cases where there is no session management (opposite issue).

### SCC fixed entry (actually works)
if [ "$PS1" ]; then
       name=$(ps -o comm= -p `ps -o ppid= -p $$`)
       case "$name" in
              sshd|login)
                      exec tmux
                      ;;
       esac
fi

**P.S. I have also worked with Shawn Wells in the past at Red Hat itself, as Red Hat re-focused on compliance in RHEL6 (2010+), and no longer left it to individual 'Public Sector Services' employees like myself (2007-2014, not including HP and Red Hat strategic partners). I.e., if you want to understand our 'frustration,'' see this LinkedIn response, especially on the latest change to /bin/false in mdoprobe (which is just grossly unjustified and makes things worse).

uk-bolly added a commit that referenced this issue Oct 22, 2024
Signed-off-by: Mark Bolwell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants