3 ms·

Right.. The moment you allow Slack/Hipchat to vouch for your identity, you've effectively delegated control of your infrastructure -- an attack on Slack/Hipchat

by subway 10y ago

Right.. The moment you allow Slack/Hipchat to vouch for your identity, you've effectively delegated control of your infrastructure -- an attack on Slack/Hipchat becomes a vector into your infrastructure.

ownagefool 10y ago
This is crazy, but the pattern isn't terrible if you replace slack with your selfhosted irc / chat server.
- sytse 10y ago
  At GitLab we think that when you are self hosted there should still be role based access control. We selected Cog as our chatops framework for that reason https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1412 https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1412 It has fine-grained command permissions, users/groups/roles, and audit logging. Besides ensuring that users are restricted it is also important that a bug in a script can't do too much damage. Where Hubot runs every script in the same namespace Cog has separated the coordinator and the scripts. They use containers to do this so you can write scripts in other languages than javascript. Apart from that Cog as pretty sweet unix like piping between commands.
- deleted 10y ago
  [deleted]
sciurus 10y ago
With what jzelinskie has described the program actually running the commands could do auth in a number of ways, including ones that completely avoid the chat system.
- subway 10y ago
  Sure, in theory, but I've struggled to find a single example of such an implementation. It seems like you either have to delegate authN to your chat service, with authZ handled by hubot-auth, or find a way to get your chat client to pass a token along with every chatops request.
voltagex_ 10y ago
If you could bind a Slack identity to LDAP, would that fix it? I've never really thought of Slack as a security threat directly, but you're correct. If you trust voltagex@slack to act on behalf of voltagex@internal.domain, you've just crossed a security boundaries with no checks whatsoever (does Hubot et-al have audit logging?)

by subway 10y ago

ownagefool 10y ago

This is crazy, but the pattern isn't terrible if you replace slack with your selfhosted irc / chat server.

sytse 10y ago
At GitLab we think that when you are self hosted there should still be role based access control. We selected Cog as our chatops framework for that reason https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1412 https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1412 It has fine-grained command permissions, users/groups/roles, and audit logging. Besides ensuring that users are restricted it is also important that a bug in a script can't do too much damage. Where Hubot runs every script in the same namespace Cog has separated the coordinator and the scripts. They use containers to do this so you can write scripts in other languages than javascript. Apart from that Cog as pretty sweet unix like piping between commands.
deleted 10y ago
[deleted]

sciurus 10y ago

With what jzelinskie has described the program actually running the commands could do auth in a number of ways, including ones that completely avoid the chat system.

subway 10y ago
Sure, in theory, but I've struggled to find a single example of such an implementation. It seems like you either have to delegate authN to your chat service, with authZ handled by hubot-auth, or find a way to get your chat client to pass a token along with every chatops request.

voltagex_ 10y ago

If you could bind a Slack identity to LDAP, would that fix it? I've never really thought of Slack as a security threat directly, but you're correct. If you trust voltagex@slack to act on behalf of voltagex@internal.domain, you've just crossed a security boundaries with no checks whatsoever (does Hubot et-al have audit logging?)