GitLab

containers.

tables for disable, since that would wipe out the rules for
domUs too.

reload.

This is because at different times, users in different subgroups can
create an experiment with the same name. If the directory has the
unix group of the initial experiment with that name, then any other future
experiment with that name but in a different subgroup will not be able
to write the directory.

This differs from the current firewall support, which assumes a single
firewall for an entire experiment, hosted on a dedicated physical
node. At some point, it would be better to host the dedicated firewall
inside a XEN container, but that is a project for another day (year).

Instead, I added two sets of firewall rules to the default_firewall_rules
table, one for dom0 and another for domU. These follow the current
style setup of open,basic,closed, while elabinelab is ignored since it
does not make sense for this yet.

These two rules sets are independent, the dom0 rules can be applied to
the physical host, and domU rules can be applied to specific
containers.

My goal is that all shared nodes will get the dom0 closed rules (ssh
from local boss only) to avoid the ssh attacks that all of the racks
are seeing.

DomU rules can be applied on a per-container (node) basis. As
mentioned above this is quite different, and needed minor additions to
the virt_nodes table to allow it.

and into the js files associated with the code.

It's going to be used by both OSinfo and Node objects.  New OSes will
want to inherit taint states from the OS they are derived from.

Firewall needed to be taught about the vnode control net (172.16.0.0).
Basic stuff works now. Haven't tested everything.

Unrelated to this commit, the Linux firewall seems to be broken.
No traffic flows between the inside and outside even in an "open"
configuration. Needs investigation.

Required rearranging some things in the script to accomodate an action
that only requires one additional argument.

This will currently work with os descriptors and nodes.

Can't do the untainting for all cases in libosload*.  The untainting
is now hooked into stated, where we catch the nodes as they send
along their "RELOADDONE" events to update their taint state according
to the final state of their partitions.

Emulab can now propagate OS taint traits on to nodes that load these OSes.
The primary reason for doing this is for loading images which
require special treatment of the node.  For example, an OS that has
proprietary software, and which will be used as an appliance (blackbox)
can be marked (tainted) as such.  Code that manages user accounts on such
OSes, along with other side channel providers (console, node admin, image
creation) can key off of these taint states to prevent or alter access.

Taint states are defined as SQL sets in the 'os_info' and 'nodes' tables,
kept in the 'taint_states' column in both.  Currently these sets are comprised
of the following entries:

* usermode: OS/node should only allow user level access (not root)
* blackbox: OS/node should allow no direct interaction via shell, console, etc.
* dangerous: OS image may contain malicious software.

Taint states are inherited by a node from OSes it loads during the OS load
process.  Similarly, they are cleared from nodes as these OSes are removed.
Any taint state applied to a node will currently enforce disk zeroing.

No other tools/subsystems consider the taint states currently, but that will
change soon.

Setting taint states for an OS has to be done via SQL presently.

needed to be, because of how the javascript code uses the selector
array. I kludged it for now, but needs more work.

BUSY errors in Terminate(), and retry (for a while).

deal with resource busy errors properly.