10:56 a.m.
On Tuesday, January 19, 2021 8:15:33 AM EST Joe Wulf wrote:
1. In audit rules 2.8.5 (front portion of the rules):
## Unsuccessful file access (any other opens) This has to go last.
-a always,exit -F arch=b32 -S
open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES-a
always,exit -F arch=b64 -S
open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES-a
always,exit -F arch=b32 -S
open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM-a
always,exit -F arch=b64 -S
open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM
Whereas in audit rules 3.0, the same portion of the same rules looks like:
-a always,exit -F arch=b32 -S
open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES-a
always,exit -F arch=b32 -S
open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM-a
always,exit -F arch=b64 -S
open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EACCES-a
always,exit -F arch=b64 -S
open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EPERM
The ordering of the syscalls differs between the two, as well as the
sequential order of the rules themselves. I better understand that the
first audit-rule matched 'wins'.- Please help me understand the reason
for the change in sequence, but also for the change in the order of the
syscalls (i.e. between 2.8.5 and 3.0).
There were several 3.0 alpha releases. I'm not sure which one you are calling
3.0. Because I can't find an exact match. Based on the text above, I do not
see the syscall ordering changed at all. The only thing that I see is in
2.8.5 they are grouped by exit code whereas 3.0 is grouped by arch. Since
this group of rules all have the same key, they are working as a team. That
means that what matters is the placement of this group of rules relative to
other groups of rules is what matters. In both cases a syscall can ever only
match one of them - the exit code either is or isn't EPERM, it either is or
isn't b32.
2. I notice there are many rules across the entire set (both 2.8.5
and
3.0) that define their key with "-F key=<name>", and others simply with
"-k <name>".- Why are their two methods for KEY naming, and does one
have
a distinct meaning, or precedence, over the other?
This is explained in the audit.rules man page in the discussion about
watches. Way back in 2005, there was the idea of filesystem watches. The
syntax for them was
-w path-to-file -p permissions -k keyname
The initial implementation was found to have some limits and it was rewritten
around 2006 around a new syscall API. The old syscall API was deprecated,
too. This new syscall API was capable of handling pathes. So, that means the
following is equivalent to the above
-a always,exit -F path=path-to-file -F perm=permissions -F key=keyname
But to preserve backwards compatibility, auditctl translates the first form
into the second under the covers. You cannot mix the two notations in the
same rule or auditctl will reject it.
Are their some 'rule' types where '-k' is
appropriate, whereas '-F key=" is
not, thus they are not truly 100% interchangeable?
Hopefully above makes this clear.
- If both methods ARE equivalent
throughout ALL of the audit.rules content, would it be reasonable to
standardize on one method in v3.0.x of your rules going forward?
It appears that all rules have been standardized around the syscall method
except for the nispom and stig rules which are no longer preferred. I suppose
at some point I should just drop nispom since no one has asked about meeting
it in 12 or 13 years. At this point, the ospp rules are the recommended rule
set.
3. For a RHEL 7.x (and even 8.x) system where the hardware is x86_64
and
there is no reasonable expectation to install or operate 'ANY' 32bit
software, is there any value, or system performance penalty, to totally
eliminating all 'b32' rules?
You could. But then I'd add "21-no32bit.rules" to detect if something
tries
to use it to evade detection. The 32 bit ABI is available even on 64 bit
systems.
4. On the grub/kernel commandline, I can add: 'audit=1'
-and-
'audit_backlog_limit=####'. I looked for solutions to address the issue I
was having, and found one here:
https://access.redhat.com/solutions/19327; I found another somewhat
helpful reference here:
https://blog.siphos.be/2015/05/audit-buffering-and-rate-limiting; though
it doesn't make good recommendations for the kernel parameter sizing (if
that is a good thing to do in RHEL 7/RHEL 8). - Is there good relevance
in RHEL 7, or RHEL 8 to adding this option to the grub/kernel
commandline?- Is there an upper-limit in setting the number? - What is
the correlation of this grub/kernel item, to the '-b ####' rule in
/etc/audit/rules.d/audit.rules? Are they (or should they be treated as)
mutually exclusive? - In the 2nd reference, what process do you suggest
for me to determine optimal values for 'kernel.printk_ratelimit' -and -
'kernel.printk_ratelimit_burst', as well as for grub/kernel
'audit_backlog_limit=####' and audit.rules '-b ####'? - This link also
seems relevant to the sysctl param's valuations:
https://topic.alibabacloud.com/a/linux-system-log-__ratelimitn-callbacks-s
uppressed_1_16_30164105.html- Does values for 'kernel.printk_ratelimit =
1'; -and- 'kernel.printk_ratelimit_burst = 1024' seem reasonable?
I covered this topic here:
http://security-plus-data-science.blogspot.com/2017/05/a-suggested-change...
-Steve