This discussion seems to be spiraling far beyond where it started,
and I'm not sure we need to go this far to resolve my original
questions.
There's been a lot of concern expressed about the ability of services
(dhcp is one example) to override explicitly stated policy created by
the user, by having per-socket policy overrides built into them. I
think there are two central questions there: one, should NWAM use a
combination of a "block everything" ipsec policy and per-socket policy
overrides for select services to bootstrap itself; and two, should
per-socket policy overrides be possible at all. In answer to the
first, I'm perfectly willing to say there are legitimate concerns
about that approach, and so we're not going to take it. The second
is simply not a question that the NWAM project is going to address.
So, are there opinions or concerns about option 1 or 2? As a reminder,
they were:
1) create ipsec rules that only allow packets related to the needed
services through
2) create ipfilter rules that do the same
And the problem I was trying to solve was how to have security policy
in place before the information needed to decide which of the user's
location profiles to put in place was available, since the user-defined
security policy is contained in the location policy.
I think either of these can better address concerns about respecting
the admin's preferred security policy. First, the default locations
may be modified by the user. If the user wants NWAM to always use
static addresses and always block dhcp traffic, the no-net location's
security policy could be modified to enforce that.
For the case where the admin installs a security policy, and is not
aware of what NWAM is trying to do, we should also ensure that neither
of the default (automatic and no-net) NWAM locations will override
existing (user-installed) security policy. The automatic location
specifies no security policy (allow everything), and the no-net
location would specify policy to block everything except traffic
NWAM believes it needs to do its job; but both should defer to
existing, legacy policy. This of course means that if the user
installs policy that prevents NWAM from doing its job, the network
won't get configured; at that point, it would be up to the admin
who put the security policy in place to decide how they expect the
network to be configured, and modify either the security policy or
the NWAM config as needed to make that happen.
Comments?
-renee
