Paranoia Roadmap for Stable D7 Release

I haven't tested it yet but I will shortly as I'm doing a security audit for several clients. This is one of the modules I want to put in place for all of them, so I'll gladly test it.

Based on my current schedule and a more pressing need to update known areas, I probably won't get to this until monday/tuesday. But as soon as I'm done, I'll update this thread.

That sounds fine by me. I had a lot of PCI items to go through, so I haven't tested this yet. Tomorrow/Thursday are likely... And I'll also check out the other ticket in #3.

Hey @greggles.

I just did about 40 minutes of testing. Let me break my response into two areas: php execution protection and configuration protection.

I think the RC1 version does an excellent job on the php front. I was able to confirm that proper modules/filter are disabled.

The concerns I still have (and I'll break these into tickets) surround around configuration.

User's with 'Administer users' can still alter user#1's username. While this doesn't open the door for another admin to take over the account with a new password, it can block an admin from getting into the site without either altering this value in the db.

The instructions on the project page state "After installing, be sure to visit and save the permissions form to remove all previous grants." Should these steps take place in hook_install (and maybe hook_cron) or would that piss people off? In addition to this, you actually cannot remove those permissions through the admin GUI after they are hidden (I can confirm all php related permissions are still in the db). This has the surprising effect (or at least unexpected) of all those permissions returning if/when the module is disabled. I realize that with the php module disabled, this might be moot. But other modules that have hidden permissions not related to the php input filter (e.g. 'bypass rules access') would be available out of the gates again.

I know not allowing the module to be disabled through the GUI would prevent many of the above scenarios. But a user on the drush command line could slip and I'd rather a temporary disabling of the module to leave all those permissions still off just in case the admin didn't notice it being tripped off.

Next. It would be cool if user #1 could still see the permissions t hat are no longer alterable in the admin GUI form. Perhaps they are merely set to 'disabled' (e.g. greyed out) so they can't be changed but an admin still knows they were there but simply disabled by paranoia.

Finally, I'm really interested in the Two Factor Authentication module. Perhaps a module with a name like 'paranoia' would at least recommend such a module on hook_enable!

That's all from me. I'll break these into tickets. And short of some unexpected behavior, the module does work as claimed in my tests. Thanks for pushing this to RC status! And ping me if anything I mentioned isn't clear or (worse) is a bad idea :)

Cool. Ticket is here #1549542: Preventing edit of uid 1 name. I don't necessarily see it as a release blocker, but it would be nice for a 1.0 release.

I just need to remove my dependency on the php filter in a few areas and I'll be ready to use/install!