9:36 a.m.
So I understand the SERVICE_START/STOP are sent by systemd. We do have a
unit file for systemd as following:
[Unit]
Description=......
[Service]
Type=forking
WorkingDirectory=/var/lib/....
PIDFile=/var/run/xxxx.pid
ExecStart=/usr/sbin/xxxx
Restart=always
# Wait a bit before restarting xxx
RestartSec=5s
# xxxx kicks the watchdog
WatchdogSec=60
# If xxxx doesn't signal that it's ready, consider it failed
TimeoutStartSec=300
# Time between SIGTERM and SIGKILL on shutdown
TimeoutStopSec=20
# Allows calls to sd_notify from main process
NotifyAccess=main
StandardInput=null
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Would this trigger the creation of the audit record? Our application is
expected to be up and running all the time. But we can shut it down, or
it could be down due to error. We want audit record when it is down.
Would TimeoutStopSec= tag (don't know if this is the proper name)
does it, or I need other special tag?
Thanks.
Gisela Cheng
giselac(a)us.ibm.com
----- Forwarded by Gisela Cheng/Poughkeepsie/IBM on 08/05/2014 09:24 AM
-----
From: Steve Grubb <sgrubb(a)redhat.com>
To: linux-audit(a)redhat.com
Cc: Gisela Cheng/Poughkeepsie/IBM@IBMUS
Date: 08/04/2014 04:34 PM
Subject: Re: How to define rule for SERVICE_START/STOP?
On Monday, August 04, 2014 03:16:18 PM Gisela Cheng wrote:
We want to use Linux audit type SERVICE_START/STOP for our
application
running as service.
But I am not able to find example on how to use auditctl to define the
rule. It seems to me that all the examples are of rules defined for
system_calls.
There are 2 kinds of events. Some are hardwired into the applications (or
kernel) and they send them if auditing is enabled. The other kind are
discretionary in that the admin defines what to audit. The problem with
the
discretionary rules are that it is from the kernel's point of view.
Meaning
that you only get events as the process transitions through something the
kernel controls like files or syscalls.
Questions:
1. Can I use audit type SERVICE_START/STOP for my application runs as
service?
The SERVICE_START/STOP command are intended to be sent by the init daemon.
Systemd already sends these. Upstart could be patched, but if that is done
it
would need to match the layout, order, and formatting of the systemd
events.
or would it be considered as type USR_CMD?
USER_CMD is for something like sudo to record what command the user will
be
running.
2. How do I use auditctl to define rule for SERVICE_START/STOP?
Can
you
direct/point me to URL/documentation where it is documented?
It can't define these events because the kernel only sees a process start
or
stop. It has no idea that its a service. Only init can tell the
difference.
-Steve
11:48 a.m.
On Tuesday, August 05, 2014 10:36:17 AM Gisela Cheng wrote:
Would this trigger the creation of the audit record?
I don't think anything in the config file would affect this. The requirements are
to record all starts and stops. I don't think it can record a segfault kind of
stop. That would, however, generate an ANOM_ABEND event.
Our application is expected to be up and running all the time. But
we can
shut it down, or it could be down due to error. We want audit record when
it is down. Would TimeoutStopSec= tag (don't know if this is the proper
name) does it, or I need other special tag?
No tag should affect this.
-Steve
7:57 a.m.
On Tue, 2014-08-05 at 12:48 -0400, Steve Grubb wrote:
On Tuesday, August 05, 2014 10:36:17 AM Gisela Cheng wrote:
> Would this trigger the creation of the audit record?
I don't think anything in the config file would affect this. The requirements are
to record all starts and stops. I don't think it can record a segfault kind of
stop. That would, however, generate an ANOM_ABEND event.
All stops of a non-forking daemon will be properly tracked with a stop
event (including segfault). systemd doesn't just start processes and
forget about them. It isn't sysv. We don't live in the stone ages any
more :)
For forking services (like yours) it gets it right most of the time,
especially since you told it the pid file, but I understand it isn't
perfect. sendmail is a forking service if you kill -SIGV $SENDMAIL_PID
you will get something like:
type=ANOM_ABEND msg=audit(1407329684.562:419): auid=4294967295 uid=0 gid=0 ses=4294967295
subj=system_u:system_r:sendmail_t:s0 pid=1114 comm="sendmail"
exe="/usr/sbin/sendmail.sendmail" sig=11
type=SERVICE_STOP msg=audit(1407329684.570:420): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="sendmail"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Aka, Steve is right and you are right.
3739
days inactive
3740
days old
linux-audit@lists.linux-audit.osci.io
2 comments
3 participants
participants (3)
-
Eric Paris -
Gisela Cheng -
Steve Grubb