[PATCH] audit: always enable syscall auditing when supported and audit is enabled
by Paul Moore
To the best of our knowledge, everyone who enables audit at compile
time also enables syscall auditing; this patch simplifies the Kconfig
menus by removing the option to disable syscall auditing when audit
is selected and the target arch supports it.
Signed-off-by: Paul Moore <pmoore(a)redhat.com>
---
init/Kconfig | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index c24b6f7..d4663b1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -299,20 +299,15 @@ config AUDIT
help
Enable auditing infrastructure that can be used with another
kernel subsystem, such as SELinux (which requires this for
- logging of avc messages output). Does not do system-call
- auditing without CONFIG_AUDITSYSCALL.
+ logging of avc messages output). System call auditing is included
+ on architectures which support it.
config HAVE_ARCH_AUDITSYSCALL
bool
config AUDITSYSCALL
- bool "Enable system-call auditing support"
+ def_bool y
depends on AUDIT && HAVE_ARCH_AUDITSYSCALL
- default y if SECURITY_SELINUX
- help
- Enable low-overhead system-call auditing infrastructure that
- can be used independently or with another kernel subsystem,
- such as SELinux.
config AUDIT_WATCH
def_bool y
6 years
RFC(v2): Audit Kernel Container IDs
by Richard Guy Briggs
Containers are a userspace concept. The kernel knows nothing of them.
The Linux audit system needs a way to be able to track the container
provenance of events and actions. Audit needs the kernel's help to do
this.
Since the concept of a container is entirely a userspace concept, a
registration from the userspace container orchestration system initiates
this. This will define a point in time and a set of resources
associated with a particular container with an audit container ID.
The registration is a pseudo filesystem (proc, since PID tree already
exists) write of a u8[16] UUID representing the container ID to a file
representing a process that will become the first process in a new
container. This write might place restrictions on mount namespaces
required to define a container, or at least careful checking of
namespaces in the kernel to verify permissions of the orchestrator so it
can't change its own container ID. A bind mount of nsfs may be
necessary in the container orchestrator's mntNS.
Note: Use a 128-bit scalar rather than a string to make compares faster
and simpler.
Require a new CAP_CONTAINER_ADMIN to be able to carry out the
registration. At that time, record the target container's user-supplied
container identifier along with the target container's first process
(which may become the target container's "init" process) process ID
(referenced from the initial PID namespace), all namespace IDs (in the
form of a nsfs device number and inode number tuple) in a new auxilliary
record AUDIT_CONTAINER with a qualifying op=$action field.
Issue a new auxilliary record AUDIT_CONTAINER_INFO for each valid
container ID present on an auditable action or event.
Forked and cloned processes inherit their parent's container ID,
referenced in the process' task_struct.
Mimic setns(2) and return an error if the process has already initiated
threading or forked since this registration should happen before the
process execution is started by the orchestrator and hence should not
yet have any threads or children. If this is deemed overly restrictive,
switch all threads and children to the new containerID.
Trust the orchestrator to judiciously use and restrict CAP_CONTAINER_ADMIN.
Log the creation of every namespace, inheriting/adding its spawning
process' containerID(s), if applicable. Include the spawning and
spawned namespace IDs (device and inode number tuples).
[AUDIT_NS_CREATE, AUDIT_NS_DESTROY] [clone(2), unshare(2), setns(2)]
Note: At this point it appears only network namespaces may need to track
container IDs apart from processes since incoming packets may cause an
auditable event before being associated with a process.
Log the destruction of every namespace when it is no longer used by any
process, include the namespace IDs (device and inode number tuples).
[AUDIT_NS_DESTROY] [process exit, unshare(2), setns(2)]
Issue a new auxilliary record AUDIT_NS_CHANGE listing (opt: op=$action)
the parent and child namespace IDs for any changes to a process'
namespaces. [setns(2)]
Note: It may be possible to combine AUDIT_NS_* record formats and
distinguish them with an op=$action field depending on the fields
required for each message type.
When a container ceases to exist because the last process in that
container has exited and hence the last namespace has been destroyed and
its refcount dropping to zero, log the fact.
(This latter is likely needed for certification accountability.) A
container object may need a list of processes and/or namespaces.
A namespace cannot directly migrate from one container to another but
could be assigned to a newly spawned container. A namespace can be
moved from one container to another indirectly by having that namespace
used in a second process in another container and then ending all the
processes in the first container.
(v2)
- switch from u64 to u128 UUID
- switch from "signal" and "trigger" to "register"
- restrict registration to single process or force all threads and children into same container
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
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
7 years, 1 month
Systemd Journald and audit logging causing journal issues
by Brad Zynda
Hello Everyone,
I am sending along an issue brought to the systemd-journald dev list
initially:
On 10/02/2017 11:40 AM, Lennart Poettering wrote:
> On Mo, 02.10.17 11:25, Brad Zynda (bradley.v.zynda(a)nasa.gov) wrote:
>
>> Sep 28 13:50:03 server systemd-journal[565]: Suppressed 73244 messages
>> from /system.slice/auditd.service
>
> The question is: why does auditd even log to the journal?
>
>> Now we are required to have full audit rules and does this look like at
>> rate limiting issue or an issue of journal not able to handle the
>> traffic to logging?
>
> journald detected that it got flooded with too many messages in too
> short a time from auditd. if this happens then something is almost
> certainly off with auditd, as auditd is not supposed to flood journald
> with messages, after all it maintains its own auditing log database.
>
> Please ping the auditd folks for help
>
> Lennart
>
_______________________________________________
systemd-devel mailing list
systemd-devel(a)lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Hey Everyone,
Not sure if this is a bug so:
systemctl status -l systemd-journald.service
● systemd-journald.service - Journal Service
Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service;
static; vendor preset: disabled)
Active: active (running) since Tue 2017-09-26 20:01:16 UTC; 5 days ago
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 565 (systemd-journal)
Status: "Processing requests..."
CGroup: /system.slice/systemd-journald.service
└─565 /usr/lib/systemd/systemd-journald
Sep 28 13:50:03 server systemd-journal[565]: Suppressed 73244 messages
from /system.slice/auditd.service
Sep 28 13:51:03 server systemd-journal[565]: Suppressed 98979 messages
from /system.slice/auditd.service
Sep 28 13:52:03 server systemd-journal[565]: Suppressed 109433 messages
from /system.slice/auditd.service
Sep 28 13:53:03 server systemd-journal[565]: Suppressed 99788 messages
from /system.slice/auditd.service
Sep 28 13:54:03 server systemd-journal[565]: Suppressed 111605 messages
from /system.slice/auditd.service
Sep 28 13:55:03 server systemd-journal[565]: Suppressed 111591 messages
from /system.slice/auditd.service
Sep 28 13:56:03 server systemd-journal[565]: Suppressed 107947 messages
from /system.slice/auditd.service
Sep 28 13:57:51 server systemd-journal[565]: Suppressed 32760 messages
from /system.slice/auditd.service
Sep 28 17:21:40 server systemd-journal[565]: Suppressed 210 messages
from /system.slice/auditd.service
Oct 01 02:16:01 server systemd-journal[565]: Suppressed 1333 messages
from /system.slice/auditd.service
journalctl --verify
PASS: /run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-000000000097f6c7-0005596b745b4d1c.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-000000000096a587-00055966f35ae59a.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-00000000009554f1-000559629c4cdb7e.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-0000000000940591-0005595e1811a2d1.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-000000000092b500-00055959f2de5ede.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-0000000000916479-0005595573137b74.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-0000000000901337-00055950d80cc3d8.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-00000000008ec2fb-0005594cad14b07a.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-00000000008d7373-0005594838683e58.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-00000000008c238e-00055943fe2072e3.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-00000000008ad1d9-0005593ff64a4f69.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-0000000000897f32-0005593e18c5758b.journal
journalctl --disk-usage
Archived and active journals take up 1.1G on disk.
Initially we saw:
16733 PATH
5070 SYSCALL
5024 CWD
3765 AVC
323 CRYPTO_KEY_USER
223 USER_START
222 USER_ACCT
222 CRED_ACQ
220 LOGIN
220 CRED_REFR
218 USER_END
218 CRED_DISP
46 USER_LOGIN
12 EXECVE
4 USER_AUTH
2 CRYPTO_SESSION
1 USER_ROLE_CHANGE
1 USER_CMD
1 SERVICE_STOP
1 SERVICE_START
1 BPRM_FCAPS
so we blocked type PATH in audit.rules
But we are still seeing 100K of dropped/suppressed messages.
Note: systemloglevel = INFO
Centos 7 1708 3.10.0-693.2.2.el7.x86_64
systemd.x86_64 219-42.el7_4.1
Now we are required to have full audit rules and does this look like at
rate limiting issue or an issue of journal not able to handle the
traffic to logging?
Error we are seeing from services that have silently failed, in this
case glassfish..
systemctl status -l glassfish
● glassfish.service - SYSV: GlassFish start and stop daemon
Loaded: loaded (/etc/rc.d/init.d/glassfish; bad; vendor preset: disabled)
Active: active (exited) since Tue 2017-09-26 20:01:36 UTC; 5 days ago
Docs: man:systemd-sysv-generator(8)
Process: 1328 ExecStart=/etc/rc.d/init.d/glassfish start (code=exited,
status=0/SUCCESS)
Warning: Journal has been rotated since unit was started. Log output is
incomplete or unavailable.
Eventually glassfish will fail but it wont kill the service so we never
get an nms service down trap from the OID.
Please let me know if further info is needed or if certain limits need
to be adjusted.
Thanks,
Brad Zynda
7 years, 2 months
[PATCH 0/2] lost_reset: alt fix restoring designed behaviour
by Richard Guy Briggs
Provide an alternate fix that restores the designed synchronous
behaviour.
Richard Guy Briggs (2):
Revert "In auditctl, when resetting lost request status output
afterwards"
lost_reset: return value rather than sequence number when zero
ChangeLog | 1 +
lib/libaudit.c | 3 ++-
lib/netlink.c | 28 ++++++++++++++++++++--------
lib/private.h | 1 +
src/auditctl.c | 7 ++++---
5 files changed, 28 insertions(+), 12 deletions(-)
--
1.8.3.1
7 years, 2 months
Pidgin, 4.14 and App Armor Oops.
by Zephaniah E. Loss-Cutler-Hull
Note: I am not subscribed to either list, please try and keep me on the
CC list.
Alright, I am running Ubuntu 16.04, with a 4.14 kernel.
When I start up pidgin, I get the following in dmesg:
[ 73.598446] audit: type=1400 audit(1511239699.316:81):
apparmor="DENIED" operation="file_mmap" profile="/usr/bin/pidgin"
name="/home/warp/.purple/plugins/libfacebook.so" pid=10675 comm="pidgin"
requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
[ 73.598639] audit: type=1400 audit(1511239699.316:82):
apparmor="DENIED" operation="file_mmap" profile="/usr/bin/pidgin"
name="/home/warp/.purple/plugins/libfacebook.so" pid=10675 comm="pidgin"
requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
[ 74.599770] audit: type=1400 audit(1511239700.318:83):
apparmor="DENIED" operation="open" profile="/usr/bin/pidgin"
name="/dev/" pid=10675 comm="pidgin" requested_mask="r" denied_mask="r"
fsuid=1000 ouid=0
[ 74.608247] audit: type=1400 audit(1511239700.326:84):
apparmor="DENIED" operation="file_mmap" profile="gst_plugin_scanner"
name="/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner"
pid=10815 comm="gst-plugin-scan" requested_mask="m" denied_mask="m"
fsuid=1000 ouid=0
[ 74.628037] audit: type=1400 audit(1511239700.346:85):
apparmor="DENIED" operation="open" profile="/usr/bin/pidgin"
name="/dev/" pid=10675 comm="pidgin" requested_mask="r" denied_mask="r"
fsuid=1000 ouid=0
[ 75.754067] audit: type=1400 audit(1511239701.472:86):
apparmor="DENIED" operation="open" profile="/usr/bin/pidgin"
name="/home/warp/.local/share/applications/javaws/" pid=10675
comm="pidgin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[ 75.756574] audit: type=1400 audit(1511239701.475:87):
apparmor="DENIED" operation="open" profile="/usr/bin/pidgin"
name="/usr/local/share/applications/" pid=10675 comm="pidgin"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 75.756803] audit: type=1400 audit(1511239701.475:88):
apparmor="DENIED" operation="open" profile="/usr/bin/pidgin"
name="/usr/local/share/applications/mimeinfo.cache" pid=10675
comm="pidgin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 75.757292] audit: type=1400 audit(1511239701.475:89):
apparmor="DENIED" operation="open" profile="/usr/bin/pidgin"
name="/usr/share/applications/kde4/" pid=10675 comm="pidgin"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 76.178568] BUG: unable to handle kernel paging request at
ffffffff0eee3bc0
[ 76.178579] IP: audit_signal_cb+0x6c/0xe0
[ 76.178581] PGD 1a640a067 P4D 1a640a067 PUD 0
[ 76.178586] Oops: 0000 [#1] PREEMPT SMP
[ 76.178589] Modules linked in: fuse rfcomm bnep usblp uvcvideo btusb
btrtl btbcm btintel bluetooth ecdh_generic ip6table_filter ip6_tables
xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
iptable_filter ip_tables x_tables intel_rapl joydev wmi_bmof serio_raw
iwldvm iwlwifi shpchp kvm_intel kvm irqbypass autofs4 algif_skcipher
nls_iso8859_1 nls_cp437 crc32_pclmul ghash_clmulni_intel
[ 76.178620] CPU: 0 PID: 10675 Comm: pidgin Not tainted
4.14.0-f1-dirty #135
[ 76.178623] Hardware name: Hewlett-Packard HP EliteBook Folio
9470m/18DF, BIOS 68IBD Ver. F.62 10/22/2015
[ 76.178625] task: ffff9c7a94c31dc0 task.stack: ffffa09b02a4c000
[ 76.178628] RIP: 0010:audit_signal_cb+0x6c/0xe0
[ 76.178631] RSP: 0018:ffffa09b02a4fc08 EFLAGS: 00010292
[ 76.178634] RAX: ffffa09b02a4fd60 RBX: ffff9c7aee0741f8 RCX:
0000000000000000
[ 76.178636] RDX: ffffffffee012290 RSI: 0000000000000006 RDI:
ffff9c7a9493d800
[ 76.178638] RBP: ffffa09b02a4fd40 R08: 000000000000004d R09:
ffffa09b02a4fc46
[ 76.178641] R10: ffffa09b02a4fcb8 R11: ffff9c7ab44f5072 R12:
ffffa09b02a4fd40
[ 76.178643] R13: ffffffff9e447be0 R14: ffff9c7a94c31dc0 R15:
0000000000000001
[ 76.178646] FS: 00007f8b11ba2a80(0000) GS:ffff9c7afea00000(0000)
knlGS:0000000000000000
[ 76.178648] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 76.178650] CR2: ffffffff0eee3bc0 CR3: 00000003d5209002 CR4:
00000000001606f0
[ 76.178652] Call Trace:
[ 76.178660] common_lsm_audit+0x1da/0x780
[ 76.178665] ? d_absolute_path+0x60/0x90
[ 76.178669] ? aa_check_perms+0xcd/0xe0
[ 76.178672] aa_check_perms+0xcd/0xe0
[ 76.178675] profile_signal_perm.part.0+0x90/0xa0
[ 76.178679] aa_may_signal+0x16e/0x1b0
[ 76.178686] apparmor_task_kill+0x51/0x120
[ 76.178690] security_task_kill+0x44/0x60
[ 76.178695] group_send_sig_info+0x25/0x60
[ 76.178699] kill_pid_info+0x36/0x60
[ 76.178703] SYSC_kill+0xdb/0x180
[ 76.178707] ? preempt_count_sub+0x92/0xd0
[ 76.178712] ? _raw_write_unlock_irq+0x13/0x30
[ 76.178716] ? task_work_run+0x6a/0x90
[ 76.178720] ? exit_to_usermode_loop+0x80/0xa0
[ 76.178723] entry_SYSCALL_64_fastpath+0x13/0x94
[ 76.178727] RIP: 0033:0x7f8b0e58b767
[ 76.178729] RSP: 002b:00007fff19efd4d8 EFLAGS: 00000206 ORIG_RAX:
000000000000003e
[ 76.178732] RAX: ffffffffffffffda RBX: 0000557f3e3c2050 RCX:
00007f8b0e58b767
[ 76.178735] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
000000000000263b
[ 76.178737] RBP: 0000000000000000 R08: 0000557f3e3c2270 R09:
0000000000000001
[ 76.178739] R10: 000000000000022d R11: 0000000000000206 R12:
0000000000000000
[ 76.178741] R13: 0000000000000001 R14: 0000557f3e3c13c0 R15:
0000000000000000
[ 76.178745] Code: 48 8b 55 18 48 89 df 41 b8 20 00 08 01 5b 5d 48 8b
42 10 48 8b 52 30 48 63 48 4c 48 8b 44 c8 48 31 c9 48 8b 70 38 e9 f4 fd
00 00 <48> 8b 14 d5 40 27 e5 9e 48 c7 c6 7d 07 19 9f 48 89 df e8 fd 35
[ 76.178794] RIP: audit_signal_cb+0x6c/0xe0 RSP: ffffa09b02a4fc08
[ 76.178796] CR2: ffffffff0eee3bc0
[ 76.178799] ---[ end trace 514af9529297f1a3 ]---
And then pidgin ends up as an unkillable zombie.
This seems rather reproducible.
My kernel .config is attached, and I am happy to send along anything
else that might be needed to track this down.
Thank you,
Zephaniah E. Loss-Cutler-Hull.
7 years, 2 months
audit rule problem
by LC Bruzenak
System:
Linux audit 2.6.32-696.3.2.el6.x86_64 #1 SMP Wed Jun 7 11:51:39 EDT 2017
x86_64 x86_64 x86_64 GNU/Linux
userspace audit-2.4.5-3
Red Hat Enterprise Linux Client release 6.9 (Santiago)
I changed this line in /etc/audit/audit.rules from:
-a exit,always -F arch=b64 -S mount -S umount2 -k mount
to this:
-a exit,always -F arch=b64 -S mount -S umount2 -F subj_type!=nothing_t
-k mount
Reloaded my rules, and now doing (as root):
# umount /boot; mount /boot
no longer produces audit events. I did this because on another system
(mls policy, with lots of custom types) I lost the events once I
included some custom types installed and operational on the system, so I
was just trying to reduce this to a reproducible case. I can almost see
that a non-existent type might fail, but it maybe should fail to load.?.
However, the bigger problem is that trying to add my other valid custom
types into the exclusion on the mls policy machine is causing me to lose
events. Any ideas?
Thx,
LCB
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
7 years, 2 months
Strange behavior with pam_tty_audit
by Maupertuis Philippe
Hi
The auditd rules for PCI reads :
## 10.2.2 Log administrative action. To meet this, you need to enable tty
## logging. The pam config below should be placed into su and sudo pam stacks.
## session required pam_tty_audit.so disable=* enable=root
I have noticed that nothing happened unless I add in /etc/pam.d/sshd
session required pam_tty_audit.so enable=*
At which point I get
Should it be done that way ?
Did I miss something ?
Philippe
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
7 years, 2 months
Problem with syntax?
by warron.french
Steve, can you help me with this please?
Somehow this slipped past our QA process, but I have an error popping up in
*/var/log/boot.log* indicating:
*28* Starting auditd: ^[[60G[^[[0;32m OK ^[[0;39m]^M
* 29* Error sending add rule data request (Rule exists)
*30 *There was an error in line 65 of /etc/audit/audit.rules
Lines 28-30 are the only range of line numbers indicating a problem in the
boot.log.
I will post a copy of the /etc/audit/audit.rules (for my RHEL6 system)
below (with line numbers included for navigation):
1 # This file managed by puppet module: osconfig_eita_mgmt
2 # DO NOT ALTER outside of the Puppet Framework.
3 #
4 #
5 # First rule - delete all
6 -D
7 # Increase the buffers to survive stress events.
8 # Make this bigger for busy systems
9 -b 8192
10 # PANIC on audit failure
11 -f 2
12 #
13 # ACTION (-a) Rules
14 # Filters out noisy cron related messages
15 -a never,user -F subj_type=crond_t
16 #
17 -a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -k
time-change
18 -a always,exit -F arch=b32 -S adjtimex -S stime -S settimeofday -S
clock_settime -k audit_time_rules
19 -a always,exit -F arch=b32 -S chmod -F auid=0 -k perm_mod
20 -a always,exit -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 -k
perm_mod
21 -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid=0 -k
perm_mod
22 -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=500
-F auid!=4294967295 -k perm_mod
23 -a always,exit -F arch=b32 -S chown -F auid=0 -k perm_mod
24 -a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 -k
perm_mod
25 -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F
auid=0 -k perm_mod
26 -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F
auid>=500 -F auid!=4294967295 -k perm_mod
27 -a always,exit -F arch=b32 -S clock_settime -k time-change
28 -a always,exit -F arch=b32 -S creat -S open -S openat -S
open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 -F
auid!=4294967295 -k access
29 -a always,exit -F arch=b32 -S creat -S open -S openat -S
open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500 -F
auid!=4294967295 -k access
30 -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate -S
ftruncate -F exit=-EACCES -F auid=0 -k access
31 -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate -S
ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access
32 -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate -S
ftruncate -F exit=-EPERM -F auid=0 -k access
33 -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate -S
ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access
34 -a always,exit -F arch=b32 -S fchmodat -F auid=0 -k perm_mod
35 -a always,exit -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295
-k perm_mod
36 -a always,exit -F arch=b32 -S fchmod -F auid=0 -k perm_mod
37 -a always,exit -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295
-k perm_mod
38 -a always,exit -F arch=b32 -S fchownat -F auid=0 -k perm_mod
39 -a always,exit -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295
-k perm_mod
40 -a always,exit -F arch=b32 -S fchown -F auid=0 -k perm_mod
41 -a always,exit -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295
-k perm_mod
42 -a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod
43 -a always,exit -F arch=b32 -S fremovexattr -F auid>=500 -F
auid!=4294967295 -k perm_mod
44 -a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod
45 -a always,exit -F arch=b32 -S fsetxattr -F auid>=500 -F
auid!=4294967295 -k perm_mod
46 -a always,exit -F arch=b32 -S init_module -S delete_module -k modules
47 -a always,exit -F arch=b32 -S lchown -F auid=0 -k perm_mod
48 -a always,exit -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295
-k perm_mod
49 -a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod
50 -a always,exit -F arch=b32 -S lremovexattr -F auid>=500 -F
auid!=4294967295 -k perm_mod
51 -a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod
52 -a always,exit -F arch=b32 -S lsetxattr -F auid>=500 -F
auid!=4294967295 -k perm_mod
53 -a always,exit -F arch=b32 -S mount -F auid=0 -k export
54 -a always,exit -F arch=b32 -S mount -F auid>=500 -F auid!=4294967295 -k
export
55 -a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod
56 -a always,exit -F arch=b32 -S removexattr -F auid>=500 -F
auid!=4294967295 -k perm_mod
57 -a always,exit -F arch=b32 -S rmdir -S unlink -S unlinkat -S rename -S
renameat -F auid=0 -k delete
58 -a always,exit -F arch=b32 -S rmdir -S unlink -S unlinkat -S rename -S
renameat -F auid>=500 -F auid!=4294967295 -k delete
59 -a always,exit -F arch=b32 -S sethostname -S setdomainname -k
audit_network_modifications
60 -a always,exit -F arch=b32 -S sethostname -S setdomainname -k
system-locale
61 -a always,exit -F arch=b32 -S setxattr -F auid=0 -k perm_mod
62 -a always,exit -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295
-k perm_mod
63 -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S
removexattr -S lremovexattr -S fremovexattr -F auid=0 -k perm_mod
64 -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S
removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F
auid!=4294967295 -k perm_mod
65 -a always,exit -F arch=b32 -S unlink -S rmdir -S unlinkat -S rename -S
renameat -F auid>=500 -F auid!=4294967295 -k delete
I noticed that lines 58 and 65 seem to be "duplicates" although the syntax
has some elements swapped.
So, what I don't understand is why is line #58 OK, if line #65 is not? Are
lines of "duplicate syntax" not legal?
Thanks in advance,
--------------------------
Warron French
7 years, 2 months
