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

Jenkins's security is not applied for IM user

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • Jenkins 1.581
      instant-messaging plugin 1.30

      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.

          [JENKINS-24902] Jenkins's security is not applied for IM user

          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.

          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.

          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.

          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.

          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.

          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.

          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?

          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?

          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

          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

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

              Created:
              Updated: