Thank you. That's clear.
I have a scenerio that affected me today that I'd like to offer.
http://www.eye.fi produces a SDHC card which has a tiny WiFi transceiver in it. It allows people to use this SDHC card in a camera and it will upload the pictures in near real time to their computer. Its really fun. One part of this solution is the Eye-Fi software on the computer hosts a server on localhost 127.0.0.1 on a specific port.
When customer wants to use the admin interface, they go to
http://manager.eye.fi which then has code that calls to 127.0.0.1. Using the default ABE SYSTEM ruleset causes this to fail. Given your instructions above, I added one line to the SYSTEM ruleset:
- Code: Select all
Site LOCAL
Accept from LOCAL
Accept ALL from *.eye.fi
Deny
The solutions works. My only concern is that there could be frequent user driven exceptions to the ruleset like this. It tends to make me think that such exceptions would be in the USER ruleset rather than altering the SYSTEM ruleset. For me and my simple mind, the SYSTEM ruleset is a global default widesweeping protection that would be overridden by user exceptions; segmenting those rules into the SYSTEM and USER rulesets respectively.
My intention is not to rethink your architecture. Rather, how is the given architecture described in a way that allows users to naturally understand how it works and to configure it? For example, in the future when a simple UI similar to NoScripts "allow" tray icon creates these exceptions...should it put them in the USER ruleset or the SYSTEM ruleset. Given the current default SYSTEM rule, it must alter that rule. Which seems odd to me.
Thank you. That's clear.
I have a scenerio that affected me today that I'd like to offer. http://www.eye.fi produces a SDHC card which has a tiny WiFi transceiver in it. It allows people to use this SDHC card in a camera and it will upload the pictures in near real time to their computer. Its really fun. One part of this solution is the Eye-Fi software on the computer hosts a server on localhost 127.0.0.1 on a specific port.
When customer wants to use the admin interface, they go to http://manager.eye.fi which then has code that calls to 127.0.0.1. Using the default ABE SYSTEM ruleset causes this to fail. Given your instructions above, I added one line to the SYSTEM ruleset:
[code]
Site LOCAL
Accept from LOCAL
Accept ALL from *.eye.fi
Deny[/code]
The solutions works. My only concern is that there could be frequent user driven exceptions to the ruleset like this. It tends to make me think that such exceptions would be in the USER ruleset rather than altering the SYSTEM ruleset. For me and my simple mind, the SYSTEM ruleset is a global default widesweeping protection that would be overridden by user exceptions; segmenting those rules into the SYSTEM and USER rulesets respectively.
My intention is not to rethink your architecture. Rather, how is the given architecture described in a way that allows users to naturally understand how it works and to configure it? For example, in the future when a simple UI similar to NoScripts "allow" tray icon creates these exceptions...should it put them in the USER ruleset or the SYSTEM ruleset. Given the current default SYSTEM rule, it must alter that rule. Which seems odd to me.
