Looking for suggestions for a poor man's powerbroker

[Mel Burslan]

SOX audits are upon us and accountability is the peak of worries for the sysadmins in my organization. We were asked by management not to use

sudo su -

command but use every each command with a sudo prefix to it when we need to run it as root. Considering we are spending a very good part of 8 hours every day, typing these commands, it is a big inconvenience if not more detrimental to adapt this sudo prefixing the commands.

I know powerbroker can log whatever you typed or passes through the screen buffer to a file located on a remote server. We have suggested use of this utility but it looks like it will only be licensed for the critical (i.e. financial information bearing) servers due to the licensing costs. Yet, we are still expected to be accountable via sudo prefixing on all servers in our landscape.

My question is, can there be a way to tell sudo to create a subshell where the screen and keyboard buffers will be captured and sent to a different server on the network ? This could be by recompling sudo or using another similar, license free (or very close to free) utility.

Has anyone implement something similar ?

Thanks for all the input.

[MarkSyder]

I've never actually tried this, so it may not work, but have you tried aliases for you most frequently used commands? E.g. alias cd=`sudo cd`.

Alternatively, you could reduce your typing with s as an alias for sudo.

Mark Syder (like the drink but spelt different)

[Court Campbell]

In our environment we have the sudo entries going to a separeate sudo log and then we copy the logs to a remote server via cron. I hardly ever use sudo su -, sudo -i, or sudo -s. One way to get around having to type sudo is via aliases. I would say that you could add "!sudo su -" to your sudoers but there may be occasions when this would be more convenient. But if you know roots password you can always just "su -". Hopefully I have given you some ideas.

[Steven E. Protter]

Shalom,

I think alias will possibly work.

So for SOX purposes root login is being forbidden altogether?

We are under SOX here (US ownership) and we don't have such a restriction.

We're a security company. We secure content for delivery to consumers from content producers (tv, movies).

SEP

[Mel Burslan]

Thanks for the answers so far.

We have thought of aliasing commands but creating alias for every each obscure command that one uses daily is simply not feasible. Solution should be transparent.

And the answer to if root login is prohibited. The answer is yes and no, as expected. Root password is a random string of 30+ characters, changed monthly by one of the sysadmins and kept in 3 locations in a safe in a sealed envelope and direct root login is only allowed through the console as any sane sysadmin does. On the other hand, people like me, who have sysadmin group privileges are able to access a root shell via

sudo su -

but the caveat is, once you are in the root shell using this command, there is no way that auditors can tell what commands you have executed. And since there are more than one person with this level of access privileges, if 2 people were using root shell at the same time (by the way limiting number of admin user logins is not an option) and something bad happens to the system, the question of "who to blame ?" turns into a finger pointing match. This has never happened but at least, this is the mentality why we need this accountability. Also, using powerbroker in the past saved my rear end more than once, by checking the pb.log files on the master server to figure out what went wrong. But again pb is way too expensive to deploy on all our servers.

What I am looking for by the way of sudo is:

1. user issues "sudo su -" command and gets authorized
2. sudo spawns a subshell with logging enabled as in "script" command"
3. output of the script command goes to a remote server

this approach above is one way I can envision this could be done, although quite hard.

second way I see this happen:

1. user issues "sudo su -" command and gets authorized
2. sudo allows every command typed, to go to syslog, not only failures and errors. This could even be configured by syslog.conf file but I have not investigated this option.
3. by means of syslog.conf, server sends the logs to a remote server simultaneously.
4. on remote server, a perl or similar script can be utilized to skim out the sudo directives out of the whole syslog file.

On this approach, I see a need for recompilation os sudo binaries but not being a programmer myself, I am not even sure if this mechanism can be built into the application.

Again thanks for all the responses in advance.

[Court Campbell]

Mel,

Fortunately our SOX controls are more lenient in this reguard. But I did add this to root's profile because I got tired of trying to figure out who was doing what. Granted this isn't fool proof, but it may spark some other ideas:

# Setup history file

