A. THE BUG
[ol]- A User Account that is a member of Group is not being check properly.
Can U reproduce the problem & if so how reliably?:
Yes, very reliable.
If U can, exact steps to reproduce. If not, exactly what U did & what happened: 1:To illustrate this issue, as it corresponds to using Administrators Group, make sure you are logged in under an Administrator account with UAC set to default. 2:Go to the website filtering and go to the Categories tab. 3:Here create a new category called “My Blocked Sites”. 4:Right-click on the new category and select “Add Website”. 5:Type in any website, for example *filehippo.com and select OK. 6:Then go to the Rules Tab, right-click and select “Add” 7:Type “Custom Blocked Sites” for new rule. 8:Under Category, right-click and select “Add” 9:Then choose “My Blocked Sites” Category and Click “OK”. 10:Under Restrictions click Add button or Right-click select “add”. 11:Type Administrators in “Enter the object name to select” textbox. 12:Click Check Names button. 13:Click OK button. Then click OK again, and once again, to create and save the new rules. 14:Open up Firefox, remembering that is run with non-elevated privileges under UAC. Note that if you go to filehippo.com it is not blocked. 15:Run Firefox with elevated privileges and see that filehippo.com is now being correctly blocked.
If not obvious, what U expected to happen:
I expected that any user account that is a member of Administrators Group will be block from the specified site even running in non-elevated privileges.
If a software compatibility problem have U tried the conflict FAQ?:
NA
Any software except CIS/OS involved? If so - name, & exact version:
Firefox
Any other information, eg your guess at the cause, how U tried to fix it etc:
The cause may be that the user account is not properly checked if they are a member of the group. They should check if the account is a member of group even if the group account is flagged as disabled in the process (non-elevated privileges).
This bug doesn’t apply only to Administrators Group but in all Group Accounts (eg. Guest, Power Users, Backup Operators, Users, Replicator, Everyone and etc.) using Restricted Token in the application. As you can see when you run a non-elevated firefox through UAC in the KillSwitch → Right-click firefox process → Properties → Security Tab. The BUILTIN\Administrators is flagged for deny only which application could accomplish by using CreateRestrictedToken function that could be apply not only on Administrators Group but in all User or Group Account that the developer desires and so to prevent this from happening and for future applications, user account should be check properly of their group member regardless of their Restricted Token.
A User or Group SID having a deny-only attribute in an Access Token is not being considered as a member that results to not being matched in Webfilter Rule.
The cause of the problem is the CheckTokenMembership or CheckTokenMembershipEx function which returns true only when SID is present and having the attribute SE_GROUP_ENABLED. Thus, having an attribute of SE_GROUP_USE_FOR_DENY_ONLY in the access token returns false that produces undesirable result. To fixed this I suggest to use GetTokenInformation function instead.
[/ol]
B. YOUR SETUP
[ol]- Exact CIS version & configuration:
CIS 7.0.317799.4142
Have U made any other changes to the default config? (egs here.):
No
Have U updated (without uninstall) from CIS 5 or CIS6?:
No
[li]if so, have U tried a a clean reinstall - if not please do?:
NA
[/li]- Have U imported a config from a previous version of CIS:
No
[li]if so, have U tried a standard config - if not please do:
NA
[/li]- OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:
Windows 8.1 Enterprise x64, UAC setting is defualt. Administrator, No VM used.
Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:
a=None b=None
[/ol]
So do the following steps roughly describe this issue?
1:Create Block Rule under an administrators account?
2:Restart computer and log into a Limited Account.
3:Find that the block rule which worked for the admin account no longer works under the Limited Account.
4:Restart computer log in under an admin account.
5:Find that the block rule correctly works.
Login any account that is a member of Administrators Group.
Create Block rules, remove all Users (eg. Everyone and ALL APPLICATION PACKAGES) and replace it with Administrators.
Find that the block rule doesn’t work even the account is under Administrators Group running unelevated firefox.
Only one account that is a member of Administrators Group was used and running firefox in unelevated privileged doesn’t work which is wrong because the account still a member of Administrators Group
Can you please provide more details, and if possible screenshots, showing how you created the category name and added the website to the category? More details, and screenshots, for this process would be very very helpful for me in understanding this issue, and thus forwarding it correctly.
Thank you. I’ve started editing the steps in the first post, but have gotten hung up on another step (a very important one). Specifically how did you set up the Restrictions to be for users Administrators? Can you please show that step as well?
Thank you. I have updated the steps for reproduction in the first post.
However, now that the rule is in place under which circumstances does it not work?
If you log in under an admin account is there any way to make the rule not work, or does it always work correctly for users logged in under an admin account?
Ok. “The Remove all users or group restrictions” and “Add Administrators Group Account in the restriction” after step 10 in the first post should be remove and insert this “Under Restriction remove all Users” right after step 5.
However, now that the rule is in place under which circumstances does it not work?: When you run the firefox in non-elevated privileged under admin account.
Thank you, and I would also like to thank you very much for the patience you have shown me. I am not very familiar with the webfilter component and am therefore trying to better understand it at the same time so that I can best evaluate this issue. I really appreciate your help with that.
I have now been able to replicate that after creating the rules as defined, it does not block the site if Firefox is run under as non-elevated through UAC. That said, as we said that the website is a restriction only to administrators, shouldn’t this be expected?
I may be misunderstanding this issue, but I looked into it more, and on this page it looks like ALL APPLICATION PACKAGES would always apply.
Running an application in non-elevated privileged through UAC doesn’t mean that your account is not a member of Administrators Group. The block rule applies to Administrators Group. If you would like to check what account is a member of Administrators Group, you can do this. Press and hold Win + r then type lusrmgr.msc. In the Groups folder, double clicked on Administrators. There you can see who were the members of Administrators Group. We could also use the KillSwitch to determine if the process belongs to a certain group. Right-click on the process select “Properties…” under Security Tab you can see that the process is a member of different groups. Even if the process is not elevated but you could see the “BUILTIN\Administrators” in the Group List then that process is running under an account which is a member of Administrators Group that supposed to be a matched in the block rule.
The “All APPLICATION PACKAGES” as far as I know applies only to windows store apps but still I tried it with the Administrators Group and it doesn’t work.
This bugs doesn’t apply only to Administrators Group but in all Group Account (eg. Guest, Power Users, Backup Operators, Users, Replicator, Everyone and etc.) using Restricted Token in the application. As you can see when you run a non-elevated firefox through UAC in the KillSwitch → Right-click firefox process → Properties → Security Tab. The BUILTIN\Administrators is flag for deny only which application could accomplished by using CreateRestrictedToken function that could be apply not only on Administrators Group but in all User or Group Account that the developer desires and so to prevent this from happening and for future applications, user account should be check properly of their group member regardless of their Restricted Token.
In the first post:
Step 11. Open up Firefox. Note that if you go to filehippo.com it does not blocked.
Step 12. Run Firefox with Admin rights and see that filehippo.com now blocked.
There are two default users(Everyone and ALL APPLICATION PACKAGES) under restriction which I removed and replaced with Administrators. They need to do this to reproduce
I can replicate this issue with the steps provided in the first post. I have also updated the first post, and the title. Let me know if everything seems correct, or if there is still a better way to illustrate this issue.
I’m confused in your step 11 and 12. I think it’s the opposite.
Below is what I mean:
In step 11, open up Firefox(non-elevated privilege) go to filehippo.com results to site is not blocked(blocked is expected)
In step 12, run Firefox with Admin rights(elevated privilege) go to filehippo.com results to site is blocked(expected).
You have not stated the removal of default or previously added User or Group Accounts in the Webfilter Restrictions.
Let me make it clear that the removal of default or previously added User or Group(eg. Everyone, All APPLICATION PACKAGES, and etc…) under Webfilter Restrictions is a must and should be replaced with Administrators Group to prevent any other matched specially Everyone Group which is a matched in this case. The intention is to apply the rules only to Administrators Group and not any one else.
One more thing, Administrator and Administrators are two different thing. The Administrator refers to a User Account while Administrators refers to all User Account which is a member of Administrators Group. Both can be successfully added without errors.
My apologies, I had flipped these on accident. I have now fixed this in the first post. Let me know if there is still a mistake for these steps.
It is likely that I am misunderstanding again, as your understanding of this far surpasses mine. However, when I replicated this I added only the single user to the Restrictions section, and that caused the discrepancy with Firefox. No other changes were needed.
Please feel free to edit the first post to correct the issues you have raised. Let me know when you have finished that and I will take a look again. This is a technical issue, and thus it’s very important to nail down exactly what is causing this, which you seem to have a good handle over.
I think you were creating a new rule. What I’ve done was I edited the “Blocked Site” rule in which there were entries in Category and Restrictions List, and so removal of the previous Users entries is a must but I think it is better to do it that way, to create a new rule so that changes wont affect older rules and so I change it in my first post so no Users or Group Removal is needed. Please have a look on it and do some changes if necessary.
I looked over the first post and everything looks fine to me. However, as there was so much confusion about this issue previously I am asking if it’s okay that you look over it once more, and make sure that even the wording is not ambiguous. I don’t want the devs to be confused as well.
If everything looks perfect let me know and I will forward this to the devs.