One challenge for audit - seeking ideas

One challenge for audit - seeking ideas

[Burn Alting]

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

Re: One challenge for audit - seeking ideas

[LC Bruzenak]

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

Re: One challenge for audit - seeking ideas

[Burn Alting]

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
> 

Re: One challenge for audit - seeking ideas

[Steve Grubb]

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