Discussion: Site Specific Permissions Policy

[seleko]

Hello!
Could I have a suggestion on my vision of Permissions Policies.

NS good addition, but unfortunately its approach to problem doesn't provide flexibility.
It copies MSIE concept of security zones... Not using much CAPS concept that already Mozilla has. It would be right to give user opportunity to configure WHAT site can or can't instead of creating whitelist or blacklist.

for example: how can i configure access policies for banning site to access SideBar same time allowing it XSS?
Yeah, I need a tool to configure: capability.policy.sidebarAccess.Window.sidebar & capability.policy.default.XMLHttpRequest.open.

Sad to do it manually.

With ABE, could be implement more granularity for policies and sites?

[Giorgio Maone]

It copies MSIE concept of security zones... Not using much CAPS concept that already Mozilla has. It would be right to give user opportunity to configure WHAT site can or can't instead of creating whitelist or blacklist.

I can see what you mean (even though I'm not sure it's a huge win from a security standpoint, since there are countless ways to do the same thinG in JavaScript), but unfortunately this functionality is being removed from Gecko's CAPS for performance reasons.
The only CAPS feature guaranteed to survive is JavaScript site-level blacklisting/whitelisting, and only because NoScript relies on it.

[seleko]

damn. thanks for comment.

[maitch]

I often find myself having to allow a site just to do something trivial like download a PDF. That got me thinking about some possible enhancements to NoScript... would these be possible/generally helpful?

1. Give users the option to allow just a particular type of script for a range of sites (e.g. to allow reading .pdf files from a list like: *.edu,*.nxp.com)

2. Let users accept only the type of scripts from a site that are required at the moment... if that means allowing a .pdf or something like that, it should not allow java/etc scripts automatically later. So it would cater for people saying "I trust this site just enough to do ...", but it may possibly help if a trusted site is hijacked to contain some dangerous type of script it has never had before.

3. Allow a script (or a site once only) if it was linked to from a particular site (matching a regular expression?), and then only if some other criteria are met perhaps (e.g. type of script and/or site matching wildcards/regex?)

Mark

[donwms]

I have known about NoScript for a quite a while, but only after I heard an endorsement on SecurityNow by Steve Gibson and Leo Laporte, did I decide to trust and install NoScript. It appears to be a great piece of software. Thank You.

It is generally agreed that disabling unneeded software features reduces the attack surface, so the more features that are disabled, the less attack surface there is. Of course, reducing the attack surface is a good thing, even for trusted sites.

In terms of NoScript, I want to be able to minimize my attack surface, even for trusted sites. In other words, I would like some method assign different options on different websites. One way to accomplish this would be to allow the user to define and name multiple sets of NoScript trust options, then allow the user to assign websites to one of those named option sets. This would allow him to pick a level of trust from a manageable number of choices.

NoScript could come with some example option sets, perhaps three options sets:
1. Unknown: Everything disabled (Unknown sites assigned to this set of options, by default)
2. Known: Many features disabled. (Many web sites should work, but with reduced risk)
3. Trusted: Most features enabled. (Only very trusted sites should be assigned to level)

The user could modify or delete these sets of options. Or he could create more.

The whitelist would have two columns (the website URL and the option set name). Each named option set would contain a set additional restrictions for the websites controlled by that option set.

A note about trust:
From a practical viewpoint, trust is not simply black or white. There are many levels of trust. My trust in someone is based on more than whether they are easily identifiable and reachable and on more than whether or not I could sue them. The same goes for a web site. Some web sites should clearly not be trusted, and should be on everyone’s black list. Some sites can be totally trusted and can be put on your white list. However, most sites are somewhere in between.

[Grumpy Old Lady]

It is generally agreed that disabling unneeded software features reduces the attack surface, so the more features that are disabled, the less attack surface there is. Of course, reducing the attack surface is a good thing, even for trusted sites.

That's the basic state of NS already; all JS, and as much active content as possible otherwise, is disabled on all sites until the user allows it selectively. That's the central point about whitelisting isn't it?

In terms of NoScript, I want to be able to minimize my attack surface, even for trusted sites. In other words, I would like some method assign different options on different websites.

You have this already in the NS (contextual) sorry, I mean Options menu - - and also in extra non-UI preferences.

One way to accomplish this would be to allow the user to define and name multiple sets of NoScript trust options, then allow the user to assign websites to one of those named option sets. This would allow him to pick a level of trust from a manageable number of choices.

The various Temporary Allow, Permanently Allow, Block plugins on untrusted and trusted sites already gives this control - - although some few users have asked for more granular control over plugins.

