On 05/13/10 07:32 PM, Edward Pilatowicz wrote:
On Thu, May 13, 2010 at 04:10:05PM -0700, Darren Reed wrote:
On 13/05/10 01:29 PM, [email protected] wrote:
Rishi Srivatsavai is looking into the work entailed to have mac-nospoof
enabled for NGZ by default.. just talked to Rishi, and I think it makes
sense, as part of that work, to also ensure that the mac address cannot
be changed by ifconfig.
It really doesn't matter what controls you put on changing any
address via ifconfig if hostile behaviour is your concern. As long
as I can open a raw socket for a NIC, I can pump whatever I like
down the wire. To that end, the "allowed-ips" and "mac-nospoof"
filtering in mac are required to prevent hostile behaviour from
the local zone because they both actively filter all packets
transmitted out of the NIC. This is why I earlier asked about
whether or not net-rawaccess could be revoked for such zones.
as far as i can tell, if "allowed-ips" and "mac-nospoof" are used to
restrict the ip and mac addresses that a zone can use then that's good
enough. removing net-rawaccess would be unnecessary because it wouldn't
buy us any more protection else. removing net-rawaccess would actually
reduce the available functionality in the zone unnecessarily. (for
example, the zone could no longer run snoop.)
Yes, and I also look at this from a resource management perspective. If
I explicitly assign an IP address and a MAC address to a zone, then it
implies that I don't want processes in that zone to steal (intentionally
or not) the resources of another zone or system and "spoof" another zone
or system by using a different address. At least then, if anything does
happen on a network as a result of packets transmitted from the zone, it
will be accountable. I don't see this as a "hostile behaviour"
prevention mechanism, as that problem isn't solvable; it's not a bounded
problem at all if you allow any bits to flow out of the confines of the
zone's environment.
Generally, the scope of the allowed-ips and mac-nospoof protection
settings is indeed simply to prevent spoofing, and not to prevent all
possible network-based malicious attacks, so those are appropriate
mechanisms to accomplish the above goal. This case (and the future case
that will propose to enable mac-nospoof for links assigned to non-global
zones) is partly about automating the configuration of these settings in
a way that they were originally intended (and providing appropriate
administrative error semantics).
-Seb
_______________________________________________
opensolaris-arc mailing list
[email protected]
