begin quoting Andrew Lentvorski as of Sun, May 21, 2006 at 10:37:48PM -0700: > Stewart Stremler wrote: > >>When usability and security conflict, security loses. Period. > > > >Which is exactly opposite of good sense. :( > > No, it's not. > > I'm tired of this platitude from security people. It's just wrong.
It all depends on how you go about defining "usability", I suppose. I'd say, technically, if you might as well power down the system and go home on account of "security", then security has failed the "availability" aspect. On the other hand, if I have to type something in from a scrap of paper given to my by someone else, that's not unusable (although it's often claimed to be so). For example, SSO (single sign-on) is not a usability enchancement, it's a security bypass. Likewise, if you might as well sit down and reinstall your system because you've let anyone on the 'Net install their software as they like, all in the name of 'usability', then it wasn't really very useful. Or if you might as well close the doors to your company because your must-be-kept-confidential data is no longer confidential, or the integrity of your data is suspect, well, that's worse than not very useful. There's a happy middle ground somewhere, we hope. Make it secure enough, without impacting usability _too_ much. Make it as usable as possible, without impacting security beyond the risks you're willing to accept. > Good security == maximally usable for the task at hand and minimally > usable for anything else. ...for the _allowed_ task at hand... > The fact that an end user can't tell the difference is a fault from the > *security* side. I'd say the security flaw goes a bit deeper than that... it's extremely difficult to define policy. Flexibility in the security configuration has a corresponding exponential increase in complexity in determining the security configuration. > Most of the applications are trying desperately to be > usable and play by the security rules. The fact that the applications > programmers cannot query the local security environment to make things > better for the user is what creates the security/usability tradeoff. Querying the local security environment is quite possibly the wrong approach. If you can tell what your security environment is, there is already a problem, as it can only get worse. I'm *very* queasy about the ability of programs to query for their effective uid. Sure, it makes for "more usable" software in that a program can check to see if it's running as uid 0... but it would be better if it Just Didn't Care. Likewise, I'd be kinda queasy about a program being able to ask the firewall(s) "what ports are allowed through to me, and from where?" Good security should enforce separation... [snip] > >The obvious approach, I think, would be to build a NAT-control library, > >like termcap and terminals. "Tell me what sort of NAT device you have, > >and where it's at." A beneficial side-effect would be to allow for the > >development of a set of open-source NAT-management tools built on top > >of such a library. > > Yes! That would be *fine*. However, no one from the land of security > has stepped forward to do the work required. Presumably it would be an > extension to SNMP. SNMP? Most of 'em appear to have web-based interfaces -- not even https. A little sniffing, and perhaps we can start building up a vocabulary for configuring NATs. Perhaps we can start with building a couple of remote drivers, and once we have a couple of NAT devices configurable, we can abstract out the common behavior (reset, reboot, pass-through-this-port-to-that-box) and define the interfaces to make it pluggable. > Until then, we are stuck with subverting NATs. :( I really am unhappy with subversion as a solution. (I've seen this a lot with firewalls. The users do stupid things, trash their machines, so IT comes in, cleans up the mess, passes out red hands, and tightens the screws. Users cry out in pain, demand Javascript, ActiveX, Outlook, IE, AIM, executable attachments, etc., and look for ways to subvert the system. And then blame the IT folks when their virus- and trojan- laden systems fall over, again. "You should prevent this!") [snip] > >By "active owner", I take it that you mean someone who explicitly allows > >incoming connections through a firewall? > > No, I mean owner with clue. One who doesn't say "Own my NAT, please!" > One who explicitly chooses the policy on the NAT rather than pulling it > out of the box, plugging in the cables, and never touching it again. Ah! Okay. So we have a tiny bit of common ground? What we need is a NAT-control abstraction mechanism, so that the clueful "active" owner can maintain a modicum of control with one tool, no matter what device they're using that week, and the "passive" owner can hand off administration of his NAT device to the developers of the software he runs. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
