Not recording two sessions

[jeannegreulich]

I am on CentOS 7.5 using gnome 3.28. I start tlog-rec-session -l and it records fine. If I start a second one for the same user it does not record. According to the documents it should connect to same tlog-rec-session running from the other. I have verfied the/proc//session_id is the same for both sessions.
I do not get the notification on the second tlog session either. I have tried this on tlog release v4 and the latest release v5.

tlog-rec-session --configuration
{
  "notice":"\nATTENTION! Your session is being recorded!\n\n",
  "latency":10,
  "payload":2048,
  "limit":{
    "rate":16384,
    "burst":32768,
    "action":"pass"
  },
  "file":{
  },
  "syslog":{
    "facility":"authpriv",
    "priority":"info"
  },
  "journal":{
    "priority":"info",
    "augment":true
  },
  "shell":"\/bin\/bash",
  "log":{
    "output":true,
    "input":false,
    "window":false
  },
  "writer":"journal",
  "configuration":true,
  "args":[
  ]
}

[spbnick]

Thank you for the report @jeannegreulich! I think the documents might be confusing. Because tlog-rec-session works in the opposite way: it actively avoids recording a session, if anoter tlog-rec-session is already recording it. That's because tlog-rec-session is assigned as the user's shell, which is started by all programs which need a shell and that would create too many recordings of the same session.

Could you tell what documentation did you read which led you to expect tlog-rec-session behaves otherwise?

[jeannegreulich]

I am re-reading it and maybe I misunderstood. The man page does say it will just start the shell. Perhaps I assumed it would record the other shell also. I will look further to see where I got that idea or if it is just in my head.

We are trying to log privileged sessions, so when a user "su"s to a user in the privileged group it starts a tlog-rec-session. You are saying I can only record one terminal at a time because gnome starts all these terminals in the same session id. So a user can get around logging by simply starting another terminal. Is there anyway to override that behavior and allow multiple recordings from the same session?

[trevor-vaughan]

@spbnick I think this comes back to what I was worried about in some previous discussions. As much as I'm willing to believe that tlog-rec-session is absolutely perfect, replacing the root user shell directly is a really, really, big deal and simply won't fly with many (if not most) organizations.

Starting tlog-rec-session from something in /etc/profile.d is pretty reasonable since a misconfiguration is generally recoverable.

The issue may be the nature of items like gnome-terminal. Have you tried tlog under multiple gnome-terminal sessions where you sudo to root?

[trevor-vaughan]

@spbnick I think that I've just reproduced this case using tmux. If you open up a single tmux session, split the screen, and then start logging your session in the two different windows only one is logged. Is there a way to force tlog to recognize this as a new session?

[spbnick]

@jeannegreulich, @trevor-vaughan, tlog should not be used for same-host recording privileged users who can simply disable the recording by changing the system configuration or use a debugger to disable the recording.

There's really no practical difference for safety between assigning tlog-rec-session as the root's shell directly, or starting it via a shell script in /etc/profile.d. If anything, the latter is less secure, and only serves to circumvent the organizational rule, which should be disputed instead, IMO.

If you want to record root, or another similarly-privileged user, with tlog, you need to use a jump-host setup where recording is done on a separate, secure, host. E.g. have tlog-rec-session specified as the shell for users on the jump host and have their shell profile execute ssh to the target host unconditionally, as well as disable access to the target host from anywhere but the jump host.

Regarding making multiple recordings for the same session (e.g. under screen/tmux, or a graphical session), this a really tricky case, and doesn't have a reliable solution using a user-mode recorder, such as tlog, and should be done from the kernel instead.

One problem is once the user has logged in they can run whatever they want in their terminals. In a graphical session they can configure their terminals to start whatever they want instead of their shell. E.g. see "Edit->Preferences->Command" in gnome-terminal. Let alone doing anything they want using just the GUI tools. Similarly, under screen you can just run screen /bin/bash and have a window with another shell, without recording. Therefore it only makes sense to do the recording at the point the user has entered the system, e.g. at login. Tlog cannot record graphical sessions so you're left with text sessions only. If you need to record a graphical session, you'll need to use another tool.

We can log the name of the terminal tlog is connected to and avoid recording of the same audit session ID and the same terminal name using lock files (same as is done for just audit sessions now), and this way allow multiple recordings per sessions, but given that one can easily circumvent running tlog-rec-session as described above, it doesn't seem worth the effort and would also create duplicate recordings when running e.g. under screen or tmux.

[trevor-vaughan]

@spbnick I understand the issue with monitoring users that can disable the monitoring. However, if that is the last recorded event that leaves the system, then that, in and of itself, should be a critical security offense.

Unfortunately, there is no way that tlog will be able to dictate the layout of any given infrastructure. The multi-window recordings seemed to work properly with sudosh2 so you may want to look there for inspiration.