NoScript could come with some example option sets, perhaps three options sets:
1. Unknown: Everything disabled (Unknown sites assigned to this set of options, by default)
2. Known: Many features disabled. (Many web sites should work, but with reduced risk)
3. Trusted: Most features enabled. (Only very trusted sites should be assigned to level)
The user could modify or delete these sets of options. Or he could create more.

NS already has these features.
Your state 1. is equivalent to all active content not allowed; the (context)sorry, again I mean Options menu gives you access to customise NS to a more tied-down configuration than even the very cautious default NS configuration, plus there are quite a few more hidden preferences to tie NS right down with. In other words, the whole web is untrusted by default in NS
Your state 2. is how most experienced users of NS already navigate - - ie with the default NS configuration - plus plugins blocked on "allowed" sites, and then temporarily allowing sites and objects only if some function is needed - and then only the minimum domains that are needed for some feature to work. In this configuration, Giorgio has designed a unique context menu that makes NS navigation on-the-fly not only one of the most transparent forms of process control amongst browsers, but also (and this is the most important for all values of usability that matter) the least intrusive into both web use and browser function.
Your state 3? Whitelisting is possible for any number of domains - and with more granularity than the default configuration. Certainly plugin whitelisting is not as finely controllable. I would say that many particular site requirements for plugin whitelisting could be met by a user creating a profile for this kind of whitelisting.

My advice for new adopters, as a plain long-time user of NS and an even longer member of the Fx community, is to firstly become familiar with Fx and it's many unique features that can be used in conjunction with specific NS settings, and then to boldly go onto the web with NS - using the context menu on-the-fly - which is its genius usability - and find out just how little whitelisting or *spit* blacklisting a user really has to concern themselves with.

From a practical viewpoint, trust is not simply black or white. There are many levels of trust. My trust in someone is based on more than whether they are easily identifiable and reachable and on more than whether or not I could sue them. The same goes for a web site. Some web sites should clearly not be trusted,

Most true!

and should be on everyone’s black list.

Well, with NS all sites are on everyone's blacklist, every day, until the user decides otherwise - - and in a default retractable form too :-) - - surely the safest way when a domain's trust status may be subject to many changes that a user doesn't keep current with.

Some sites can be totally trusted and can be put on your white list.

Yes, but that's only on current information surely? What about tomorrow when the site's been corrupted or the company's been sold? Better to temporarily allow and to have a tiny whitelist. My whitelist in my general browsing profile is 2 entries long - and more for convenience of cookie setting per visit rather than a set-to-forget convenience.

However, most sites are somewhere in between.

Which is why Temporarily Allow, and the domain granularity already in NS suit the thoughtful user so well.

All of the above, of course, recognises that there is a demand for a Group Policy version of NS, but for the general single user points you've made, NS is already providing an extremely flexible whitelisting approach to security.

Edited once to correct bad use of "context" where it should have read "Options"

[donwms]

[/quote]

...Certainly plugin whitelisting is not as finely controllable. I would say that many particular site requirements for plugin whitelisting could be met by a user creating a profile for this kind of whitelisting.

Sorry, I rambled on and on in my previous post. I should have simply said that it would be very nice to have a site list which could be used to select a trust profile. The new site list would extend the current whitelist function to allow a more granular level of trust to be chosen. There would need to be a default trust profile (for untrusted sites) and an arbitrary number (based on how granular the user wanted to be) of additional profiles for sites with varying levels of trust. I have not tried to determine which options could be put in trust profiles. Of course, some NS options need to apply to globally. However, there are many options that make sense to be able to vary from site to site. Most are under the Plugins, Appearance, Notifications, and Advanced tabs. They allow the user to specify varying levels of trust. By having multiple trust profiles, the user could assign different levels of trust to each site as he sees fit.

I agree that by using temporary trust and context menus you could approximate my suggestion. However, frequently I close applications that I not using, otherwise I get too many applications going at the same time and my system bogs down or I bog down trying to keep track of them. So my temporary trust assignments would disappear many times a day. However, you do make a good point, that sites change over time and may become compromised. Therefore, I would like to suggest that the ability to assign an expiration interval to each entry in the site list. The interval could be short as in minutes, long as in weeks or months, or even permanent. An expiration message could prompt the user that it is time to reevaluate the site.

P.S. As you add more and more options to any program, it becomes easier for others to find a bug that they can exploit. Adding more options to a security program like NoScript increases its attack surface; therefore one has to carefully weigh the benefits of the new options against the potential threats.

[Grumpy Old Lady]

...Certainly plugin whitelisting is not as finely controllable. I would say that many particular site requirements for plugin whitelisting could be met by a user creating a profile for this kind of whitelisting.

Sorry, I rambled on and on in my previous post. I should have simply said that it would be very nice to have a site list which could be used to select a trust profile.

My use of profile is different from yours - - I'm using profile in the context of Fx profiles (see the Mozillazine KB for how to manipulate profiles), not in any security policy model, as you appear to be doing.

