(#2122288) logind: add option to stop idle sessions after specified timeout #332
Conversation
This allows us to determine the TTY an ssh session is for, which is useful to to proper idle detection for ssh sessions. Fixes: #9622 (cherry picked from commit 3d0ef5c) Related: #2122288
This is useful later on, when we quickly want to find the session for a leader PID. (cherry picked from commit 238794b) Related: #2122288
(cherry picked from commit 4ee8176fe33bbcd0971c4583a0e7d1cc2a64ac06) Related: #2122288
We frequently want to set a timer relative to the current time. Let's add an explicit API for this. This not only saves us a few lines of code everywhere and simplifies things, but also allows us to do correct overflow checking. (cherry picked from commit d6a83dc) Related: #2122288
Thanks to Jan Pazdziora <jpazdziora@redhat.com> for providing a patch which implemeted a PoC of this feature. (cherry picked from commit 82325af3ae41bc7efb3d5cd8f56a4652fef498c2) Resolves: #2122288
…ure out atime timestamp (cherry picked from commit 6edf707fd59347024fa6be0342b108527825db1f) Related: #2122288
|
PREFACE: Yes, I will be opening a Red Hat Case on this matter (just like we did Case 03115293 for tmux), but I wanted to post it here. PER: I hope everyone realizes that, unlike SSH and those options, this option to system-logind will kill a TTY, and take out all its children, because systemd-logind could be wholly ignorant of those children that are running, and interactive and otherwise sending data back'n forth. If I'm mistake, please feel free to correct my ignorance. But in my testing so far, watching TTYs, this seems to be the case. I.e., I would strongly advise a review of how the SSH settings complement and, in many cases, should be maintained long-term, because systemd-logind may be unable to track many uses of a SSH login and the resulting TTY and communication. We're seeing this in RHEL8.7+ (2022 Nov), after DISA added it to the RHEL8 STIG (2023 Jun) at a Cat-2 (V-257258). E.g., see the following from the Ansible Lockdown RHEL8 STIG RANT: (I don't know who needs to hear this, and ... take it with a grain of salt, but ... I'm not the only one out there who feels this way about later RHEL8 Updates ... and I don't like to 'rant at' open source developers) If I was really in a demonizing mood, I would feel like few (mainly the ones who filed the RFE and/or pushed for the backport for RHEL8.7) bothered to check if the impact of this systemd-logind change mid-RHEL releases impact would be equivalent to the SSH configuration, or if it would have all sorts of unforeseen impacts that were not well evaluated, before end-users like us ran across this. Now I understand Red Hat has many compliance, customer and partner RFEs and other changes (DISA tends to be better than CIS in my experience). But since RHEL 8.4, and increasingly worsening 8.6-8.7+, we're seeing more and more of this ... perfectly working environments utterly having a wrench 'thrown in' by compliance, with these types of changes -- especially for lower severities (higher severities are more understandable). Which brings me to ... It would be one thing if Red Hat Global Support Services (GSS) had STIG'd systems for reproducing things. But they do not. We also have to fight the fact that KB articles aren't with FIPS enabled. So, we end-users are left to our own creativity, and I only caught this because I 'watched' every TTY and figured it out (it wasn't tmux or SSH, and even kills it before tmux locks). I'm just glad we're a heavy development shop, and not running production RHEL instances, just developing software for others to use in production. But we are still aiming for >95% compliance. Furthermore, and this isn't the OS vendor's fault, but ... it's also agonizing we're seeing 3-4 redundant and compounding findings for 'timeout' settings (TMOUT, Tmux, SSH, now systemd-logind0 made mid release -- see Red Hat Case 03115293 for an example of trying to mitigate the compounding issues). To try to make it equivalent to another OS, no one is putting locks screens or timeouts on Windows CMD.EXE, PowerShell, or other, interactive shells/windows in Windows, only the GDI lockscreen (one session manager). As I've postulated to many people both with and outside of Red Hat, "Help Me, Help You." We could improve a lot of the implementation of these details, especially in testing, although I can code as well, if needed. Especially for things mid-release. The typical RHEL Update Beta period also isn't always going to be well tailored for end-users like us either (more partners). But I'm not finding any avenues to date, and most Cases do not result in Red Hat interacting with Compliance entities and some Red Hat associates I've leveraged have been unable to get others engaged who are stakeholders, let alone decisionmakers. If you read all that, thank you. If you know some people who I could provide some code and solutions to for Compliance, I'm all ears. |
No description provided.