syscall list update: Rename multiple syscalls to be up to date with kernel

[Cropi]

I checked all relevant files from the kernel part mentioned in lib/syscall-update.txt.
I haven't observed any significat updates on socketcall/ipccall.

Some notes:

• Interpretation could be added for: arm_sync_file_range/sync_file_range, s390_guarded_storage
• Name of certain syscalls was wrongly specified (pread/pwrite instead of pread64/pwrite64)
• ppc/s390 tables had many missing fields

[stevegrubb]

This looks like a good update. One of the goals in naming things is to try to have the same syscall names on each arch so that the rules we ship are not arch dependent. And the other thing I've been trying to do is if you strace a process, you can use the same syscall names that you saw in the strace output to make your audit rules. We get reports that someone is not getting events. To troubleshoot it I have them run strace so they can update their rules.

Also, do we need to change any rules that we ship to match the new names?

[Cropi]

This looks like a good update. One of the goals in naming things is to try to have the same syscall names on each arch so that the rules we ship are not arch dependent. And the other thing I've been trying to do is if you strace a process, you can use the same syscall names that you saw in the strace output to make your audit rules. We get reports that someone is not getting events. To troubleshoot it I have them run strace so they can update their rules.

Also, do we need to change any rules that we ship to match the new names?

I went through the list of changes and the followings are suspicious:

• clock_settime vs clock_settime64
• clock_adjtime vs clock_adjtime64

Whilst the first one is present in all supported architectures (plus there are rules for it), the second is not.

## 10.4.2b Time data is protected.
## We will place rules to check time synchronization
-a always,exit -F arch=b32 -S adjtimex,settimeofday,stime -F key=10.4.2b-time-change
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=10.4.2b-time-change
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=10.4.2b-time-change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=10.4.2b-time-change

How should we proceed if a particular security standard includes rules that depend on architecture-specific system calls?

[stevegrubb]

Yes, this is the kind of problems a change could make. In this case, I wonder what strace shows? I know that there is a glibc wrapper that is clock_settime. The actual syscall is clock_settime64. But it doesn't have a man page.

In cases like this, I was going with the glibc wrapper because Common Criteria has a rule that all syscall must be documented. We really want to point to the man page and not make busy work.

Another issue is auparse/normalize_syscall_map.h It is used to match syscall names to categorize what kind of object the event is working with. Changes to anything need to be coordinated with that file also.

One last point, if the auditd is in the enriched mode, it will translate the syscall number into the syscall name. It is impossible to undo. Once it's recorded, that's how it will be intepreted. It does not do a new lookup to see if it was correct. That could mean mismatches in the normalizer that used to work fine.

Based on this, we might want to be very conservative so the whole world doesn't break.

[Cropi]

Yes, this is the kind of problems a change could make. In this case, I wonder what strace shows? I know that there is a glibc wrapper that is clock_settime. The actual syscall is clock_settime64. But it doesn't have a man page.

My guess is that both clock_settime and clock_settime64 are Y2038 safe and do the same thing internally, but don't have strong evidence except for some mailing list discussions.

In cases like this, I was going with the glibc wrapper because Common Criteria has a rule that all syscall must be documented. We really want to point to the man page and not make busy work.

arm, i386, ppc tables already contain clock_settime64, so maybe it's safe to add it for s390 as well. Neither interpreter, nor auparse/normalize_syscall_map.h contains it. I could also add a comment to the relevant sample rules files, saying that in 32b you should monitor clock_settime64 and clock_adjtime64 as well. Not sure what else could be done here.
Based on this, I don't have a strong opinion how to move forward.

Another issue is auparse/normalize_syscall_map.h It is used to match syscall names to categorize what kind of object the event is working with. Changes to anything need to be coordinated with that file also.

One last point, if the auditd is in the enriched mode, it will translate the syscall number into the syscall name. It is impossible to undo. Once it's recorded, that's how it will be intepreted. It does not do a new lookup to see if it was correct. That could mean mismatches in the normalizer that used to work fine.

Based on this, we might want to be very conservative so the whole world doesn't break.