I would be happy with the lock file solution and it should be up to the end user as to whether or not the added overhead of multiple recordings per session is worth the added logging capabilities. In a similar vein, you can audit literally everything using auditd but it would, indeed, probably not be a great idea. That said, some environments may require it and so the capability exists.

Relates to #209

[spbnick]

Thank you, @trevor-vaughan. Tlog shouldn't dictate the infrastructure layout, of course, but it can't support all the possible layouts either. Still, perhaps we should support the session/terminal lock to allow multiple recordings in a session, for use at user's discretion.

[trevor-vaughan]

@spbnick I think that would be ideal. If you hack together the code, I'd be happy to PR the documentation caveats as to what does, and does not, work and why it's generally not ideal.

[trevor-vaughan]

@spbnick I think that something may have been unclear in the explanation.

I get that you would get double logging if you do the following as the same user:

• Login as user
• Start tlog
• Run tmux
• Start tlog

The issue is the following scenario:

• Login as user
• Start tmux
• Split pane
• Left pane -> su to other user and start tlog
• Right pane -> su to other user and start tlog

The right pane will not be logged even though they are technically two different sessions.

[trevor-vaughan]

@spbnick Just checking in to see if you managed to reproduce the issue based on my last comment.

[spbnick]

Sorry, @trevor-vaughan, I no longer work on the project officially, so this is on @justin-stephenson.

[justin-stephenson]

@trevor-vaughan if I understand correctly, the split pane example scenario you described never creates a new unique audit session id therefore tlog exhibits the same behavior as attempting to start a new recording when a session recording already exists.

I will need to consider if tlog can be expanded to handle multiple recordings, because the tlog session -> audit session ID correlation is an integral design component of tlog.

[trevor-vaughan]

Hmm...that's quite possible but it certainly makes circumventing the whole thing pretty trivial. Would appending an internal add-on identifier work?

<audit_id>:<session_num> or the like?

[trevor-vaughan]

@justin-stephenson Any ideas here since you seem to be active? This is still possible with your latest COPR build.

[justin-stephenson]

@trevor-vaughan reading through the thread, this looks like a request to change the tlog-rec-session locking logic from current behavior:

• If a session is already running with the same audit session ID, avoid recording the new session.

To new behavior:

• If a session is already running with the same audit session id AND same terminal name, avoid recording the new session.

However, tlog recording can still be circumvented with terminal multiplexers in other ways therefore this should not be considered as fixing a security hole.

This seems feasible, I just need to do more research to see if this change leads to excessive duplicate recordings, or any other unwanted side effects.

[trevor-vaughan]

Oh, I completely get that it isn't a perfect fix (nothing is) but it's at least not an immediate face plant using common technology.

[andrej-gomozov]

This issue is happening also with SSH connection multiplexing. This can be reproduced by putting below options into your SSH client config file ~/.ssh/config, then open several SSH sessions from same source and as a result only first SSH session will be recorded by tlog-rec-session and others are not. Is this planned to be fixed? Anything fundamental in tlog design that prevents the recording of several sessions under same connection and impossible to implement?

Host *
  ControlPath ~/.ssh/%h.%p
  ControlMaster auto
  ControlPersist 24h

[justin-stephenson]

This issue is happening also with SSH connection multiplexing. This can be reproduced by putting below options into your SSH client config file ~/.ssh/config, then open several SSH sessions from same source and as a result only first SSH session will be recorded by tlog-rec-session and others are not.

Right, the problem is similar to what is discussed in this issue. I haven't tested this myself to confirm but I suspect subsequent SSH multiplexing connections do not generate a new audit session id, this leads to the behavior of tlog only recording the first session.

Is this planned to be fixed? Anything fundamental in tlog design that prevents the recording of several sessions under same connection and impossible to implement?

If the terminal name changes between each multiplexed new connection/session, then tlog may work in this configuration if the changes I describe in my previous comment are implemented.

Note that the SSH ProxyJump configuration will not work with tlog for different reasons. https://github.com/Scribery/tlog/issues/303

[andrej-gomozov]

@justin-stephenson yes, terminal is different for each session. I think this issue is quite important to fix, otherwise need to disable this feature somehow in sshd_config, but with default config ssh multiplexing can be easily utilized to bypass tlog.

[trevor-vaughan]

I think asking people to disable that feature in sshd would go over like a lead balloon....

[andrej-gomozov]

@justin-stephenson have you tested that session multiplexing with SSH? as mentioned, it's enough to put these lines into ~/.ssh/config and open several login sessions, only first one will be recorded by tlog.

Host *
  ControlPath ~/.ssh/%h.%p
  ControlMaster auto
  ControlPersist 24h

[ajf8]

The SSH multiplex issue can be resolved by simply disabling the locking code. This seems to work well for us, we don't want or need the locking by session id, so multiple sessions are recorded with the same session ID but different recording ids.

I've added an option to tlog-rec-session.conf here to do it.

https://github.com/Scribery/tlog/pull/328/files