Poorly Executed …. User - Config: Deny Config Write
-
Hi all,
Long time pfSense admin here, and I'm taking 15 minutes to type out a post about a new "feature" that is now biting me in the rear.
If you log in to your firewall and go to System > User Manager > Groups > [GroupName] > Edit you are presented with the ability to grant members of this group access to certain features of the WebGUI.
For as long as I can recall, this has worked like this: If you assigned them that privilege, they could do that thing. If you didn't, they could not do that thing.
So, for instance, when I have a non-technical person such as a manager that I want to give access to see the bandwidth usage in real time, I could give them a login and only give them access to this one Status Report. Sure, I have to give them a little more than that (access to Log out, for instance) but it's a handy feature and a value added bonus as compared to some other firewalls where it's an "all or nothing" situation.
Recently the pfSense dev team added a new privilege, but it's NOT a privilege. It's "User - Config: Deny Config Write." So this is a DENY privilege, not a GRANT privilege.
My fatal mistake and one I'd consider a bug is this: At some point I or one of my colleagues assigned this privilege to the group "admins", of which admin is a member. Guess what the result is? None of us can modify our firewall anymore.
We actually have another group in there called FW_Admins that has an identical group in Active Directory, so it ties into AD and we don't log in as "admin", we log in as our AD user credentials and we're admins on the firewall. Well, guess what? The FW_Admins group has this "privilege" too.
Here's the disastrous result: No one can change the firewall anymore. We can't log in and remove this "privilege", whether as ourselves or as admin, because the privilege itself is denying us the ability to write the config.xml.
I can even tell you how this happened. Because we were all used to privileges being GRANT rights and not DENY rights, someone pressed Control-A in the privileges section and then pressed Save. Then they did the same thing for the FW_Admins group.
I thought about creating a new group, like FWAdmins (no underscore), granting it everything except this feature, and then creating an identical AD group that I made myself a member of, then signing in and removing the feature. That doesn't work either, because deny write to config.xml means DENY.
So, in effect this new "feature" is a good way to brick yourself out of your firewall. I'm going to do some hunting and see if I can find where to turn this "feature" off from SSH or the console, but I think this was a poorly executed addition to pfSense. And, please understand that I love the product and will continue to use it, this is just constructive feedback. :-)
-
That privilege has been there for years, actually. Only recently a bug was fixed where that (and some other) privileges were not being respected when using LDAP or RADIUS-backed logins.
Blindly hitting "select all" without considering what all of the privileges do is a bad practice and I don't see us facilitating that by changing the permissions around, but I'm open to suggestions.
-
That privilege has been there for years, actually. Only recently a bug was fixed where that (and some other) privileges were not being respected when using LDAP or RADIUS-backed logins.
Blindly hitting "select all" without considering what all of the privileges do is a bad practice and I don't see us facilitating that by changing the permissions around, but I'm open to suggestions.
Hi jimp,
I'd agree, generally speaking Control-A is a bad practice, but I also notice that the section in question is called "Assigned Privileges." Personally I've never considered it a privilege to be denied access to write a file, but, well, maybe I'm not up on today's backspeak. I mean, the patriot act was supposedly a privilege too, but… I digress.
I guess my suggestion would be that it be handled like it's done with Windows Permissions on NTFS. You have a permission and then two checkboxes -- an allow and a deny checkbox. "Deny" always supercedes "Allow."
The bigger question is, is there a way to remove this "privilege" from a user account or a group once it's been set and everyone is locked out of making changes? We do have console access and access via SSH. I'd just prefer not to reload the entire firewall as there's quite a bit of customization in there...
-
That way was chosen because it fit the current user privilege mechanism. If it was done some other way it would have vastly increased the complexity of the code for very minimal benefit. Selecting everything is never necessary, just pick the "all pages" privilege and a maybe ssh and whatever else someone needs. We have never recommended selecting them all and it's never been necessary. You also never, ever need to edit the group permissions for the admin group, it has all access by default. We don't lock it down because there may be some unforeseen need, but that is also a bad practice.
We can only go so far to prevent foot-shooting.
As for regaining access, the config can be edited by hand at the console using viconfig, or you could use scp to fetch a backup copy of the config and then edit out the privilege, scp it back and restore it from the console.
