On Wed, 7 Mar 2012 09:26:31 -0800 Adrienne Porter Felt wrote: > > > For example, there is relatively little risk attached to > > > letting an app turn your Bluetooth on or off. > > > > How about a local app introduced via qr code phishing switching > > it on and then a stack exploit by a local attacker or attackers device > > getting root. What about bluetooth malware and the bugs in the > > bluetooth stack. > > > That is a problem that the system itself needs to handle, via system design > and hardening. Users need to be able to assume that his or her device > works like it is supposed to (e.g., granting access to location will not > also accidentally grant access to the mic), otherwise permissions are > meaningless.
Sorry to be obtuse but I standby the following sentiment. Assumption is the mother of all ???? ups In fact, most security books say users should assume that anyone can access anything on an online computer. The leave it off and bury it sentiment goes a bit far though, despite tempest attacks. > If any privilege can be used to get any other privilege, then > how can you ever make a decision? Certainly there will be privilege > escalation bugs but it is the responsibility of the platform vendor to find > and fix them, not the responsibility of the user to plan ahead for them. That's true, but unfortunately it is quite ineffective. Certain permissions will be far more easily exploited or have greater potential consequences than others and the user needs to be given all the tools for an easy life, both through the ability of a user to secure and allowing a user to not give a ???? about what the browser is doing or not being able to make any risk based decision. This reinforces the fact that priviledges need to be fine grained and definable by the user even if they are sane by default and hidden by default and chosen by authors of apps but with warnings for a select few more concerning permissions or domains the user has not chosen to visit. Developers cannot please everyone and also want an easy life, mandating riskier setups. Personally I don't think any browser app should be able to or want to turn bluetooth on/off as turning bluetooth on is a security risk which could end with a machine being owned. A browser that could switch wireless on or off without being exploited wouldn't touch my radio free networks, that's for sure. A couple of other examples where users may reduce default permissions for a less risky setup, possibly because they simply will never need those permissions but others might. Note that most people would think disabling these was pointless and devs are right to enable them by default. ______________________________________________________________________ IPV4 only network Ipv6 is less secure than ipv4 (The brilliant OpenBSD based on code from your establishment has one of it's two only remote holes attributed to ipv6, cisco routers have had more than one exploit but that's no surprise and a recent paper highlights many concerns with ipv6). firefox enables ipv6 but lets you disable it through about:config. You can also ultimately disable it through blacklisting the kernel module and firewalls but I currently see no point in making hardening harder or why anything other than the OS UI would need to control bluetooths on/off state. ______________________________________________________________________ All Gentoo hardened users have to recompile firefox for it to run with their hardened kernel due to a feature most people simply don't use. I've switched to Opera as I don't wish to waste time and cpu cycles compiling firefox and firefox depends upon being able to run Java Just In Time Executions that the grsecurity patch blocks by default to prevent simultaneously writeable and executable areas of memory. If I have no need for JIT, I shouldn't have to have it enabled. _______________________________________________________________________ Minimising and seperating priviledges is key to security. Why on earth firefox needs IPC dbus just to write a config file and run is bad overly complicated design. Hopefully designing this permission system will improve these things. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
