"John" == John Malloy <jomalloy@gmail.com> writes:
John> They just want to know who can login as route or sudo And so do you! :-) John> These are both Oracle servers and they only have a route and Oracle account That you know of. Auditing, while painful and not fun unless it's automated, is the solution here. John> There’s no additional users in the Sudo file It's not that easy, since you also need to look in /etc/sudoers.d/ and also need to parse out group membership and check the sudoers* files for group entries. It's *not* trivial. But again, it's the auditing part that the auditors will be concerned about. How to do validate your results? How do you know that us powerful sysadmins aren't hacking the reports and ignoring certain accounts in the reports so that we can hide stuff? How do you know someone *else* hasn't hidden a SUID script or program somewhere else on the system? It's a damn rathole honestly, and there's a cost vs benefit call you need to make. Or more accurately, management needs to make. 100% security is when the server is off, unplugged from everything and buried in a hole. In concrete. :-) Be thankful you're not having to go through PCI compliance audits for handling credit cards, I've heard they're even worse! John John> On Fri, Apr 17, 2020 at 1:39 PM Dan Ritter <dsr@randomstring.org> wrote: John> John Malloy wrote:
What is the best way to provide proof to an audit person who needs to know all the root/sudo users for a RHEL 6 server?
(I am new at this company, and don't have access to all their resources)
We can provide the /etc/passwd & /etc/sudoers file (the auditor may not know how to read these files)
We also have the RedHat Identity Management running here, but I am not familiar with this tool.
John> What question did they ask? It's important. John> -dsr- John> -- John> John Malloy John> _______________________________________________ John> bblisa mailing list John> bblisa@bblisa.org John> http://www.bblisa.org/mailman/listinfo/bblisa