[Argh... Hit send before the end.]
A common, good security model is:
Big bad Internet <==> Outer Firewall <==>
DMZ <==> Inner firewall <==> Corp. Server subnet <==>
User firewall <==> Corp. User subnet
And a seperate subnet for management interfaces. To allow ops to control the
net, there is a really hardened login server with login interfaces on the DMZ
and corp users subnets and which forwards sessions to the management subnet. It
should have two-factor auth, a very limited set of allowed users, etc.
----
An "appliance" is a single-purpose box with limited capabilities, such as a
file server, print server, logging server, console server, etc. It should be
very stripped down--crude or no graphics, primitive editing, very few daemons.
A "server's server." I wouldn't classify anything with a "desktop" version of a
package as an appliance.
Good dom0's don't need anything other than Xen daemons, HW monitoring daemons,
and maybe a log file rotator. All of this must be run as root. Adding any
other, unnecessary users lessens security. Since all processes are root,
putting the password in a separate file is pointless; it's still readable by
root. Getting rid of shadow files also allows you to get rid of vipw and vigr,
elimininating two more potential sources of bugs. vulnerabilities, and updates.
In this case, adding a shadow file will not actually increase security. The
best it could do would be to provide "check the box" "warm and fuzzies" for
people who do not understand shadow's purpose. As such, it would be a _false_
sense of security. This may be the case here; "if I have shadow files, then
it's safe to expose the dom0 login to the bare internet."
----
Sorry for the long-windedness :)
--
Michael South
msouth@xxxxxxxxxx
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home