* One challenge for audit - seeking ideas
@ 2014-06-09 9:39 Burn Alting
2014-06-09 15:53 ` LC Bruzenak
2014-06-09 20:17 ` Steve Grubb
0 siblings, 2 replies; 4+ messages in thread
From: Burn Alting @ 2014-06-09 9:39 UTC (permalink / raw)
To: linux audit
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: One challenge for audit - seeking ideas
2014-06-09 9:39 One challenge for audit - seeking ideas Burn Alting
@ 2014-06-09 15:53 ` LC Bruzenak
2014-06-09 20:07 ` Burn Alting
2014-06-09 20:17 ` Steve Grubb
1 sibling, 1 reply; 4+ messages in thread
From: LC Bruzenak @ 2014-06-09 15:53 UTC (permalink / raw)
To: linux-audit
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@magitekltd.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: One challenge for audit - seeking ideas
2014-06-09 15:53 ` LC Bruzenak
@ 2014-06-09 20:07 ` Burn Alting
0 siblings, 0 replies; 4+ messages in thread
From: Burn Alting @ 2014-06-09 20:07 UTC (permalink / raw)
To: LC Bruzenak; +Cc: linux-audit
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
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: One challenge for audit - seeking ideas
2014-06-09 9:39 One challenge for audit - seeking ideas Burn Alting
2014-06-09 15:53 ` LC Bruzenak
@ 2014-06-09 20:17 ` Steve Grubb
1 sibling, 0 replies; 4+ messages in thread
From: Steve Grubb @ 2014-06-09 20:17 UTC (permalink / raw)
To: linux-audit, burn
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-06-09 20:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-09 9:39 One challenge for audit - seeking ideas Burn Alting
2014-06-09 15:53 ` LC Bruzenak
2014-06-09 20:07 ` Burn Alting
2014-06-09 20:17 ` Steve Grubb
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.