Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-24902

Jenkins's security is not applied for IM user

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Critical
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      Jenkins 1.581
      instant-messaging plugin 1.30
    • Similar Issues:

      Description

      In Global authorization matrix (https://ci.gfi.fr/jenkins/configureSecurity/), the "Authorization" option is "Project-based Matrix Authorization Strategy" :
      "jenkins-im" user has all authorizations, and is the one I've mapped to "Jenkins Username" parameter of "instant-messaging plugin"

      I have a user will no right at all in Jenkins but allowed to connect to the conference used by "jenkins-im".

      This user can send any bot commands and this is really weird. The same is true for a registered jenkins user having only read/view rights. If he can only see builds using the Web/REST/CLI interfaces, this plugin acts like a "sudo".

      "Jenkins Username" parameter of "instant-messaging plugin" should be removed or merged with the rights of connected IM user. The Jenkins user corresponding to the author of the bot command must be used.

        Attachments

          Issue Links

            Activity

            Hide
            kutzi kutzi added a comment -

            I don't understand why you see this as a bug. If you given the jenkins-im user all authorizations, it works as designed.
            If I understand your request correctly, you want the plugin to somehow match the users of the connect IM user (e.g. IRC).
            This is IMO simply not possible because that are 2 totally different user bases.

            Show
            kutzi kutzi added a comment - I don't understand why you see this as a bug. If you given the jenkins-im user all authorizations, it works as designed. If I understand your request correctly, you want the plugin to somehow match the users of the connect IM user (e.g. IRC). This is IMO simply not possible because that are 2 totally different user bases.
            Hide
            fabdouglas Fabrice Daugan added a comment -

            Indeed there are 2 different bases but why not reusing the "Default ID suffix" parameter to remove its value from the user requesting the action. This way, you get the jenkins user name and then the assoacited authorizations.

            Show
            fabdouglas Fabrice Daugan added a comment - Indeed there are 2 different bases but why not reusing the "Default ID suffix" parameter to remove its value from the user requesting the action. This way, you get the jenkins user name and then the assoacited authorizations.
            Hide
            kutzi kutzi added a comment -

            It would under circumstances be pretty easy to get admin rights to Jenkins by registering an admin_<default_id_suffix> IM user for example. There are probably a couple of other thinkable attack vectors if we would simply trust the passed IM user credentials.

            Show
            kutzi kutzi added a comment - It would under circumstances be pretty easy to get admin rights to Jenkins by registering an admin_<default_id_suffix> IM user for example. There are probably a couple of other thinkable attack vectors if we would simply trust the passed IM user credentials.
            Hide
            fabdouglas Fabrice Daugan added a comment - - edited

            We can extend the current behavior just like this :

            given XMPP user "USER1@company"
            if (option "Remove suffix for mapping" == null) {
              execute_command_with(generic user)
            } else {
              matching_jenkins_user = findUserByLogin(remove_mapping_suffix("USER1@company"))
              if (matching_jenkins_user == null) {
                 not authorized
              }
              execute_command_with(matching_jenkins_user)
            }
            

            What do you think?

            Show
            fabdouglas Fabrice Daugan added a comment - - edited We can extend the current behavior just like this : given XMPP user "USER1@company" if (option "Remove suffix for mapping" == null) { execute_command_with(generic user) } else { matching_jenkins_user = findUserByLogin(remove_mapping_suffix("USER1@company")) if (matching_jenkins_user == null) { not authorized } execute_command_with(matching_jenkins_user) } What do you think?
            Hide
            kutzi kutzi added a comment -

            As I said before, I think that trusting that if someone has a user name on some remote system (the IM server) also means that he/she has the same username in Jenkins, has the big potential for security issues

            Show
            kutzi kutzi added a comment - As I said before, I think that trusting that if someone has a user name on some remote system (the IM server) also means that he/she has the same username in Jenkins, has the big potential for security issues

              People

              Assignee:
              kutzi kutzi
              Reporter:
              fabdouglas Fabrice Daugan
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated: