BUG: wrong PROCTITLE record for ANOM_LINK creation

[pcmoore]

When experimenting with the ANOM_LINK event creation, it was found that the proctitle record seemed to have the exe of the ppid instead of the pid's.

This has been observed on Fedora kernel 4.1.6-200.fc22.x86_64.

Reproducer

As a non-root user:

# cd /tmp
# ln -s /bin/passwd my-passwd

As root:

# ausearch --start recent -m anom_link -i
<verify you have nothing>
# chown lp /tmp/my-passwd       <- but use tab completion after /tmp/m
<this will fail>
# ausearch --start recent -m anom_link -i | grep PROCTITLE
type=PROCTITLE msg=audit(08/27/2015 19:22:40.823:1246) : proctitle=-bash 
type=PROCTITLE msg=audit(08/27/2015 19:22:40.824:1247) : proctitle=su - root 
type=PROCTITLE msg=audit(08/27/2015 19:22:40.824:1248) : proctitle=su - root 
type=PROCTITLE msg=audit(08/27/2015 19:22:43.489:1249) : proctitle=chown lp /tmp/my-passwd 

Expected Results

I would not expect su to be involved.

[rgbriggs]

On f23, 4.5.7-200.fc23.x86_64, I get 4 ANOM_LINK records, but no PROCTITLE records. Is there a more complete procedure or settings?

[pcmoore]

@sgrubb I believe you originally reported this, can you help Richard?

@rgbriggs not that I expect any difference, but have you tried this on a current kernel (upstream or Rawhide)?

[rgbriggs]

Ok, I tried it on an f22 vm with a 4.6 custom kernel and I get the proctitle records, so I can proceed. I don't get the exact same output as above because of a different route to arrive at a root login (bash/su/su vs. bash/bash/bash), which wasn't detailed in the original report. I still don't understand why f23 with a newer kernel and audit doesn't give me proctitle records...

[pcmoore]

That does seem a bit odd, perhaps something to look at afterwards ... although as long as the upstream/current kernel is behaving as we would expect I'm not sure it is worth a lot of effort for the older kernels.

[rgbriggs]

The four records are from two distinct operations. The fourth is from chown. This looks as expected. The first three are from tab completion in bash, attempting a stat. The first is from a child bash. The second and third are listed as coming from its parent which is also the parent of chown, the current bash shell. This seems like a lot of stat calls for tab completion, but looks ok to me. I can't explain the "su" entries in the original report unless su execs bash and doesn't update proctitle.

[stevegrubb]

For the records, this was bz 1259765.

I tried to reproduce it and things have changed. I'm on F24. I did the normal procedure as detailed in comment 1 but I always use su - root to become root from my login. Now I see 3 -bash and 1 chown.. I looked at the /proc//cmdline for the processes that were still active and its wrong (-bash) there. ps -ef also picks up the wrong name and displays it.

Using strace I see only one thing that is unusual: [pid 5545] execve("/bin/bash", ["-bash"], [/* 9 vars */]) = 0

If this was a bz I would get the bash maintainer to ask what is going on.

[pcmoore]

For the records, this was bz 1259765.

If you are going to reference an external issue tracker please provide a better reference, "bz" or "bugzilla" is ambiguous here. A better option would be to use "Red Hat Bugzilla", "RHBZ", or simply provide a URL (the best and least ambiguous method).

• https://bugzilla.redhat.com/show_bug.cgi?id=1259765

If this was a bz I would get the bash maintainer to ask what is going on.

Comments like this aren't helpful. If you want to reach out to the Fedora Bash package maintainers it is easy to look them up via the Fedora's Package DB:

• https://admin.fedoraproject.org/pkgdb
• https://admin.fedoraproject.org/pkgdb/package/rpms/bash

It appears that the main point of contact is Siteshwar Vashisht (svashisht), and a quick search on GitHub indicates that he has an account here in addition to his contact info which can be found in the package changelog/DB.

[pcmoore]

Just adding some notes from our off-list discussion today ... @rgbriggs reach out to the Bash folks to see what they have to say about this, depending on how that discussion goes I think we might be able to close this out as NOTABUG.

[pcmoore]

@rgbriggs I know you reach out to the Bash developers, any updates?

[rgbriggs]

@pcmoore not yet, but I have an indicator of life...

[siteshwar]

I tried the reproducer steps on a Fedora 23 system. This is the output I received :

[situ@localhost tmp]$ ln -s /bin/passwd my-passwd
[situ@localhost tmp]$ su - root
Password: 
[root@localhost ~]# aus
ausearch   ausyscall  
[root@localhost ~]# ausearch --start recent -m anom_link -i
<no matches>
[root@localhost ~]# chown lp /tmp/my-passwd 
chown: cannot dereference ‘/tmp/my-passwd’: Permission denied
[root@localhost ~]# ausearch --start recent -m anom_link -i | grep -i PROCTITLE
[root@localhost ~]# ausearch --start recent -m anom_link -i 
----
type=ANOM_LINK msg=audit(09/09/2016 02:53:40.876:395) : op=follow_link ppid=4208 pid=4289 auid=situ uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts3 ses=1 comm=bash exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no 
----
type=ANOM_LINK msg=audit(09/09/2016 02:53:40.877:397) : op=follow_link ppid=4193 pid=4208 auid=situ uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts3 ses=1 comm=bash exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no 
----
type=ANOM_LINK msg=audit(09/09/2016 02:53:40.877:399) : op=follow_link ppid=4193 pid=4208 auid=situ uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts3 ses=1 comm=bash exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no 
----
type=ANOM_LINK msg=audit(09/09/2016 02:53:44.559:401) : op=follow_link ppid=4208 pid=4294 auid=situ uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts3 ses=1 comm=chown exe=/usr/bin/chown subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no 

[root@localhost ~]# uname -a
Linux localhost.localdomain 4.5.7-200.fc23.x86_64 #1 SMP Wed Jun 8 17:41:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

So I was not able to reproduce this bug. Let me know if I missed anything.

[pcmoore]

@stevegrubb @rgbriggs I think we can close this out now, any objections?

[rgbriggs]

@pcmoore @stevegrubb Unless we have a clear reproducing procedure, I would be in favour of closing it.

[pcmoore]

Okay, I'm closing this. @stevegrubb if you have any new information that would demonstrate that this is still a bug please reopen this issue.