16

I can do

auditctl -a always,exit -S all -F pid=1234

To log all the system calls done by pid 1234 and:

auditctl -a always,exit -S all -F ppid=1234

For its children, but how do I cover the grand-children and their children as well (current and future)?

I cannot rely on (e)uid/(e)gid that do change.

(note that using strace is not an option either)

Stéphane Chazelas
  • 522,931
  • 91
  • 1,010
  • 1,501
  • 4
    omg, omg, omg, Stephane *asking* a question... (I came here just from the title, thinking `strace -s` ^^ but then I saw who was asking and immediately knew "he knows that already!" )... Stephane, can you maybe: 1) build the list of pids using the "tree" option of ps, 2) launch auditctl(s) on all the pids listed in the tree ? (ie, can you have multiple "pid=...." ? or multiple auditctl, each on one?) or the "dumb" way: auditctl everything, and some kind of egrep on the "pid|pid|pid" if they appear on each line?) (caveat: I don't have access to linux atm, so I have no idea how infos appear) – Olivier Dulac Oct 30 '14 at 15:00
  • a trick you could maybe use (once again, I don't know specifics of auditd, nor can I try at the moment) : specify a specific environnement variable when launching the topmost parent, and auditctl all processes having this variable set? – Olivier Dulac Oct 30 '14 at 15:12
  • @OlivierDulac, marking the process in some way (that is inherited by children) is one thing I have in mind. But the list of things audit rules can match on is quite thin (not even sid, pgid...). Maybe the SELinux ones, but I don't know the first thing about SELinux. Maybe process name spaces? – Stéphane Chazelas Oct 30 '14 at 15:25
  • maybe the topmost parent can be in its own process group ? ( http://en.wikipedia.org/wiki/Process_group ) – Olivier Dulac Oct 30 '14 at 15:55
  • @OlivierDulac, as I said, it doesn't seem you can match on pgid (or sid). – Stéphane Chazelas Oct 30 '14 at 16:01
  • oops ^^ sorry. But seems to me you are trying to do what strace does, without using strace ? What is your exact need? Why do you need all system calls of all childs? (maybe you are just trying to find out what calls something specific?) And why can't you use strace or a variant thereof? (apart from the sheer slowdown it induces on the processes) – Olivier Dulac Oct 30 '14 at 16:06
  • 2
    I thought maybe run your program in a specific container, if that's an option for you. If I understand [this bug thread](https://bugzilla.redhat.com/show_bug.cgi?id=893751) correctly, that should work with a kernel ≥3.13. Other than that, I don't see any method other than SELinux and the [audit UID](https://www.redhat.com/archives/linux-audit/2010-December/msg00019.html). Would the AUID be applicable to your use case? – Gilles 'SO- stop being evil' Oct 31 '14 at 00:31
  • @Gilles, sounds promising, a POC would be welcome. – Stéphane Chazelas Oct 31 '14 at 10:39

1 Answers1

1

Just proposing something without having any way to try it right now... but just guessing from the post itself

Here is a proposal of solution:

Assuming the topmost process id is in $pid, and that on linux as well ps -T gives out the tree of processes (I can't have access to linux at the moment)

for eachpid in $(ps -T "$pid" | awk '{print $1}' | grep -v 'PID')
do
   auditctl -a always,exit -S all -F pid=$eachpid  >somelog_${eachpid}.log 2>&1
done

Of course, replace ps -T "$pid" with the equivalent for linux, if that one doesn't work on linux (or find it by awk-ing the "pstree -p" output, the pid will be between parenthesis)

Olivier Dulac
  • 5,924
  • 1
  • 23
  • 35
  • 2
    Thanks, but that doesn't cover "future" children, and running that in a loop frequently won't cover short-lived processes. And pid re-use would cause a problem as well. – Stéphane Chazelas Oct 30 '14 at 15:22
  • all valid points... Then I believe that what you want is probably a "most wanted" feature, and therefore could already be present at the auditctl level (but it certainly doesn't appear right now in the manpage): it may have to be proposed (or... written) for a future version. I don't recall some way to "follow a tree" of processes... but you could maybe implement one by 1) having some script do regular "ps -T" equivalents, 2) another script kills the 1st one as soon as the pid dies 3) each time the list of pid from 1) changes, add/remove the auditctl for those pids ? (not too hard to do) – Olivier Dulac Oct 30 '14 at 15:28
  • 1
    (my last comment doesn't solve the pb for very short lived processes... this may need something at the kernel level itself, and I don't know enough to tell you if something exists for that. May be worth a question on the kernel mailing lists) – Olivier Dulac Oct 30 '14 at 15:29