LinuxQuestions.org - [SOLVED] New entries in /var/log/secure: what changed and is causing them?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - New entries in /var/log/secure: what changed and is causing them? (https://www.linuxquestions.org/questions/slackware-14/new-entries-in-var-log-secure-what-changed-and-is-causing-them-4175720330/)

New entries in /var/log/secure: what changed and is causing them?

I'm running slackware64 15.0 on all of my machines. Today I've started getting entries in /var/log/secure on my main machine that look like this:

Code:

su[19017]: Successful su for user by root

su[19017]: + ??? root:user

su[19017]: pam_unix(su:session): session opened for user user(uid=1000) by (uid=0)

su[19017]: gkr-pam: unable to locate daemon control file

su[19017]: gkr-pam: gnome-keyring-daemon started properly

su[19017]: pam_unix(su:session): session closed for user user

(I've replaced my username by "user" above.) These entries in each instance are all during the same second, so something is opening the su session and closing it quickly. It has happened now eight times, at 13:56:59, 16:21:07, 16:21:08, 17:26:21, 17:59:39, 19:01:14, 19:01:15, and 19:42:18.

There are no similar entries before this afternoon. I don't recall what I was doing around the times of the entries, but I had upgraded some SBo packages on this machine this morning, which may have something to do with it. Oddly, my machines are all very similar with more or less the same SBo packages installed and only my main machine is doing this.

I can't find anything useful by searching the web. One person suggested that logging in causes these messages, but I know I was sitting at the machine logged in for several of them. Has anyone seen something similar? I'm not worried about anything nefarious but I'm puzzled by the sudden appearance of these entries and wonder what's causing them.

Per this link, /var/log/secure is an alternative to /var/log/auth. A search for "auth log linux" turned up several articles. This one appears to be a good place to start.

Thanks, frankbell.

I think I worded my question poorly. I should have clarified that I'm not confused about log files, but I am wondering why, starting today, some process running as root does a brief su to my username now and then. I'm also wondering what that process is and what it's doing as my username during that time, but that seems harder to find out.

Is there anything unfamiliar in your shell history file?

Good idea, pghvlaans. Unfortunately, I see nothing unusual.

Would you mind sharing which SBo packages were upgraded? That might help narrow things down a bit.

Also, this is a long shot, but are there any surprise ssh connections as root in /var/log/secure*?

I'm mistaken; I upgraded some packages on another machine, but on this one I installed the following SBo packages:

pdfarranger-1.9.1-x86_64-1_SBo
pikepdf-5.3.2-x86_64-1_SBo
pybind11-2.10.0-x86_64-1_SBo
python3-deprecation-2.1.0-x86_64-1_SBo
python3-setuptools_scm_git_archive-1.1-x86_64-1_SBo

and just before the first instance of successful su for my username by root, slackpkg+ updated alienBOB's speex-1.2.0 package with the original slackware package speex-1.2.0-x86_64-4. (alienBOB's speex package must have disappeared from slackware.nl.)

There are no records of surprise root connections in /var/log/secure*. It would be quite the surprise as the machine has been behind the firewall at home for quite some time and root login requires an 8192 bit key. I don't suspect foul play.

Quote:

Originally Posted by tjallen (Post 6401132)

I am wondering why, starting today, some process running as root does a brief su to my username now and then.

If this phenomena has not stopped, you might be able to trace which process is running as root and doing su if you install audit:

https://slackbuilds.org/repository/15.0/system/audit/

and configure audit to keep an eye on /bin/su

regards Henrik

Quote:

Originally Posted by tjallen (Post 6401126)

I'm running slackware64 15.0 on all of my machines. Today I've started getting entries in /var/log/secure on my main machine that look like this:

Code:

su[19017]: Successful su for user by root

su[19017]: + ??? root:user

su[19017]: pam_unix(su:session): session opened for user user(uid=1000) by (uid=0)

su[19017]: gkr-pam: unable to locate daemon control file

su[19017]: gkr-pam: gnome-keyring-daemon started properly

su[19017]: pam_unix(su:session): session closed for user user

Looking at the PAM log, I understand that a program successfully changed from root to a user account.

This is magnitude grade less dangerous than a program changing from an unprivileged user account to root account.

Anyway, there are not so many programs in Slackware which goes from root to a user account, and I think first about SDDM or a similar User Login Manager.

BUT, same does the Apache server, which sinks in apache:apache or MySQL which goes mysql:mysql.

So, the question is also to which user account the program sinks? It's an local account or a system account?

I had some spamming gnome-keyring entries in /var/log/secure, I did ' grep gnome /etc/pam.d/* ' and edited each file which had pam_gnome_keyring.so lines, adding ' only_if=gdm ' at the end of those lines (I don't use gdm).

I am sure there are better ways though

Quote:

Originally Posted by LuckyCyborg (Post 6401234)

So, the question is also to which user account the program sinks? It's an local account or a system account?

It's my own, local user account on the machine, to which I'm logged in at the time. It's not a system account.

Quote:

Originally Posted by tjallen (Post 6401126)

Has anyone seen something similar?

no, not your way

Code:

su[19017]: + ??? root:user

gnome-keyring-daemon ?

Code:

Dec  7 11:49:03 darkstar su[6112]: The gnome keyring socket is not owned with the same credentials as the user login: /home/USERTJ/.cache/keyring-90FGS2/control

Dec  7 11:49:03 darkstar su[6112]: gkr-pam: couldn't unlock the login keyring.

Dec  7 11:49:03 darkstar su[6112]: Successful su for root by USERTJ

Dec  7 11:49:03 darkstar su[6112]: + /dev/pts/2 USERTJ:root

Dec  7 11:49:03 darkstar su[6112]: pam_unix(su:session): session opened for user root(uid=0) by USERTJ(uid=1000)

Dec  7 11:49:03 darkstar su[6112]: The gnome keyring socket is not owned with the same credentials as the user login: /home/USERTJ/.cache/keyring-90FGS2/control

Dec  7 11:49:03 darkstar su[6112]: gkr-pam: couldn't unlock the login keyring.

Dec  7 11:49:30 darkstar su[6112]: pam_unix(su:session): session closed for user root

Quote:

Originally Posted by keefaz (Post 6401237)

I'm testing to see if your modification stops the su from root.

Quote:

Originally Posted by tjallen (Post 6401258)

I'm testing to see if your modification stops the su from root.

You shouldn't.

Because otherwise you are at risk that Firefox or Chromium to be incapable to memorize/recover passwords.

Anyway, if those log messages are generated by the pam_gnome_keyring.so plugin, they are benign. Nothing there to freak out.

And I remember an old saying of those who use LinuxPAM since 20 years:

PAM is a nice lady, but never dare to mess with it.

You known why they say this? Because messing with the LinuxPAM configuration, it's even possible to lock out all accounts, including the root. I suggest you that until you have a fully functional live system to boot as alternative, to never touch the /etc/pam.d/ files or anything related with LinuxPAM or Kerberos. ;)

Well that didn't take long. keefaz's mods stopped the gkr-pam messages, but not the su by root. I reverted the pam changes so as not to overly worry LuckyCyborg :-). I'm still figuring out how to use auditd. In the meantime, I'm looking at all files that have recently changed.