I agree that by using temporary trust and context menus you could approximate my suggestion. However, frequently I close applications that I not using, otherwise I get too many applications going at the same time and my system bogs down or I bog down trying to keep track of them. So my temporary trust assignments would disappear many times a day.

To re-emphasise what I said in my first response to you, I highly recommend that a new NS/Fx user approaches using NS in the context of Fx use overall; there are many posts in the support forum that attest to users being unfamiliar with both the features and fine-tuning power of the total Fx package, as well as the operation of NS on-the-fly (as it was designed to be used). In your particular example, for your temporarily allow (TA) choices, Giorgio has designed the on-the-fly menu for just this kind of use; I also browse the web in short sessions, and it is such a simple and natural action to toggle the NS menu with either the CTRL SHFT backslash or the CTRL SHFT S key combos. But, if you want to whitelist a site for good (Allow), your choice is already there in the on-the-fly menu.
For your suggestion to include expiry terms in the whitelist? I believe this has been brought up in here already and I wasn't persuaded by it; my main objection is that it adds yet another toggle that can be misused by novices - - with consequent confusion about why whitelisted sites no longer work, or worse, why a semi-permanent Allow could have morphed into an Allow. There are posts in plenty in the support forum showing that novices have toggled other obscure preferences and find themselves unable to back out of the maze :-) As you emphasised upthread, trust is many different things to different users, and in the case of reviewing whitelists, well, make it a system housework job for yourself.

P.S. As you add more and more options to any program, it becomes easier for others to find a bug that they can exploit. Adding more options to a security program like NoScript increases its attack surface; therefore one has to carefully weigh the benefits of the new options against the potential threats.

Totally agree, goes without saying almost :-)
Anyway, welcome to NS and Fx! I know you are so much safer on the web with NS/Fx than with any other browsing solution and I hope you get to see the power over the web that NS also gives you.

[donwms]

Unless you have some way to sandbox and test a script, view the code, etc. a temporary allow could let malicious code execute without you even knowing it (and as Steve Gibson on SecurityNow has said many times, “you’re toast”). I'm fairly sure that most users don't have the time (or take the time) to truly vet the software for themselves. In other words, the average/native user needs to have advice from an expert. However, they probably don't do that, instead they want cool software, so they temporarily trust it, even if they shouldn’t. (My kids don’t understand why I’m not a PC expect. I've been a MainFrame systems programmer since 1979 long before they were born. I was playing on MFs long before that in high school.)

I come from a different world with different rules. In the mainframe world, companies provide a test system or sandbox, at least the ones I've worked for. On the MF, software (esp. high risk software) tends to be tested for many weeks or months, sometimes even longer. It is not uncommon, for MF software testing to go through multiple levels or stages of quality assurance involving many experts on both the software developer side and by the business users who purchased it. It does not matter how much the developer has tested it. The user tests it, again. (Ok, both companies are probably paranoid that they could get sued.) Testing is generally not rocket science; it is just methodical. It tends to be done in a very incremental orderly fashion. Initially, they start in an environment where nothing of value can be damaged or compromised. Then they slowly relax the restrictions as they become more confident (or brainwashed). When everyone is satisfied, they declare it as good to go (then it crashes the entire network 12 times the first week).

On the PC platform, I do not have an equivalent environment available. How do you avoid the temptation to use TA on the cool new website that your best buddy found yesterday?

[Alan Baxter]

On the PC platform, I do not have an equivalent environment available. How do you avoid the temptation to use TA on the cool new website that your best buddy found yesterday?

I used to resist the temptation. Now I run the browser in Sandboxie whenever I need to visit a "cool new website".

[donwms]

Yes, Sandboxie was recommended by SecurityNow with Steve Gibson in their Virtual Machine series. I have not tried Sandboxie, yet. It does not claim to identify badware, it just prevents it from being installed. While prevention is good, I would like notification as well. Of course, it is not a trivial matter to determine what is goodware and what is badware, otherwise anti-virus programs, etc. would be a piece of cake.

[Alan Baxter]

While prevention is good, I would like notification as well.

"If wishes were fishes, we'd all eat like kings." Fortunately, prevention is good enough. Just like NoScript, Sandboxie protects your system's integrity from malware without having to evaluate it. Leave the blacklists to your AV and other security products, but rely on them at your peril.

[donwms]

I'd be one fat king

[Alan Baxter]

[Grumpy Old Lady]

Quoth Alan Baxter:

Sandboxie protects your system's integrity from malware without having to evaluate it

Ahem, Sandboxie plus NS/Fx - - there's no hiding inside any sandbox from active exploits that use the web, as opposed to your operating system.
http://hackademix.net/2008/01/12/malware-20-is-now/