4:39 a.m.
All,
I am looking a ways to counter the situation where a user restarts a
service and hence all that service's auditing events are attributed to
the auid of the user who performed the restart.
That is
a. User logs into system (and pam sets auid)
b. User su's or sudo's up to a service account (auid still the same).
c. User restarts the service
d. All audit events resulting from the service have the user's auid.
At present I am looking at solution that front-end's the
RHEL5/RHEL6 /sbin/service command which sets the auid via a
audit_setloginuid() call and then execv's the service script and command
arguments.
I am interested in any other solutions that people may have implemented
successfully. Especially for the systemd replacement, if it's been done.
Regards
Burn
10:53 a.m.
On 06/09/2014 04:39 AM, Burn Alting wrote:
All,
I am looking a ways to counter the situation where a user restarts a
service and hence all that service's auditing events are attributed to
the auid of the user who performed the restart.
That is
a. User logs into system (and pam sets auid)
b. User su's or sudo's up to a service account (auid still the same).
c. User restarts the service
d. All audit events resulting from the service have the user's auid.
At present I am looking at solution that front-end's the
RHEL5/RHEL6 /sbin/service command which sets the auid via a
audit_setloginuid() call and then execv's the service script and command
arguments.
I am interested in any other solutions that people may have implemented
successfully. Especially for the systemd replacement, if it's been done.
Regards
Burn
Like run_init does (in the policy_coreutils rpm)?
LCB
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
3:07 p.m.
Thanks Lenny,
Do I need to be running selinux in enforcing mode or would permissive
work?
I will do some research - I am 100% brand new to selinux.
Rgds
Burn
On Mon, 2014-06-09 at 10:53 -0500, LC Bruzenak wrote:
On 06/09/2014 04:39 AM, Burn Alting wrote:
> All,
>
> I am looking a ways to counter the situation where a user restarts a
> service and hence all that service's auditing events are attributed to
> the auid of the user who performed the restart.
>
> That is
>
> a. User logs into system (and pam sets auid)
> b. User su's or sudo's up to a service account (auid still the same).
> c. User restarts the service
> d. All audit events resulting from the service have the user's auid.
>
> At present I am looking at solution that front-end's the
> RHEL5/RHEL6 /sbin/service command which sets the auid via a
> audit_setloginuid() call and then execv's the service script and command
> arguments.
>
> I am interested in any other solutions that people may have implemented
> successfully. Especially for the systemd replacement, if it's been done.
>
> Regards
>
> Burn
>
>
Like run_init does (in the policy_coreutils rpm)?
LCB
3:17 p.m.
On Monday, June 09, 2014 07:39:26 PM Burn Alting wrote:
I am looking a ways to counter the situation where a user restarts a
service and hence all that service's auditing events are attributed to
the auid of the user who performed the restart.
That is
a. User logs into system (and pam sets auid)
b. User su's or sudo's up to a service account (auid still the same).
c. User restarts the service
d. All audit events resulting from the service have the user's auid.
At present I am looking at solution that front-end's the
RHEL5/RHEL6 /sbin/service command which sets the auid via a
audit_setloginuid() call and then execv's the service script and command
arguments.
I am interested in any other solutions that people may have implemented
successfully. Especially for the systemd replacement, if it's been done.
On older sysvinit systems, you could also plumb upstart to do service starts
via its dbus/socket kind of the same way telinit communicates with it. I think
upstream made this work a long time ago. Stopping a service should be left as
is.
-Steve
3849
days inactive
3849
days old
linux-audit@lists.linux-audit.osci.io
3 comments
3 participants
participants (3)
-
Burn Alting -
LC Bruzenak -
Steve Grubb