sudo, sudosh, and pssh

[Samuel Vange]

I'm trying to plan privileges and roles for users and admins on my system. I'd like to use sudosh to log super-user interactions with the system, but I'd also like to give admins the ability to use pssh (to allow sysadmins the ability to run a command on a set of machines).

If I give sysadmins only super user access to sudosh, then pssh is limited to commands that don't require super user privilege (because as far as I can tell, sudosh is interactive-only; there is no ability to do "sudosh command -flags"), and 

If I give sysadmins the ability to pssh and grant them super-user access to commands other than sudosh, then they can circumvent using sudosh alltogether. 

[it looks like this can be mitigated by forcing sudo to log successful command execution]

I also noticed that running "sudo sudosh -n" is an option to bypass logging a root session to syslog.

Is there a recommended way to be setup groups so that logging is always enforced (no sudosh -n), and so that pssh and sudosh work harmoniously?

Thanks you.

[Nicholas Hughes]

Samuel,

I had a similar problem, in that I wanted to have administrators be able to run remote commands on a large number of servers at once. In large clusters, interactive sessions are not practical. I solved that in my environment by deploying SaltStack [1]. While SaltStack allows for some similar functionality to Puppet by creating "formulas" (Salt-speak for Puppet modules) that perform software installation and configuration, system changes, etc... I'm only using it for it's ability to provide a remote execution mechanism [2]. This allows me to escalate to root on the Salt master with sudosh, and then run remote commands on all (or a subset) of my systems at once. I even found a Salt module for Puppet which made it super easy to roll out to my deployed SIMP systems [3]. I'm not sure if this would solve your problem, or if you need to use PSSH specifically.

That's an interesting find regarding the sudosh logging bypass... I wasn't aware that was possible.

-Nick

[1] - https://saltstack.com/
[2] - https://saltstack.com/remote-execution/
[3] - https://github.com/maxchk/puppet-salt

--
You received this message because you are subscribed to the Google Groups "SIMP Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simp-users+unsubscribe@googlegroups.com.
To post to this group, send email to simp-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/simp-users/ceb5ba5b-4ae0-4601-96cf-4e90119b3abd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Trevor Vaughan]

Sorry for the late follow up.

Honestly, your best bet would be to add entries to your sudoers file that allow your users to execute the commands required and not pass through sudosh for those commands.

Obviously, this only works if you know what commands they wish to run. Otherwise, you end up with arbitrary execution which is also fine if that's what you want.

Alternatively, Salt is certainly a practical solution to the issue but does suffer from the ability to audit commands run if you have multiple users executing in parallel (basically, you end up with an open root shell).

We actually include an MCollective module for this capability but I will freely admit that (at this time) MCO is not as user friendly.

I do think that the Choria updates that RI is working on are going to make a HUGE difference in usability.

We chose MCO both for the auditability of the platform as well as the ability to scale to large numbers of distributed hosts.

In terms of sudosh2, we're closely monitoring the progress of tlog (https://www.mankier.com/package/tlog) and will be replacing sudosh with tlog when it is ready.

To view this discussion on the web visit https://groups.google.com/d/msgid/simp-users/CALL24LXYwu7D3S_PwydS6nazYiFzr4QOAAi89sZHmd38rf%2BARg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Trevor Vaughan
Vice President, Onyx Point, Inc

(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --

[Samuel Vange]

Thanks! I don't expect that this will be a problem for us. Recorded root sessions are more of a nice-to-have than a necessity. Instead, we will likely enumerate the privileged commands we need and have sudo log successes and failures for roles we want to monitor. Concurrently, we'll start looking into saltstack so that we have some options. Thanks Nick!

On Thursday, February 9, 2017 at 6:50:00 PM UTC-8, Trevor Vaughan wrote:

Sorry for the late follow up.

Honestly, your best bet would be to add entries to your sudoers file that allow your users to execute the commands required and not pass through sudosh for those commands.

Obviously, this only works if you know what commands they wish to run. Otherwise, you end up with arbitrary execution which is also fine if that's what you want.

Alternatively, Salt is certainly a practical solution to the issue but does suffer from the ability to audit commands run if you have multiple users executing in parallel (basically, you end up with an open root shell).

We actually include an MCollective module for this capability but I will freely admit that (at this time) MCO is not as user friendly.

I do think that the Choria updates that RI is working on are going to make a HUGE difference in usability.

We chose MCO both for the auditability of the platform as well as the ability to scale to large numbers of distributed hosts.

In terms of sudosh2, we're closely monitoring the progress of tlog (https://www.mankier.com/package/tlog) and will be replacing sudosh with tlog when it is ready.