Dropping auid for daemons started via sudo

Dropping auid for daemons started via sudo

[Konstantin Ryabitsev]

Hello:

I'm dealing with a set of machines with unrestricted sudo for admins
("sudo -s"). It's not something I can immediately change (though I'm
working toward a more restrictive attitude and policy). I'm trying to
at least do some auditing via the following audit rule:

-a always,exit -F arch=b32 -S execve -F uid=0 -F auid>=500 -F
auid!=4294967295 -k privileged
-a always,exit -F arch=b64 -S execve -F uid=0 -F auid>=500 -F
auid!=4294967295 -k privileged

It mostly does the right thing, except for cases when an admin logs in
and restarts a service. If it's running a privileged process, that
process will have an auid of the user that last ran "service foo
restart".

Is there a way to drop auid for services restarted by individual
admins? I'm not sure if run_init does it, but I can't use it anyway
because selinux is disabled on those machines.

Thanks for any advice.

Regards,
-- 
McGill University IT Security
Konstantin "Kay" Ryabitsev
Montréal, Québec

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Dropping auid for daemons started via sudo

[Steve Grubb]

On Monday 17 May 2010 09:32:15 am Konstantin Ryabitsev wrote:
> It mostly does the right thing, except for cases when an admin logs in
> and restarts a service. If it's running a privileged process, that
> process will have an auid of the user that last ran "service foo
> restart".

Yep.

 
> Is there a way to drop auid for services restarted by individual
> admins?

No, because that would allow the audit system to be attacked so that it 
misrepresents who actually did something. This would be on the short list of 
things to do like cleaning up logs after successfully compromising a system.


> I'm not sure if run_init does it, but I can't use it anyway
> because selinux is disabled on those machines.

What I would really like to see is daemons not being started directly. Meaning 
that when you run "service httpd restart", this would tell init to restart 
httpd so that httpd does not inherit anything in the admin's environment. This 
would clean up SE Linux rules a bit too since there wouldn't be a need to 
transition from the admin's context to the daemon's. The path would always be 
admin->init->daemon. Of course starting up a service in this way should be an 
auditable event, too.


> Thanks for any advice.

No so much advice as just an understanding of why its this way. I won't have  
time to look into upstart any time soon, but it would be nice if someone else 
did some digging into this and perhaps even fix it for everyone.

-Steve