tlog
tlog copied to clipboard
Scribery
Tlog should provide a method for detecting if you are already in a tlog session
If you're not setting the user's shell natively to use tlog, then you need some way to detect if you're already in a tlog session to prevent potential infinite log looping.
This should either be a capability that is inbuilt to tlog or a file that can be found on the local filesystem indicating that you're already in a logged session.
My systems run with hidepid=2 which means that I cannot see processes owned by other users which makes this particularly difficult to do at this time since tlog runs as the tlog user.
Hmm, tlog-rec-session already won't start for the same session (same audit session ID). If you're talking about tlog-rec, then it's a general-purpose recording tool, and I don't think it should impose such limits.
@spbnick I was referring to tlog-rec-session. Are you sure on this? If you run tlog-rec-session as a normal user, then su to root, then re-run tlog-rec-session, then su to another user and run tlog-rec-session what happens?
Also, I need to wrap this in a profile.d script, so I need a way to tell if I'm already in a session and I've found that I'll end up in an infinite loop unless I can tell if I'm already in a session.
Well, I cannot be absolutely sure, but that's the usecase I targeted :)
It should work, although I wouldn't recommend starting tlog-rec-session from a shell startup script.
@spbnick Fair enough, but I don't have a choice. The shells allowed in /etc/shells are regulated and tlog-rec-session isn't one of them.
Hmm, and it shouldn't be in /etc/shells, otherwise users would be able to change it. Does it not work with it not being there?
The issue is that the validation code from the various checking tools will fail if a user's shell is not in /etc/shells and I can't fail security validation activities.
I see. I wonder why they have a problem with that. Having a shell not in /etc/shells seems to be the way of preventing changing it. At least according to chsh. Anyway, then that seems to be your only option.
I haven't verified it recently, but tlog-rec-session should prevent repeated start, even when started from the shell.
The problem is that I end up in an infinite loop because I can't skip trying to start tlog-rec-session if I can't tell that it's already running from my current shell. This is why I need something else (a file, a query command, whatever) to determine that I'm already running in tlog-rec-session.
Hmm, tlog-rec-session should simply spawn a shell if it detects that the session is already recorded. Perhaps, if you could share the shell snippet you're using, I'd be able to better understand what's going on. Maybe the session-locking code could help you figure it out as well: https://github.com/Scribery/tlog/blob/master/lib/tlog/session.c
Ah, that's what probably gets you. You get infinitely nested shells started by tlog-rec-session, which try to start tlog-rec-session, which starts the shell again. That has nothing with nested recording, though.
That's easy enough https://github.com/simp/pupmod-simp-tlog/pull/1/files#diff-26a3932fc1b359d77baf70bd17ef07c2
Honestly, if I could just run something like tlog-rec-session --already-logging and determine if I'm already being logged, that would work just fine.
Right. I'll need to think about it more, but I have to leave for a vacation. Will be back on Tuesday. Meanwhile, perhaps you could see if you could use the lock file tlog-rec-session creates.
As far as I can tell, I can only see that as the tlog user, not as my regular user.
Sorry, I no longer work on the project officially. This will be up to @justin-stephenson.
@trevor-vaughan if the spawned shell sets an environment variable like INSIDE_TLOG_SESSION, would that address what you are looking for? The idea being similar to INSIDE_EMACS variable used by bash
@justin-stephenson I'm not sure. I'm trying to find a way that can't be circumvented by users and setting an environment variable can. I guess I was assuming that there would be a read-only tracking system somewhere behind the suid actions of tlog.
@justin-stephenson Hmm...after thinking about that briefly, I guess all the user would do by un-setting that variable would be to cause looping. While a DoS risk, I think people would learn their lesson pretty fast so this is probably feasible.
Sorry for the multi-post, typing as I think :-|. So, the real issue is if someone sets that variable before running tlog-rec-session the first time.
It is not bulletproof, but could you use a conditional check of the 'tty' similar to the following? Note the tty does not change when tlog-rec-session spawns a normal shell instead of a recorded shell.
[testuser1@agalloch ~]$ tty
/dev/pts/2
[testuser1@agalloch ~]$ tlog-rec-session
ATTENTION! Your session is being recorded!
[testuser1@agalloch ~]$ tty
/dev/pts/4
[testuser1@agalloch ~]$ tlog-rec-session
[testuser1@agalloch ~]$ tty
/dev/pts/4
Hmm...that's not horrible but it would still be nice to have something built in given that the tty behavior could change at any time.