Permissions are not enforced

permissions

(123dev) #1
  • version used: Community Edition Version 7.6 (build 21501) [Docker]
  • error observed: permissions are not enforced
  • steps to reproduce: see below
  • potential workaround: none

Sonarqube 7.6 integrated with Active Directory
sonar.properties:

sonar.security.realm=LDAP
sonar.authenticator.downcase=true
ldap.url=ldap://<ldaphost>
ldap.bindDn=CN=sonar,OU=Users,OU=MyBusiness,DC=Company,DC=local
ldap.bindPassword=secret
ldap.user.baseDn=OU=Users,OU=MyBusiness,DC=Company,DC=local
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
ldap.group.baseDn=OU=Security Groups,OU=MyBusiness,DC=Company,DC=local
ldap.group.request=(&(objectClass=group)(member={dn}))
ldap.group.idAttribute=cn
sonar.forceAuthentication=true

We have the following Groups and they also exist in AD
Note: Sorry couldn’t post multiple images, so please see it in the single image at the bottom of this post

And these are the users
Note: Sorry couldn’t post multiple images, so please see it in the single image at the bottom of this post

All simple
Initially we wanted to only authenticate users that belonged in AD groups:
sonar-analysers, sonar-developers, sonar-administrators groups. (sonar-)
But it looks like we can’t do that, so we have no choice but to allow any AD authenticated user to login to sonar. (PS, we couldn’t get nested groups working either, so we flattened the users in sonar-
groups)
If this is not true, please advise how it is possible to restrict to certain groups
as this setting didn’t work

ldap.group.request=(&(objectClass=group)(|(cn=sonar-analysers)(cn=sonar-developers)(cn=sonar-administrators))(member={dn}))

To work around that limitation, we decided to remove all permissions from sonar-users and here are our default template
Note: Sorry couldn’t post multiple images, so please see it in the single image at the bottom of this post
As can be seen, sonar-users have no permissions granted.

And here’s the global permissions
Note: Sorry couldn’t post multiple images, so please see it in the single image at the bottom of this post

The user F in Active Directory does not belong to any of the sonar-* groups
yet the user is authenticated in sonar, and is in sonar-users group

Fine,
However this particular user is able to

  • Run Project Analysis
  • Browse Projects
  • And Even see the Code

How is that possible?
Is this a bug or a misconfiguration on our part?

Thanks


(G Ann Campbell) #2

Hi,

A Permission Template is a set of permissions that will be applied to new projects at creation. You can update your template all day long without affecting existing projects. You should check the permissions of your existing, individual projects to understand what’s going on.

If you’d like your current permission template to be applied to already-existing projects, you can accomplish that by going to Administration > Projects > Management and using the Bulk Apply Permission Template button.

 
Ann


(123dev) #3

Hi Ann,

Thanks for taking the time to respond.
Sorry if I wasn’t too clear, the project was created after setting the default template, and indeed checking the project details, I could see that the user F had no permissions on the project.

However visiting that page made me realize what the issue was.
All new projects are created as public, sadly there is no setting to control that, other than setting it manually in the UI or through API.
The project was set to public, and effectively allowed the user F to see / do anything.

Although we can work around these limitations by trying to be pro-active I find that security is not the strong suite of Sonar.

To summarize the limitations.

  • Can’t restrict LDAP authentication of users to specific LDAP groups instead of the entire Active Directory.
  • Nested Active Directory Groups are not supported.
  • Can’t set the default visibility of a project (public / private).
  • No support for Deny in permissions.

This issue can be considered closed.
Thanks


(G Ann Campbell) #4

Hi,

Before we close this, let me offer just a little more information:

Nope. Instead, it’s about what permissions you make available to your users. (More below).

We don’t offer direct support, but this guy got it working

Assuming you’ve locked your instance down to require login, then nothing’s truly “public”. Beyond that, it’s about how you configure your permission template. If you don’t want new projects to be visible to all logged in users, first remove any permissions granted to “Anyone” in your permissions template, then also remove “Browse” (and probably “See Source Code”) from the sonar-users group.

 
Ann


(123dev) #5

Hi Ann,

Thanks again for the follow up.
Re: Can’t restrict LDAP authentication of users to specific LDAP groups instead of the entire Active Directory.

Nope. Instead, it’s about what permissions you make available to your users. (More below).

Although not ideal, ie allowing any AD user to be able to login, and then making sure that all the proper permissions are set to restrict the user, that is exactly what we tried to do, after realizing that everyone in AD is able to login.
Sadly that is why we logged this ticket, as that method didn’t work.
The anyone group did not have any permissions, as you suggested here

Assuming you’ve locked your instance down to require login, then nothing’s truly “public”. Beyond that, it’s about how you configure your permission template. If you don’t want new projects to be visible to all logged in users, first remove any permissions granted to “Anyone” in your permissions template, then also remove “Browse” (and probably “See Source Code”) from the sonar-users group.

Yet, as shown in our original post, the user who did not belong to any group was able to see everything, because projects by default are public.
Perhaps this is a bug.

Only after setting the project to private we were able to limit the user’s access.
So if some developer creates a new project and doesn’t pay attention to setting it private, all bets are off, this coupled with any AD user being able to access Sonar compounds the issue further.

As for support of Nested Group, we tried that before logging this ticket, it didn’t work, not sure how and why it worked for that user.

Thanks