Posted by greggles on October 19, 2011 at 8:27pm
We have a security policy page that says if a vulnerability requires a specific list of permissions then the team will not send an SA for the issue. In Drupal 7 we have hook_permission with more options like "restrict access" which can be set to TRUE to warn users about the permission being important.
I propose that we add a bullet point text to the security policy page to say:
Any permission in Drupal 7 which has "restrict access" set to TRUE. Given that this is not available in Drupal 6, if a Drupal 7 permission has that set and there is a similar issue in Drupal 6 then both versions will get an SA.
Comments
Makes sense
I think this proposal makes sense. It extends the list of permissions on that policy page to include contributed modules (like access all views), which I think is nice and generally just gives a reason as to why those specific permissions are different than others. +1 from me.
--
-- matt tucker
k
I think I agree with this idea. In my opinion this is kind of the point of the "restrict access" property of the permission. If you can't trust a user to not be malicious they shouldn't have permissions of this kind.
That said, I feel it's important that there is complete clarity about the timing and requirements for security announcements.
Here's a question that may create a gray area: does this only apply to Drupal 7 versions?
Example from an imaginary contrib module--
Drupal 6 "administer widgets"
Drupal 7 "administer widgets" (that is tagged with restrict access)
If there's a security issue that applies only if the user has "administer widgets".
Does there need to be a fix and an SA?
(I say yes, that should be the case)
I agree and updated my
I agree and updated my proposed text in the original post. Great catch!
knaddison blog | Morris Animal Foundation
Seems fine
Our Security Advisories (SAs) provide a code "fix" for a particular problem and possibly list (behavioral) remediation steps -- as opposed to the Public Service Announcements, which focus pretty much solely on user education.
In light of this, it makes sense to me that if we have a mechanism within hook_permission() to inform site admins that a particular enabled permission could allow certain exploits, and they enable it anyway, this is not a problem that would normally be fixed in code and require an SA. So, thumbs up on your suggested change, greggles.
I completely agree.
Hopefully this won't give contrib maintainers the green light to start willy-nilly adding 'restrict access' to their permissions to 'avoid' the security team or 'fix' the security issues - I have a bit of faith left in our community. I'm fully in favor of making this an official assumption about permissions and security releases.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
Great, just updated the docs
Great, just updated the docs at http://drupal.org/security-advisory-policy
@Dave - I agree. If we see that happening we can clarify the policy and create issues in those module queues.
Thanks, everyone!
knaddison blog | Morris Animal Foundation