[PATCH v2 0/3] dm: audit event logging
by Michael Weiß
dm integrity and also stacked dm crypt devices track integrity
violations internally. Thus, integrity violations could be polled
from user space, e.g., by 'integritysetup status'.
>From an auditing perspective, we only could see that there were
a number of integrity violations, but not when and where the
violation exactly was taking place. The current error log to
the kernel ring buffer, contains those information, time stamp and
sector on device. However, for auditing the audit subsystem provides
a separate logging mechanism which meets certain criteria for secure
audit logging.
With this small series we make use of the kernel audit framework
and extend the dm driver to log audit events in case of such
integrity violations. Further, we also log construction and
destruction of the device mappings.
We focus on dm-integrity and stacked dm-crypt devices for now.
However, the helper functions to log audit messages should be
applicable to dm verity too.
The first patch introduce generic audit wrapper functions.
The second patch makes use of the audit wrapper functions in the
dm-integrity.c.
The third patch uses the wrapper functions in dm-crypt.c.
The audit logs look like this if executing the following simple test:
# dd if=/dev/zero of=test.img bs=1M count=1024
# losetup -f test.img
# integritysetup -vD format --integrity sha256 -t 32 /dev/loop0
# integritysetup open -D /dev/loop0 --integrity sha256 integritytest
# integritysetup status integritytest
# integritysetup close integritytest
# integritysetup open -D /dev/loop0 --integrity sha256 integritytest
# integritysetup status integritytest
# dd if=/dev/urandom of=/dev/loop0 bs=512 count=1 seek=100000
# dd if=/dev/mapper/integritytest of=/dev/null
-------------------------
audit.log from auditd
type=UNKNOWN[1336] msg=audit(1628692862.187:409): module=integrity dev=254:3 op=ctr res=1
type=UNKNOWN[1336] msg=audit(1628692862.443:410): module=integrity dev=254:3 op=dtr res=1
type=UNKNOWN[1336] msg=audit(1628692862.543:411): module=integrity dev=254:3 op=ctr res=1
type=UNKNOWN[1336] msg=audit(1628692877.943:412): module=integrity dev=254:3 op=dtr res=1
type=UNKNOWN[1336] msg=audit(1628692887.287:413): module=integrity dev=254:3 op=ctr res=1
type=UNKNOWN[1336] msg=audit(1628692925.156:417): module=integrity dev=254:3 op=dtr res=1
type=UNKNOWN[1336] msg=audit(1628692930.720:418): module=integrity dev=254:3 op=ctr res=1
type=UNKNOWN[1336] msg=audit(1628692989.344:419): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:420): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:421): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:422): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:423): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:424): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:425): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:426): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:427): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:428): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
v2 Changes:
- Fixed compile errors if CONFIG_DM_AUDIT is not set
- Fixed formatting and typos as suggested by Casey
Michael Weiß (3):
dm: introduce audit event module for device mapper
dm integrity: log audit events for dm-integrity target
dm crypt: log aead integrity violations to audit subsystem
drivers/md/Kconfig | 10 +++++++
drivers/md/Makefile | 4 +++
drivers/md/dm-audit.c | 59 ++++++++++++++++++++++++++++++++++++++
drivers/md/dm-audit.h | 33 +++++++++++++++++++++
drivers/md/dm-crypt.c | 22 +++++++++++---
drivers/md/dm-integrity.c | 25 +++++++++++++---
include/uapi/linux/audit.h | 1 +
7 files changed, 146 insertions(+), 8 deletions(-)
create mode 100644 drivers/md/dm-audit.c
create mode 100644 drivers/md/dm-audit.h
--
2.20.1
3 years, 11 months
[PATCH 0/3] dm: audit event logging
by Michael Weiß
dm integrity and also stacked dm crypt devices track integrity
violations internally. Thus, integrity violations could be polled
from user space, e.g., by 'integritysetup status'.
>From an auditing perspective, we only could see that there were
a number of integrity violations, but not when and where the
violation exactly was taking place. The current error log to
the kernel ring buffer, contains those information, time stamp and
sector on device. However, for auditing the audit subsystem provides
a separate logging mechanism which meets certain criteria for secure
audit logging.
With this small series we make use of the kernel audit framework
and extend the dm driver to log audit events in case of such
integrity violations. Further, we also log construction and
destruction of the device mappings.
We focus on dm-integrity and stacked dm-crypt devices for now.
However, the helper functions to log audit messages should be
applicable to dm verity too.
The first patch introduce generic audit wrapper functions.
The second patch makes use of the audit wrapper functions in the
dm-integrity.c.
The third patch uses the wrapper functions in dm-crypt.c.
The audit logs look like this if executing the following simple test:
# dd if=/dev/zero of=test.img bs=1M count=1024
# losetup -f test.img
# integritysetup -vD format --integrity sha256 -t 32 /dev/loop0
# integritysetup open -D /dev/loop0 --integrity sha256 integritytest
# integritysetup status integritytest
# integritysetup close integritytest
# integritysetup open -D /dev/loop0 --integrity sha256 integritytest
# integritysetup status integritytest
# dd if=/dev/urandom of=/dev/loop0 bs=512 count=1 seek=100000
# dd if=/dev/mapper/integritytest of=/dev/null
-------------------------
audit.log from auditd
type=UNKNOWN[1336] msg=audit(1628692862.187:409): module=integrity dev=254:3 op=ctr res=1
type=UNKNOWN[1336] msg=audit(1628692862.443:410): module=integrity dev=254:3 op=dtr res=1
type=UNKNOWN[1336] msg=audit(1628692862.543:411): module=integrity dev=254:3 op=ctr res=1
type=UNKNOWN[1336] msg=audit(1628692877.943:412): module=integrity dev=254:3 op=dtr res=1
type=UNKNOWN[1336] msg=audit(1628692887.287:413): module=integrity dev=254:3 op=ctr res=1
type=UNKNOWN[1336] msg=audit(1628692925.156:417): module=integrity dev=254:3 op=dtr res=1
type=UNKNOWN[1336] msg=audit(1628692930.720:418): module=integrity dev=254:3 op=ctr res=1
type=UNKNOWN[1336] msg=audit(1628692989.344:419): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:420): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:421): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:422): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:423): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:424): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:425): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:426): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:427): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
type=UNKNOWN[1336] msg=audit(1628692989.348:428): module=integrity dev=254:3 op=integrity-checksum sector=77480 res=0
Michael Weiß (3):
dm: introduce audit event module for device mapper
dm integrity: log audit events for dm-integrity target
dm crypt: log aead integrity violations to audit subsystem
drivers/md/Kconfig | 10 +++++++
drivers/md/Makefile | 4 +++
drivers/md/dm-audit.c | 59 ++++++++++++++++++++++++++++++++++++++
drivers/md/dm-audit.h | 33 +++++++++++++++++++++
drivers/md/dm-crypt.c | 23 ++++++++++++---
drivers/md/dm-integrity.c | 25 +++++++++++++---
include/uapi/linux/audit.h | 2 ++
7 files changed, 148 insertions(+), 8 deletions(-)
create mode 100644 drivers/md/dm-audit.c
create mode 100644 drivers/md/dm-audit.h
--
2.20.1
4 years
Re: [PATCH v7 0/5] IMA: restrict the accepted digest algorithms for the security.ima xattr
by Mimi Zohar
[Cc'ing linux-audit]
Hi Simon,
On Wed, 2021-08-11 at 11:40 +0000, THOBY Simon wrote:
Other than the two questions on " IMA: add a policy option to restrict
xattr hash algorithms on appraisal" patch, the patch set is looking
good.
thanks,
Mimi
> Here is also a short description of the new audit messages, but I can
> send it in a followup mail if that is not the proper place:
>
> When writing the xattr with an algorithm not built in the kernel (here the
> kernel was built with CONFIG_CRYPTO_MD5 unset), e.g. with
> "evmctl ima_hash -a md5 /usr/bin/strace":
> audit(1628066120.418:121): pid=1344 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=set_data cause=unavailable-hash-algorithm comm="evmctl" name="/usr/bin/strace" dev="dm-0" ino=2632657 res=0 errno=0
>
> With the same command and the policy rule
> "appraise func=SETXATTR_CHECK appraise_algos=sha256,sha384,sha512", we get:
> audit(1628066210.141:127): pid=1362 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=set_data cause=denied-hash-algorithm comm="evmctl" name="/usr/bin/strace" dev="dm-0" ino=2632657 res=0 errno=0
>
> Note that the cause is now 'denied-hash-algorithm' instead of
> 'unavailable-hash-algorithm'. We get that audit message for any algorithm
> outside of sha256/384/512 (including algorithms not compiled in the kernel
> like MD5). In a sense, 'denied-hash-algorithm' takes predecence over
> 'unavailable-hash-algorithm'.
>
> When appraising files, e.g. trying to execute a file whose xattr was hashed
> with sha1 while the policy rule
> "appraise func=BPRM_CHECK fowner=0 appraise_algos=sha256" is enabled:
> audit(1628066349.230:130): pid=1369 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=collect_data cause=denied-hash-algorithm comm="bash" name="/usr/bin/strace" dev="dm-0" ino=2632657 res=0 errno=0
>
>
> This series is based on the following repo/branch:
> repo: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
> branch: next-integrity-testing
> commit e37be5343ae2b9419aea1442b07e5d2428b437b4 ("Merge branch 'ima-buffer-measurement-changes-v4' into next-integrity")
4 years
audit-3.0.5 released
by Steve Grubb
Hello,
I've just released a new version of the audit daemon. It can be
downloaded from http://people.redhat.com/sgrubb/audit. It will also be
in rawhide soon. The ChangeLog is:
- In auditd, flush uid/gid caches when user/group added/deleted/modified
- Fixed various issues when dealing with corrupted logs
- In auditd, check if log_file is valid before closing handle
I usually do not make a release this quick after doing one. But there was an
issue (209) reported on github that I think merits an immediate release. The
issue is that if you create, delete, and create a new user with a new name,
auditd may have stale cache entries for the older user.
If you use the enriched format (default setting), then this old association
can get added to the record. That can cause ausearch to report actions
attributed to the old user name. Normally people don't delete and create
users quickly. By design, the cache is only 19 entries long and flushes the
least recently used.
Please test audit-3.0.5 carefully - 3.0.4 had big changes.
SHA256: 7c54e73a6cafc8154ee6e37971efb1c8dd9ac2361daec429a52a7538c24fdc70
Please let me know if you run across any problems with this release.
-Steve
4 years
BUG: segfault on systemctl auditd stop
by Brown, Thomas
Hello,
The following auditd segfault occurs during shutdown but can be
reproduced using the service stop command...
service auditd stop 2root@aug-test:/# 2021 Aug 4 12:47:22 aug-test
Process 687 (auditd) of user 0 dumped core. 34Stack trace of thread 687:
5#0 0x00007f18bb1657e4 fclose (libc.so.6) 6#1 0x000055b88ab50ec0 n/a
(auditd) 7#2 0x000055b88ab4e421 n/a (auditd) 8#3 0x000055b88ab4d9a7 n/a
(auditd) 9#4 0x00007f18bb11a09b __libc_start_main (libc.so.6) 10#5
0x000055b88ab4df4a n/a (auditd)
Setting AUDIT_WRITE_LOGS to "yes" corrects this problem however we have
a requirement to disable these logs (i.e. AUDIT_WRITE_LOGS needs to be
set to "no")
After perusing the source I suspect that one of these unconditional
fclose()s is causing the problem...
git diff ./src/aureport.c
diff --git a/src/aureport.c b/src/aureport.c
index 22618f0..6359144 100644
--- a/src/aureport.c
+++ b/src/aureport.c
@@ -277,7 +277,8 @@ static int process_log_fd(const char *filename)
list_clear(entries);
free(entries);
} while (ret == 0);
- fclose(log_fd);
+ if (log_fd)
+ fclose(log_fd);
// This is the per file action items
very_last_event.sec = last_event.sec;
very_last_event.milli = last_event.milli;
git diff ./src/ausearch.c
diff --git a/src/ausearch.c b/src/ausearch.c
index 4a6bdae..df14df5 100644
--- a/src/ausearch.c
+++ b/src/ausearch.c
@@ -481,7 +481,8 @@ static int process_log_fd(void)
checkpt_failure |= CP_CORRUPTED;
list_clear(entries);
free(entries);
- fclose(log_fd);
+ if (log_fd)
+ fclose(log_fd);
return 10;
}
if (just_one) {
@@ -497,7 +498,8 @@ static int process_log_fd(void)
if (set_ChkPtLastEvent(&entries->e)) {
list_clear(entries);
free(entries);
- fclose(log_fd);
+ if (log_fd)
+ fclose(log_fd);
return 4; /* no memory */
}
}
@@ -505,7 +507,8 @@ static int process_log_fd(void)
list_clear(entries);
free(entries);
} while (ret == 0);
- fclose(log_fd);
+ if (log_fd)
+ fclose(log_fd);
return 0;
}
However I have not tested these changes. Even though this is a benign
problem I believe that it warrants a correction. Please open a ticket
and respond with the ticket id so that we can track this problem/solution.
--
Kind Regards,
Thomas Brown
Linux Developer
EPS PBU RT Solution Services
411 Leggett Drive
Suite 502
Kanata, ON, Canada
K2K 3C9
Tel: 613-963-1016
Fax: 613-599-1060
4 years
[PATCH RFC] audit-userspace: support for MAC_TASK_CONTEXTS and MAC_OBJ_CONTEXTS
by Casey Schaufler
This patch supplies userspace support for the MAC_TASK_CONTEXTS
and MAC_OBJ_CONTEXTS audit records proposed as part of the Linux
security module (LSM) stacking effort.
I have posted as an RFC because, well, I'd like comments.
The additional context values are added to the existing lists.
The existing search methods work on these lists, so that's about
all it takes.
---
lib/libaudit.h | 8 ++++
lib/msg_typetab.h | 2 +
src/ausearch-parse.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 111 insertions(+)
diff --git a/lib/libaudit.h b/lib/libaudit.h
index ed75892..9bc3aa9 100644
--- a/lib/libaudit.h
+++ b/lib/libaudit.h
@@ -311,6 +311,14 @@ extern "C" {
#define AUDIT_MAC_CALIPSO_DEL 1419 /* NetLabel: del CALIPSO DOI entry */
#endif
+#ifndef AUDIT_MAC_TASK_CONTEXTS
+#define AUDIT_MAC_TASK_CONTEXTS 1420 /* Multilple task contexts */
+#endif
+
+#ifndef AUDIT_MAC_OBJ_CONTEXTS
+#define AUDIT_MAC_OBJ_CONTEXTS 1421 /* Multilple object contexts */
+#endif
+
#ifndef AUDIT_ANOM_LINK
#define AUDIT_ANOM_LINK 1702 /* Suspicious use of file links */
#endif
diff --git a/lib/msg_typetab.h b/lib/msg_typetab.h
index dba2f7b..e6df28b 100644
--- a/lib/msg_typetab.h
+++ b/lib/msg_typetab.h
@@ -147,6 +147,8 @@ _S(AUDIT_MAC_UNLBL_STCADD, "MAC_UNLBL_STCADD" )
_S(AUDIT_MAC_UNLBL_STCDEL, "MAC_UNLBL_STCDEL" )
_S(AUDIT_MAC_CALIPSO_ADD, "MAC_CALIPSO_ADD" )
_S(AUDIT_MAC_CALIPSO_DEL, "MAC_CALIPSO_DEL" )
+_S(AUDIT_MAC_TASK_CONTEXTS, "MAC_TASK_CONTEXTS" )
+_S(AUDIT_MAC_OBJ_CONTEXTS, "MAC_OBJ_CONTEXTS" )
_S(AUDIT_ANOM_PROMISCUOUS, "ANOM_PROMISCUOUS" )
_S(AUDIT_ANOM_ABEND, "ANOM_ABEND" )
_S(AUDIT_ANOM_LINK, "ANOM_LINK" )
diff --git a/src/ausearch-parse.c b/src/ausearch-parse.c
index 9ee4a4f..286829e 100644
--- a/src/ausearch-parse.c
+++ b/src/ausearch-parse.c
@@ -63,6 +63,8 @@ static int parse_simple_message(const lnode *n, search_items *s);
static int parse_tty(const lnode *n, search_items *s);
static int parse_pkt(const lnode *n, search_items *s);
static int parse_kernel(lnode *n, search_items *s);
+static int parse_task_contexts(lnode *n, search_items *s);
+static int parse_obj_contexts(lnode *n, search_items *s);
static int audit_avc_init(search_items *s)
@@ -184,6 +186,12 @@ int extract_search_items(llist *l)
case AUDIT_TTY:
ret = parse_tty(n, s);
break;
+ case AUDIT_MAC_TASK_CONTEXTS:
+ ret = parse_task_contexts(n, s);
+ break;
+ case AUDIT_MAC_OBJ_CONTEXTS:
+ ret = parse_obj_contexts(n, s);
+ break;
default:
if (event_debug)
fprintf(stderr,
@@ -2768,3 +2776,96 @@ static int parse_kernel(lnode *n, search_items *s)
return 0;
}
+static int parse_task_context(lnode *n, search_items *s, char *c, int l)
+{
+ char *str, *term;
+ anode an;
+
+ str = strstr(n->message, c);
+ if (str == NULL)
+ return 64;
+
+ str += l;
+ term = strchr(str, '"');
+ if (term == NULL)
+ return 62;
+ *term = 0;
+ if (audit_avc_init(s) != 0)
+ return 63;
+
+ anode_init(&an);
+ an.scontext = strdup(str);
+ alist_append(s->avc, &an);
+ *term = '"';
+
+ return 0;
+}
+
+// parse multiple security module contexts
+// subj_<lsm>...
+static int parse_task_contexts(lnode *n, search_items *s)
+{
+ int rc, final = 64;
+
+ if (!event_subject)
+ return 0;
+
+ rc = parse_task_context(n, s, "subj_selinux=\"", 14);
+ if (rc == 62 || rc == 63)
+ return rc;
+ if (rc == 0)
+ final = 0;
+
+ rc = parse_task_context(n, s, "subj_smack=\"", 12);
+ if (rc == 62 || rc == 63)
+ return rc;
+ if (rc == 0)
+ final = 0;
+
+ rc = parse_task_context(n, s, "subj_apparmor=\"", 15);
+ if (rc == 62 || rc == 63)
+ return rc;
+ if (rc == 0)
+ final = 0;
+
+ return final;
+}
+
+static int parse_obj_context(lnode *n, search_items *s, char *c, int l)
+{
+ char *str, *term;
+ anode an;
+
+ str = strstr(n->message, c);
+ if (str != NULL) {
+ str += l;
+ term = strchr(str, '"');
+ if (term)
+ *term = 0;
+ if (audit_avc_init(s) != 0)
+ return 2;
+ anode_init(&an);
+ an.tcontext = strdup(str);
+ alist_append(s->avc, &an);
+ if (term)
+ *term = '"';
+ }
+
+ return 0;
+}
+
+// parse multiple object security module contexts
+// obj_<lsm>...
+static int parse_obj_contexts(lnode *n, search_items *s)
+{
+ // obj context
+ if (!event_object)
+ return 0;
+
+ if (parse_obj_context(n, s, "obj_selinux=\"", 12))
+ return 2;
+ if (parse_obj_context(n, s, "obj_smack=\"", 10))
+ return 2;
+
+ return 0;
+}
4 years
auditd not logging proper log.
by Rakesh Kumar
Hi Team,
I have two queries.
1)I am trying to run the auditd (start/stop) without root user as normal user , how to achieve this on linux.?2)i am using kernel version 4.19.97 nd i ma not getting any login/logout, authentication fail/pass log data in audit.log file. DOes it need any changes in the config or rules..
Please help me out on these query. Any answer would be appreciable.
Regards,Rakesh
4 years
audit-3.0.4 released
by Steve Grubb
Hello,
I've just released a new version of the audit daemon. It can be
downloaded from http://people.redhat.com/sgrubb/audit. It will also be
in rawhide soon. The ChangeLog is:
- Apply performance speedups to auparse library
- Optimize rule loading in auditctl
- Fix an auparse memory leak caused by glibc-2.33 by replacing realpath
- Update syscall table to the 5.14 kernel
- Fixed various issues when dealing with corrupted logs
The big change in this release is converting the lowest level data structure
in the auparse library from a linked list to an array. Linked lists are not
CPU cache friendly. This change brought about a 20% speed improvement for the
library. The down side is that an array has a fixed size. This is controlled
by the NFIELDS define in rnode.h, which is currently 36. SYSCALL events have
the most normal fields. They currently have about 28. So, 36 should be a good
safety margin going forward.
The only records that potentially have more fields is the EXECVE record. For
the audit-3.0.4 release, this is limited to 36 fields by auparse. This does
not affect ausearch output. Ausearch uses an entirely different method to
parse/disply events. If anyone is *using* auparse and thinks auparse should
handle more EXECVE fields, let me know. I might switch to a hybrid model that
uses a linked list after consuming all of the array.
Next, auparse was switched from doing strtok/strdup to having one record and
an array of pointers that point to a different segment of that record. On a
typical test that I performed,
ausearch -if /var/log/audit/audit.log.1 --format csv > /dev/null 2>&1
valgrind reports 55 million allocations. With this switch, valgrind now
reports 5 million allocations. This speeds up auparse another 35%. All in
all, the test I run above runs in half the time that audit-3.0.3 does.
Because this is a big change in design, I spent a few days fuzzing ausearch/
report/auparse. I don't not want to fix everything a fuzzer makes because it
won't happen in real life. For example, no record will have 10 comm= fields.
But this found a significant number of issues in various places - which are
now fixed. The audit libraries should now be more robust in the face of
corrupt logs.
Also, I noticed that auparse was leaking memory. This turned out to be a
behavior change in glibc-2.33's realpath function. It was returning an error
even though it succeeded. Therefore, auparse didn't process or free the
allocated buffer. In looking at the source code for realpath, I found that it
also calls stat and readlink. Neither of these should be needed for path
normalization after the fact. So, a new function was created to handle path
normalization. You may notice some changes in paths returned when
interpretting. But they are correct now where glibc was unable to stat the
file.
Please test audit-3.0.4 carefully - it has big changes.
SHA256: 8c5ae825b9d2837742b626fa93b86cb4a84d15530bf05b6cb42be3f304db8cf6
Please let me know if you run across any problems with this release.
-Steve
4 years
last restart of auditd - in EPOCH time
by warron.french
Is there a hidden switch option to auditctl that would tell me the last
time auditd was restart specifically in epoch (down to the second)?
If my rules are changed to non-immutable ( -e 1 ) rebooted, and then
changed back to immutable ( -e 2 ), then I discover this weeks later, then
I will not know for sure which was most recently updated/restarted.
That is the reason for the question. I am doing this for a hardening
script that will tell me based on known recent changes (as of script
execution), but I cannot properly/successfully assess for dates outside of
a day or so. :-/
Any ideas would be appreciated,
--------------------------
Warron French
4 years
[PATCH] kernel/auditsc: remove unused header file
by Hui Su
Since commit c72051d5778a ("audit: use ktime_get_coarse_ts64()
for time access"), the linux/time.h is unused.
Signed-off-by: Hui Su <suhui(a)zeku.com>
---
kernel/auditsc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 8dd73a64f921..33bb6a83baf1 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -57,7 +57,6 @@
#include <linux/mqueue.h>
#include <linux/audit.h>
#include <linux/personality.h>
-#include <linux/time.h>
#include <linux/netlink.h>
#include <linux/compiler.h>
#include <asm/unistd.h>
--
2.30.2
4 years
