[ANNOUNCE] Linux Security Summit North America 2018 - CFP
== ANNOUNCEMENT AND CALL FOR PARTICIPATION LINUX SECURITY SUMMIT NORTH AMERICA 2018 27-28 August VANCOUVER, CANADA == DESCRIPTION The Linux Security Summit (LSS) is a technical forum for collaboration between Linux developers, researchers, and end users. Its primary aim is to foster community efforts in analyzing and solving Linux security challenges. LSS will be held this year as two separate events, one in North America (LSS-NA), and one in Europe (LSS-EU), to facilitate broader participation in Linux Security development. Note that this CFP is for LSS-NA; a separate CFP will be announced for LSS-EU in May. We encourage everyone to attend both events. The program committee currently seeks proposals for: * Refereed Presentations: 45 minutes in length. * Panel Discussion Topics: 45 minutes in length. * Short Topics: 30 minutes in total, including at least 10 minutes discussion. * BoF Sessions. Topic areas include, but are not limited to: * Kernel self-protection * Access control * Cryptography and key management * Integrity control * Hardware Security * Iot and embedded security * Virtualization and containers * System-specific system hardening * Case studies * Security tools * Security UX * Emerging technologies, threats & techniques Proposals should be submitted via: https://events.linuxfoundation.org/events/linux-security-summit-north-america-2018/program/cfp/ DATES * CFP Close: June 3, 2018 * CFP Notifications: June 11, 2018 * Schedule Announced: June 25, 2018 * Event: August 27-28, 2018 WHO SHOULD ATTEND We're seeking a diverse range of attendees, and welcome participation by people involved in Linux security development, operations, and research. The LSS is a unique global event which provides the opportunity to present and discuss your work or research with key Linux security community members and maintainers. It’s also useful for those who wish to keep up with the latest in Linux security development, and to provide input to the development process. WEB SITE https://events.linuxfoundation.org/events/linux-security-summit-north-america-2018/ TWITTER For event updates and announcements, follow: https://twitter.com/LinuxSecSummit PROGRAM COMMITTEE The program committee for LSS 2018 is: * James Morris, Microsoft * Serge Hallyn, Cisco * Paul Moore, Red Hat * Stephen Smalley, NSA * Elena Reshetova, Intel * John Johansen, Canonical * Kees Cook, Google * Casey Schaufler, Intel * Mimi Zohar, IBM * David A. Wheeler, Institute for Defense Analyses The program committee may be contacted as a group via email: lss-pc () lists.linuxfoundation.org -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH ghak47 V1] audit: normalize MAC_POLICY_LOAD record
The audit MAC_POLICY_LOAD record had redundant dangling keywords and was missing information about which LSM was responsible and its completion status. While this record is only issued on success, the parser expects the res= field to be present. Old record: type=MAC_POLICY_LOAD msg=audit(1479299795.404:43): policy loaded auid=0 ses=1 Delete the redundant dangling keywords, add the lsm= field and the res= field. New record: type=MAC_POLICY_LOAD msg=audit(1523293846.204:894): auid=0 ses=1 lsm=selinux res=1 See: https://github.com/linux-audit/audit-kernel/issues/47 Signed-off-by: Richard Guy Briggs --- security/selinux/selinuxfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c index 00b21b2..496915a 100644 --- a/security/selinux/selinuxfs.c +++ b/security/selinux/selinuxfs.c @@ -531,7 +531,7 @@ static ssize_t sel_write_load(struct file *file, const char __user *buf, out1: audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_POLICY_LOAD, - "policy loaded auid=%u ses=%u", + "auid=%u ses=%u lsm=selinux res=1", from_kuid(&init_user_ns, audit_get_loginuid(current)), audit_get_sessionid(current)); out: -- 1.8.3.1 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH ghak46 V1] audit: normalize MAC_STATUS record
There were two formats of the audit MAC_STATUS record, one of which was more standard than the other. One listed enforcing status changes and the other listed enabled status changes with a non-standard label. In addition, the record was missing information about which LSM was responsible and the operation's completion status. While this record is only issued on success, the parser expects the res= field to be present. old enforcing/permissive: type=MAC_STATUS msg=audit(1523312831.378:24514): enforcing=0 old_enforcing=1 auid=0 ses=1 old enable/disable: type=MAC_STATUS msg=audit(1523312831.378:24514): selinux=0 auid=0 ses=1 List both sets of status and old values and add the lsm= field and the res= field. Here is the new format: type=MAC_STATUS msg=audit(1523293828.657:891): enforcing=0 old_enforcing=1 auid=0 ses=1 enabled=1 old-enabled=1 lsm=selinux res=1 This record already accompanied a SYSCALL record. See: https://github.com/linux-audit/audit-kernel/issues/46 Signed-off-by: Richard Guy Briggs --- security/selinux/selinuxfs.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c index 00eed84..00b21b2 100644 --- a/security/selinux/selinuxfs.c +++ b/security/selinux/selinuxfs.c @@ -145,10 +145,11 @@ static ssize_t sel_write_enforce(struct file *file, const char __user *buf, if (length) goto out; audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS, - "enforcing=%d old_enforcing=%d auid=%u ses=%u", + "enforcing=%d old_enforcing=%d auid=%u ses=%u" + " enabled=%d old-enabled=%d lsm=selinux res=1", new_value, selinux_enforcing, from_kuid(&init_user_ns, audit_get_loginuid(current)), - audit_get_sessionid(current)); + audit_get_sessionid(current), selinux_enabled, selinux_enabled); selinux_enforcing = new_value; if (selinux_enforcing) avc_ss_reset(0); @@ -272,9 +273,11 @@ static ssize_t sel_write_disable(struct file *file, const char __user *buf, if (length) goto out; audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS, - "selinux=0 auid=%u ses=%u", + "enforcing=%d old_enforcing=%d auid=%u ses=%u" + " enabled=%d old-enabled=%d lsm=selinux res=1", + selinux_enforcing, selinux_enforcing, from_kuid(&init_user_ns, audit_get_loginuid(current)), - audit_get_sessionid(current)); + audit_get_sessionid(current), 0, 1); } length = count; -- 1.8.3.1 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: Can auditd run in lxc on centos7
On 2018-04-09 15:52, John Jasen wrote: > As points of clarification: > > would audit on the host have visibility into the container? (for > example, logging execve calls from certain users) Yes, but filenames and inodes may not make sense if the filesystem isn't mounted in the host mount namespace. > would pam_tty_audit running the host still be able to collect data upon > entering the container? Yes, I believe so. > Thanks! > > On 04/05/2018 02:28 PM, Steve Grubb wrote: > > On Thursday, April 5, 2018 12:52:24 PM EDT Bob Beck wrote: > >> Thanks for your quick reply. > >> > >> Do you mean that it logs events from within the 1 specific lxc container > >> in which it is running but not the host VM? > > Nope. It would only work as an aggregating server. Meaning it can collect > > logs from remote systems. But it cannot collect anything itself. Not from > > the > > container nor the host kernel. It can only log what comes across a tcp/ip > > connection from another auditd. This is a limitation of the kernel - which > > is > > being worked on currently. > > > > -Steve > > > >> -Original Message- > >> From: Steve Grubb [mailto:sgr...@redhat.com] > >> Sent: Thursday, April 05, 2018 12:37 PM > >> To: linux-audit@redhat.com > >> Cc: Bob Beck > >> Subject: Re: Can auditd run in lxc on centos7 > >> > >> On Thursday, April 5, 2018 12:26:15 PM EDT Bob Beck wrote: > >>> Hi, > >>> > >>> I am attempting to run auditd in centos7 inside a lxc container. > >> It can run inside a container only as an aggregating server. Meaning that > >> it cannot audit the host system, but rather collect logs from remote > >> systems. To do this, set local_events = no. This was added in > >> audit-2.5.2. > >>> Here is the log I get when I run auditd -f > >>> > >>> config file /etc/audit/auditd.conf opened for parsing > >>> > >>> log_file_parser called with: /var/log/audit.log > >>> > >>> log_format_parser called with: RAW > >>> > >>> log_group_parser called with: root > >>> > >>> priority_boost_parser called with: 4 > >>> > >>> flush_parser called with: INCREMENTAL > >>> > >>> freq_parser called with: 20 > >>> > >>> num_logs_parser called with: 5 > >>> > >>> qos_parser called with: lossy > >>> > >>> dispatch_parser called with: /usr/sbin/audispd > >>> > >>> name_format_parser called with: NONE > >>> > >>> max_log_size_parser called with: 6 > >>> > >>> max_log_size_action_parser called with: ROTATE > >>> > >>> space_left_parser called with: 75 > >>> > >>> space_action_parser called with: SYSLOG > >>> > >>> action_mail_acct_parser called with: root > >>> > >>> admin_space_left_parser called with: 50 > >>> > >>> admin_space_left_action_parser called with: SUSPEND > >>> > >>> disk_full_action_parser called with: SUSPEND > >>> > >>> disk_error_action_parser called with: SUSPEND > >>> > >>> tcp_listen_queue_parser called with: 5 > >>> > >>> tcp_max_per_addr_parser called with: 1 > >>> > >>> tcp_client_max_idle_parser called with: 0 > >>> > >>> enable_krb5_parser called with: no > >>> > >>> GSSAPI support is not enabled, ignoring value at line 30 > >>> > >>> krb5_principal_parser called with: auditd > >>> > >>> GSSAPI support is not enabled, ignoring value at line 31 > >>> > >>> Started dispatcher: /usr/sbin/audispd pid: 3028 > >>> > >>> type=DAEMON_START msg=audit(1522944040.042:592): op=start ver=2.8.4 > >>> format=raw kernel=3.10.0-693.17.1.el7.centos.plus.i686 auid=4294967295 > >>> pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t > >>> res=success > >>> > >>> config_manager init complete > >>> > >>> Error sending status request (Connection refused) > >>> > >>> Error sending enable request (Connection refused) > >>> > >>> type=DAEMON_ABORT msg=audit(1522944040.043:593): op=set-enable > >>> auid=4294967295 pid=3026 uid=0 ses=4294967295 > >>> subj=system_u:system_r:init_t res=failed > >>> > >>> Unable to set initial audit startup state to 'enable', exiting > >>> > >>> The audit daemon is exiting. > >>> > >>> Error setting audit daemon pid (Connection refused) > >> Yep. That is what you get when trying to audit the host from a unprivileged > >> container. Container support in the kernel is still an ongoing project. > >> > >> -Steve - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: Can auditd run in lxc on centos7
As points of clarification: would audit on the host have visibility into the container? (for example, logging execve calls from certain users) would pam_tty_audit running the host still be able to collect data upon entering the container? Thanks! On 04/05/2018 02:28 PM, Steve Grubb wrote: > On Thursday, April 5, 2018 12:52:24 PM EDT Bob Beck wrote: >> Thanks for your quick reply. >> >> Do you mean that it logs events from within the 1 specific lxc container >> in which it is running but not the host VM? > Nope. It would only work as an aggregating server. Meaning it can collect > logs from remote systems. But it cannot collect anything itself. Not from the > container nor the host kernel. It can only log what comes across a tcp/ip > connection from another auditd. This is a limitation of the kernel - which is > being worked on currently. > > -Steve > >> -Original Message- >> From: Steve Grubb [mailto:sgr...@redhat.com] >> Sent: Thursday, April 05, 2018 12:37 PM >> To: linux-audit@redhat.com >> Cc: Bob Beck >> Subject: Re: Can auditd run in lxc on centos7 >> >> On Thursday, April 5, 2018 12:26:15 PM EDT Bob Beck wrote: >>> Hi, >>> >>> I am attempting to run auditd in centos7 inside a lxc container. >> It can run inside a container only as an aggregating server. Meaning that >> it cannot audit the host system, but rather collect logs from remote >> systems. To do this, set local_events = no. This was added in >> audit-2.5.2. >>> Here is the log I get when I run auditd -f >>> >>> config file /etc/audit/auditd.conf opened for parsing >>> >>> log_file_parser called with: /var/log/audit.log >>> >>> log_format_parser called with: RAW >>> >>> log_group_parser called with: root >>> >>> priority_boost_parser called with: 4 >>> >>> flush_parser called with: INCREMENTAL >>> >>> freq_parser called with: 20 >>> >>> num_logs_parser called with: 5 >>> >>> qos_parser called with: lossy >>> >>> dispatch_parser called with: /usr/sbin/audispd >>> >>> name_format_parser called with: NONE >>> >>> max_log_size_parser called with: 6 >>> >>> max_log_size_action_parser called with: ROTATE >>> >>> space_left_parser called with: 75 >>> >>> space_action_parser called with: SYSLOG >>> >>> action_mail_acct_parser called with: root >>> >>> admin_space_left_parser called with: 50 >>> >>> admin_space_left_action_parser called with: SUSPEND >>> >>> disk_full_action_parser called with: SUSPEND >>> >>> disk_error_action_parser called with: SUSPEND >>> >>> tcp_listen_queue_parser called with: 5 >>> >>> tcp_max_per_addr_parser called with: 1 >>> >>> tcp_client_max_idle_parser called with: 0 >>> >>> enable_krb5_parser called with: no >>> >>> GSSAPI support is not enabled, ignoring value at line 30 >>> >>> krb5_principal_parser called with: auditd >>> >>> GSSAPI support is not enabled, ignoring value at line 31 >>> >>> Started dispatcher: /usr/sbin/audispd pid: 3028 >>> >>> type=DAEMON_START msg=audit(1522944040.042:592): op=start ver=2.8.4 >>> format=raw kernel=3.10.0-693.17.1.el7.centos.plus.i686 auid=4294967295 >>> pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t >>> res=success >>> >>> config_manager init complete >>> >>> Error sending status request (Connection refused) >>> >>> Error sending enable request (Connection refused) >>> >>> type=DAEMON_ABORT msg=audit(1522944040.043:593): op=set-enable >>> auid=4294967295 pid=3026 uid=0 ses=4294967295 >>> subj=system_u:system_r:init_t res=failed >>> >>> Unable to set initial audit startup state to 'enable', exiting >>> >>> The audit daemon is exiting. >>> >>> Error setting audit daemon pid (Connection refused) >> Yep. That is what you get when trying to audit the host from a unprivileged >> container. Container support in the kernel is still an ongoing project. >> >> -Steve > > > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v2] audit: allow not equal op for audit by executable
On 2018-04-09 10:00, Ondrej Mosnacek wrote: > From: Ondrej Mosnáček > > Current implementation of auditing by executable name only implements > the 'equal' operator. This patch extends it to also support the 'not > equal' operator. > > See: https://github.com/linux-audit/audit-kernel/issues/53 > > Signed-off-by: Ondrej Mosnacek Looks good to me. Reveiwed-by: Richard Guy Briggs > --- > kernel/auditfilter.c | 2 +- > kernel/auditsc.c | 2 ++ > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c > index d7a807e81451..a0c5a3ec6e60 100644 > --- a/kernel/auditfilter.c > +++ b/kernel/auditfilter.c > @@ -426,7 +426,7 @@ static int audit_field_valid(struct audit_entry *entry, > struct audit_field *f) > return -EINVAL; > break; > case AUDIT_EXE: > - if (f->op != Audit_equal) > + if (f->op != Audit_not_equal && f->op != Audit_equal) > return -EINVAL; > if (entry->rule.listnr != AUDIT_FILTER_EXIT) > return -EINVAL; > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index 4e0a4ac803db..479c031ec54c 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -471,6 +471,8 @@ static int audit_filter_rules(struct task_struct *tsk, > break; > case AUDIT_EXE: > result = audit_exe_compare(tsk, rule->exe); > + if (f->op == Audit_not_equal) > + result = !result; > break; > case AUDIT_UID: > result = audit_uid_comparator(cred->uid, f->op, f->uid); > -- > 2.14.3 > - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v2] audit: allow not equal op for audit by executable
On Mon, Apr 9, 2018 at 4:00 AM, Ondrej Mosnacek wrote: > From: Ondrej Mosnáček > > Current implementation of auditing by executable name only implements > the 'equal' operator. This patch extends it to also support the 'not > equal' operator. > > See: https://github.com/linux-audit/audit-kernel/issues/53 > > Signed-off-by: Ondrej Mosnacek > --- > kernel/auditfilter.c | 2 +- > kernel/auditsc.c | 2 ++ > 2 files changed, 3 insertions(+), 1 deletion(-) This looks better, thanks. I think we should also add a test for this added to the exec_name tests, could you also do that please? * https://github.com/linux-audit/audit-testsuite/blob/master/tests/exec_name/test You can send the audit-testsuite patch either to this mailing list or as a PR against the GitHub project. > diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c > index d7a807e81451..a0c5a3ec6e60 100644 > --- a/kernel/auditfilter.c > +++ b/kernel/auditfilter.c > @@ -426,7 +426,7 @@ static int audit_field_valid(struct audit_entry *entry, > struct audit_field *f) > return -EINVAL; > break; > case AUDIT_EXE: > - if (f->op != Audit_equal) > + if (f->op != Audit_not_equal && f->op != Audit_equal) > return -EINVAL; > if (entry->rule.listnr != AUDIT_FILTER_EXIT) > return -EINVAL; > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index 4e0a4ac803db..479c031ec54c 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -471,6 +471,8 @@ static int audit_filter_rules(struct task_struct *tsk, > break; > case AUDIT_EXE: > result = audit_exe_compare(tsk, rule->exe); > + if (f->op == Audit_not_equal) > + result = !result; > break; > case AUDIT_UID: > result = audit_uid_comparator(cred->uid, f->op, > f->uid); > -- > 2.14.3 > -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: auditing automounted filesystems (NFS)
On 04/07/2018 06:38 PM, Frank Thommen wrote: On 07/04/18 13:56, Richard Guy Briggs wrote: On 2018-04-07 04:04, Frank Thommen wrote: Hello, we have started auditing on our systems (file open, close, write etc.). This is no problem on local and on statically mounted NFS systems (-a exit,always -F dir=/a/b/c ...). However for automounted filesystems auditd only reports on system calls on those filesystems which are mounted when auditd starts. Is there a way to make auditd aware of newly mounted NFS filesystems, so that we can audit them, too? Have you looked at the auditctl "-t" (trim) and "-q" (equivalent) commands? I'm not certain they do exactly what you want, but may help. Thanks a lot. I don't understand what "trim" means in this context. Reading the explanation in the manpage ("Trim the subtrees after a mount command") I'd expect this to happen after an UNmount, not a mount...? However -q looks promising. I'll give it a try. Unfortunately this didn't work. Either our config is wrong or I misunderstand what "-q" does: Example: /mnt/test is automounted (/etc/auto.mnt: test -vers=3 fs:/export/test) In /etc/audit/audit.rules we have --- [...] -a always,exit -F dir=/mnt -F arch=b64 -S write -S open -S close -S rename -S mkdir -S chmod -S chown -S rmdir -S unlink -S unlinkat -S renameat -S fchmod -S fchown -S symlink -S symlinkat -S readlink -S link -S readlinkat -S linkat -S fchmodat -S fchownat -k fs- -q /mnt,/mnt/test --- when I unmount /mnt/test, restart auditd and then do e.g. a `cat /mnt/test/myfile`, then I get the following entries in the audit log: --- type=SYSCALL msg=audit(1523295277.512:3124883): arch=c03e syscall=89 success=no exit=-22 a0=7ffeac151c70 a1=7ffeac150c20 a2=1000 a3=7ffeac1509b0 items=1 ppid=15487 pid=11761 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mount" exe="/usr/bin/mount" key="fs-" type=PATH msg=audit(1523295277.512:3124883): item=0 name="/mnt" inode=57521 dev=00:74 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL type=SYSCALL msg=audit(1523295277.512:3124884): arch=c03e syscall=89 success=no exit=-22 a0=7ffeac151c70 a1=7ffeac150c20 a2=1000 a3=7ffeac1509b0 items=1 ppid=15487 pid=11761 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mount" exe="/usr/bin/mount" key="fs-" type=PATH msg=audit(1523295277.512:3124884): item=0 name="/mnt/test" inode=1049245405 dev=00:74 mode=040555 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL type=SYSCALL msg=audit(1523295277.516:3124885): arch=c03e syscall=89 success=no exit=-22 a0=7ffe3dc73d80 a1=7ffe3dc72d30 a2=1000 a3=7ffe3dc72ac0 items=1 ppid=11761 pid=11769 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mount.nfs" exe="/sbin/mount.nfs" key="fs-" type=PATH msg=audit(1523295277.516:3124885): item=0 name="/mnt" inode=57521 dev=00:74 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL type=SYSCALL msg=audit(1523295277.516:3124886): arch=c03e syscall=89 success=no exit=-22 a0=7ffe3dc73d80 a1=7ffe3dc72d30 a2=1000 a3=7ffe3dc72ac0 items=1 ppid=11761 pid=11769 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mount.nfs" exe="/sbin/mount.nfs" key="fs-" type=PATH msg=audit(1523295277.516:3124886): item=0 name="/mnt/test" inode=1049245405 dev=00:74 mode=040555 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL --- Access to the file itself is not logged. When I restart auditd while /mnt/test /is/ mounted, then a `cat /mnt/test/myfile` results in --- type=SYSCALL msg=audit(1523295467.808:3125055): arch=c03e syscall=2 success=yes exit=3 a0=7a9c424c a1=0 a2=1fff a3=7a9c2560 items=1 ppid=22404 pid=4794 auid=22189 uid=22189 gid=1110 euid=22189 suid=22189 fsuid=22189 egid=1110 sgid=1110 fsgid=1110 tty=pts7 ses=662075 comm="cat" exe="/usr/bin/cat" key="fs-" type=PATH msg=audit(1523295467.808:3125055): item=0 name="/mnt/test/myfile" inode=13 dev=00:80 mode=0100764 ouid=6836 ogid=2515 rdev=00:00 nametype=NORMAL --- in the logfile. That's the entries I'd like to see even when /mnt/test is unmounted when auditd is started. Can that be done at all? Cheers frank -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH v2] audit: allow not equal op for audit by executable
From: Ondrej Mosnáček Current implementation of auditing by executable name only implements the 'equal' operator. This patch extends it to also support the 'not equal' operator. See: https://github.com/linux-audit/audit-kernel/issues/53 Signed-off-by: Ondrej Mosnacek --- kernel/auditfilter.c | 2 +- kernel/auditsc.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c index d7a807e81451..a0c5a3ec6e60 100644 --- a/kernel/auditfilter.c +++ b/kernel/auditfilter.c @@ -426,7 +426,7 @@ static int audit_field_valid(struct audit_entry *entry, struct audit_field *f) return -EINVAL; break; case AUDIT_EXE: - if (f->op != Audit_equal) + if (f->op != Audit_not_equal && f->op != Audit_equal) return -EINVAL; if (entry->rule.listnr != AUDIT_FILTER_EXIT) return -EINVAL; diff --git a/kernel/auditsc.c b/kernel/auditsc.c index 4e0a4ac803db..479c031ec54c 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -471,6 +471,8 @@ static int audit_filter_rules(struct task_struct *tsk, break; case AUDIT_EXE: result = audit_exe_compare(tsk, rule->exe); + if (f->op == Audit_not_equal) + result = !result; break; case AUDIT_UID: result = audit_uid_comparator(cred->uid, f->op, f->uid); -- 2.14.3 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit