View Single Post
Old 02-09-2007, 05:53 PM   #4
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,462
Blog Entries: 54

Rep: Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899
OK, so you got hit by the SOX section 404 thing, right? Bummer...

First thing I would suggest is look around for SOX toolkits to help you achieve compliance. Make sure you know *exactly* what you need to do (and do share that information if you care).

Second thing I'd suggest is figuring out the impact of damage a user can do. Not so much wrt the system but wrt to the data (verification, retention). You probably have to provide proof showing you can test and maintain integrity. Then figure out impact of damage on the system. If it's untolerable and 0) the box already runs SELinux and 1) the box runs only that application (meaning it's not Swiss cheese application or daemon-wise) you could decide to run the "strict" SELinux policy. That isn't a decision you can turn a knob for (writing and testing iterations) but you have a real assurance nobody, including root, can do more damage than those rules allow for. Note there's one thing more fascist than "strict" and that's MLS. It's more geared towards those that work with (near-) EAL/CAPP grade systems. You don't need that. If you would, you'd already know ;-p


Wrt accountability wrt your questions there's two ways IMHO:
- either you allow shell access so users can choose to run the application or you
- replace the shell with a wrapper that execs the application.
Personally I would choose for execing because then (unless the application itself allows for users to exec a subprocess) the user has no foothold on the system and access is gone when the application exits.
If for some obscure reason you are bound to provide shell access then you (next to what PAM already governs)
- need to run a login shell that allows for logging like rootsh (or sudosh),
- configure the shell to log to syslog *and*
- syslog to a remote syslog server to assure you have untaintable logs.
Rootsh can also log to separate session files but I guess that isn't a scalable solution if you are going to scale up. Running SELinux with the "strict" policy also means users will be bound by specific rules governing what resources they are allowed to access. Since access means really *everything* this covers writes as well.
Wrt alerting I think email is the worst thing to do if you're gonna shepard multiple servers. Instead you should use something like a central management station that polls resources like the syslog server. Note this all kind of hinges on you being able to implement SELinux with the "strict" policy. If you can't do that all isn't lost but to stand a chance I'd exhaust all methods of warfare at your disposal before looking at other options...

HTH

Last edited by unSpawn; 02-09-2007 at 05:54 PM.