Stewart Stremler wrote:
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...
This is a breakdown in abstraction.
I want to ask the environment:
Where can I put this data?
How much data can I put there?
Can you give me an Internet facing connection?
Will you identify that connection, please?
etc.
Suddenly, those concerned about their security can set things up so that
the response: "Rejected" comes flying back. Now the user software can
stop and inform the user that an explicit security policy has blocked them.
As things currently stand, the response is more along the lines of
"Denied". Unfortunately, a zillion things can result in "Denied". The
wireless network is overloaded, DHCP crashed, the NAT is out of memory
or ports, the foreign computer is down, the port it wants is already
mapped, the bandwidth is overloaded, the routers all died, etc.
The application programmer has no idea whether to keep trying or to
stop. If the program stops too soon, it gets called brittle. If it
continues too aggressively, it gets called malware.
I actually have this issue with Java Web Start. The normal sandbox is
horribly restrictive, but a fully signed certificate is far too permissive.
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!")
And the cycle begins anew.
The problem lies on both sides. Setting new security policies is
responsibility. Corporate managers are rewarded for *avoiding*
responsibility. Therefore, IT chooses "default deny" and then is very
slow to open anything.
Eventually, the users need to get work done and punch through the
blockage. Since this is done stupidly, it opens up nice big gaping
holes which can be exploited. In come the worms, trojans, etc. IT gets
called in to clean up the damage.
Lather, rinse, repeat.
As someone who once cleaned up /usr/local in a system which had been
around for 4+ years, I can tell you *LOTS* about the politics involved.
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.
All I want a NAT to answer are two simple questions:
1) Will you give me an Internet facing IP/port?
2) What IP/port did you give me?
Even "Request Rejected" would be an improvement on what we have now. At
least then I can stop trying to subvert things and tell the user.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
