[DRAFT v3.4] - audit cmdline updates
by William Roberts
Changes since last publish:
* Ran all patches through checkpatch, some elluded me.
* Changed cmdline copy/length API to reduce task_mm_get() mmput() calls
Still need to know:
* Any major objecttions to this still?
* My public API changes are in proc, is this the best spot for those?
As always, thanks.
[PATCH 1/4] audit: Allow auditing of proc/self/cmdline value
[PATCH 2/4] audit: Enable cacheing of cmdline in audit_context
[PATCH 3/4] audit: dont allocate whole pages
[PATCH 4/4] SQUASH audit: Change cmdline get API to reduce locking
11 years, 11 months
[PATCH v3.4] - Updates on cmdline auditing patches
by William Roberts
Patch 1 - Remains the same
Patch 2 - Updated the cache to use char* over unsigned long, but it still
caches a page
Patch 3 - Refactored the proc code, and the cache now uses kmalloc. Not sure if the new
refactored functions belong in base.c. They take a tas struct, so I am thinking
they should be relocated? Anyone have any thoughts on to where?
Patch 3 significantly droped the memory usage (before each got would have been 4096):
<snip>
<3>[ 27.891815] BILL req: 59 got: 64
<3>[ 27.897277] BILL req: 60 got: 64
<3>[ 27.902404] BILL req: 57 got: 64
<3>[ 27.907714] BILL req: 58 got: 64
<3>[ 27.912994] BILL req: 83 got: 128
<3>[ 27.918273] BILL req: 84 got: 128
<3>[ 27.923675] BILL req: 90 got: 128
<3>[ 27.929351] BILL req: 91 got: 128
<3>[ 27.939270] BILL req: 33 got: 64
<3>[ 27.944671] BILL req: 34 got: 64
<3>[ 27.951721] BILL req: 34 got: 64
<3>[ 27.958251] BILL req: 35 got: 64
<3>[ 27.963714] BILL req: 35 got: 64
<3>[ 27.969085] BILL req: 36 got: 64
<3>[ 27.989868] BILL req: 89 got: 128
<3>[ 27.995758] BILL req: 90 got: 128
<3>[ 28.001861] BILL req: 90 got: 128
<3>[ 28.007385] BILL req: 91 got: 128
<3>[ 28.019226] BILL req: 33 got: 64
<3>[ 28.029449] BILL req: 34 got: 64
<3>[ 28.034515] BILL req: 34 got: 64
<3>[ 28.039581] BILL req: 35 got: 64
<3>[ 28.044708] BILL req: 35 got: 64
<3>[ 28.049804] BILL req: 36 got: 64
<3>[ 31.352050] BILL req: 76 got: 128
Assuming they all stayed resident in the audit context
Total before:
102400
Total after:
2176
98% reduction in memory usage.
[PATCH 1/3] audit: Allow auditing of proc/self/cmdline value
[PATCH 2/3] audit: Enable cacheing of cmdline in audit_context
[PATCH 3/3] audit: dont allocate whole pages
11 years, 11 months
ANON message
by David Flatley
Getting an "ANOM_RBAC_INTEGRITY_FAIL" in audit output around the time
aide -C runs. In the message audit is reports the summary that Aide -C
reports. Kind of confused as to why
Role based authentication control, aide and audit mix to this message?
D. Flatley
11 years, 11 months
[PATCH v3.4] - audit cmdline on events
by William Roberts
Draft versions of some work I have been doing auditing the cmdline
value on events. The reason for this, is that I need to get the
package name in Android in the audit records. Often times, the app dies
before userspace would be able to get it from procfs.
I'll (attempt) to summarize the feedback so far.
* RGB - Can we make this dynamic?
** This was nak'd by Steve Grubb and subsequently dropped from these patches.
* Stephen Smalley - Can we cache this in audit struct for performance concerns?
** I think I address this in patch 2
* Steve Grubb - Is cmdline generic enough? Should we extend
prctl for an extended comm field?
** The heart of the matter is some spot the process can stick
more than 16 chars of data. I think this meets that, without
having to modify prctl.
* Steve Grubb - Can you use a user audit record?
** I can, but the downside is that it doesnt
keep the same id with the related issues, you
have to combine them by hand, by pid. Doesn't
seem like a generic solution.
Right now, the cache never gets invalidated, as their is no kernel
interface on which to invalidate the cache on. This would be one
win for adding to prctl.
Once we have a clear way forward on this, I can make the effort
to port to master.
[PATCH 1/2] audit: Allow auditing of proc/self/cmdline value
[PATCH 2/2] audit: Enable cacheing of cmdline in audit_context
11 years, 11 months
Audit Cross Compile Support
by AKASHI Takahiro
Hello Clayton,
I picked up your patches and tried to cross-build the package for
AArch64. In the following code of lib/gen_tables.py,
parser.add_argument('--i2s', dest='gen_i2s', action='',
should be
parser.add_argument('--i2s', dest='gen_i2s', action='store_true',
Right?
-Takahiro AKASHI
11 years, 11 months
logging changes in tty logging status
by Richard Guy Briggs
Hi Steve,
I'm reviewing audit_receive_msg() and noticing that the AUDIT_TTY_SET
case doesn't log a configuration change. Should it?
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
11 years, 11 months
Hash ideas on adding an extended comm field
by William Roberts
Previously I posted a patch to print during audit the proc/self/cmdline
value.
Steve Grubb had some concerns, as he has seen this before of "lets fix this
once and for all, properly"
The major concerns (consolidated) were:
1. The value could be set by the process at runtime and therefore easily
spoofed
2. The value could be too large (truncated at page level)
3. Performance concerns of copying a whole page from userspace on every
record
Steve Grubb proposed adding some field in struct task and extending the
prctl interface
for getter/setter.
My concern here, is the spoofing portion. Obviously this needs to be
controlled by someone
other then the process to which this applies, right now the PR_SET_NAME
would have the
same issue as cmdline, except be truncated to 16 bytes.
I don't see any capabilities or restrictions on existing prctl interfaces,
outside of the MAC hook.
Can anyone chime in and either tell me my concerns are over kill or what
here?
I don't want to go coding down a bad path on this.
--
Respectfully,
William C Roberts
11 years, 11 months
lib/audit.c (kernel)
by AKASHI Takahiro
Hi
I'm working on audit/seccomp support for AArch64 as you see in
[0/4] arm64: Add audit support
https://www.redhat.com/archives/linux-audit/2013-November/msg00040.html
ARM sub-system maintainer asked me whether it would be possible
to re-work lib/audit.c to work with "compat" syscalls.
My question is, "Is this reasonable to think about?"
(I know all the existing architectures already have their own
implementations.)
I'd like to get any comments before going further.
One of possible solutions is
* Add lib/compat_audit.c, where
#include "asm/unistd32.h" <= it seems somewhat arch-specific.
static unsigned dir_class[] = {
...
int audit_classify_compat_syscall() {
...
static int __init audit_compat_classes_init() {
...
__initcall(audit_compat_classes_init);
* In lib/audit.c,
#include <asm/audit.h>
#include <asm/unistd.h>
...
int audit_classify_arch(arch) {
#ifdef CONFIG_COMPAT
if (audit_is_compat(arch))
return 1;
#endif
return 0;
}
int audit_classify_syscall(abi, syscall) {
#ifdef CONFIG_COMPAT
if (audit_is_compat(arch))
return audit_classify_compat_syscall(abi, syscall);
#endif
...
}
* In arch/*/include/asm/audit.h,
#inlcude <linux/audit.h>
...
#define audit_is_compat(arch) \
((arch == AUDIT_ARCH_x) || (arch == AUDIT_ARCH_y))
-Takahiro AKASHI
11 years, 11 months
missing system call defs in audit(userspace)
by AKASHI Takahiro
Hi Steve
As I mentioned in my patch,
[0/4] arm64: Add audit support
there are missing system call definitions in lib/aarch64_table.h.
All those syscalls have the same attribute, __NR3264_*.
It seems intentional, right?
-Takahiro AKASHI
11 years, 11 months
order of entries output from ausearch -i
by AKASHI Takahiro
Hi Steve
I followed your advise and verified my patch of AArch64 audit support
by comparing the output from
# autrace /bin/ls
# ausearch -i -p XXX | grep SYSCALL
with the output from
# strace /bin/ls
Here I found that the entries shown by "ausearch -i" are listed
partially in the order of lifo (Last In First Out?).
I don't think this behavior is "intuitive".
(As you know, ausearch without -i generates fifo order of outputs.)
Is there any good reason?
Thanks,
-Takahiro AKASHI
11 years, 11 months