WHOAMI=$(who am i | awk '{print $1}')
touch ~/.${WHOAMI}_sh_history
HISTFILE=~/.${WHOAMI}_sh_history
export HISTFILE
echo "# Open: $(date)\n\0000\c" >> $HISTFILE

This creates a separate history for each user but it can be circumvented as you know.

[Patrick Wallek]

I'm not sure what you want can be done easily just via sudo.

What if you were to add something like:

/usr/bin/script root.$(date +%m%d%y).$(date +%H%M%S)

to root's .profile? That would then record everything root does. You could have a log directory that the logs are kept it.

Caveats: 1) Being root, you could turn off the script command ; 2) Being root you could potentially blow away the script log, or the entire log directory ; 3) I honestly hate the SOX audits because they have the mentality of guilty until proven innocent and cause management not to trust their administrators.

[Duncan Edmonstone]

Mel,

Sounds like you need sudosh:

http://sourceforge.net/projects/sudosh/

Never tried it myself, but seems pretty close to what you're looking for - not sure whether it is still a maintained product as can't see much action on it in the last 3 years but...

Without looking at what it does, make sure it won't end up screwing up single-user mode!

Looking in the notes is appears people have got it to compile on HP-UX.

HTH

Duncan

[Court Campbell]

Sorry to go off topic, but Patrick is right on the money. I once told a manager that if he couldn't trust me, he needed to fire me right there on the spot.

[Court Campbell]

Duncan -- that is sweet. I just compiled it on a test box and it really cool. I think I am going install it on all our prod boxes after I use it a little more. The replay functionality is really cool.

[Heironimus]

The original sudosh is dead and unmaintained. At one point the author said it had some fundamental design problems that he wasn't going to fix because he was writing a total replacement.

That replacement was EAS, which did fix a lot of the problems and offered more advanced features (like logging to a central server). That's what I use today for all of our application accounts. However, it was sold to some company shortly after release and by an amazing coincidence almost every trace of the free open source version promptly vanished from the web.

Now there's a sudosh2, which is an attempt to resurrect the open source stuff. That's where I'd look if I had to start from scratch today.

[Andres_13]

Heironimus

Could you post or share EAS software? Is it possible? I want test it...

Regards

[Mel Burslan]

Duncan & Heironimus,

Thanks for this information. Do you have a link where the original sudosh author says about the problems of his software as well as name of the company acquired the EAS software package ?

Depending on what the deficiencies in the original sudosh, I might still consider it, or if the company acquiring the EAS package is charging a more reasonable licensing costs, I might consider that one as well. I hope it was not Symark who acquired EAS to eliminate the competititon.

Any further info would be invaluable.

Thanks.

[Heironimus]

Copies of EAS are still around, but it looks like all of the stuff on sourceforge for EAS is gone. I found this link by doing a google search on the exact filename.

http://www.sfr-fresh.com/unix/privat/eas-2.0.00.tar.gz

I think I originally saw the comments about design problems in sudosh on the sourceforge mailing list or forum. Unfortunately, both seem to be gone now. I don't know if they're gone because the author took them down or if they were a victim of sourceforge's interface redesign.

The information on somebody buying EAS is secondhand and I don't know the name of the company. One of my colleagues saw them at a trade show a year or two ago. They were apparently quite proud of the fact that they had rewritten most of the code and converted it to rely on MS SQL Server for audit log storage. That second point was a total dealbreaker in our environment (not that we were really looking to spend money).

[VK2COT]

Hello,

Others already gave some good pointers.

I actually wrote a Knowledge Brief on
using SUDO and SUDOSH on Solaris,
Linux and HP-UX. I did some
projects for customers with them.
They work nicely.

However, if you want to move into then 21st
century maybe you should start looking at
things like Role based Access Control
(RBAC) on HP-UX. I teach various Unix courses
and I am trying to show
students how powerful and useful RBAC
is (native to Solaris, ported to Linux,
and works on newer HP-UX releases).

Basically, you set up roles, add commands
to roles, and then assign users to roles.
Voila.

Cheers,

VK2COT