OpenBSD Sparc64 on Sunfire V120

OpenBSD works amazingly well on "our" new SunFire V100 hardware.

With my pre-existing netboot buildout, doing a network installation on the SunFire was quick and easy -- faster than the Solaris network installation, if not quite as self-completing as my "fire and forget" firewall build boot :)

There are a number of security enhancements inherent in OpenBSD by which we can justify this admittedly unusual choice of operating system for DNS and other specialized applications where security is more important than "normalization"

Kevin


(P.S. FreeBSD 5.0 for Sparc64 supports most of the same modern Solaris systems as OpenBSD (Oddly, no Ultra-2 SCSI support, but FreeBSD does work on E220/E250) and offers SMP support for systems that have multiple CPUs)

Sudo advocacy

Some additional comments on the subject of "sudo" (http://www.courtesan.com/sudo/).

Sudo (Super User Do) is a popular solution for Unix access control, permitting regular users to run certain commands as root or as a role account, without the risks of shared passwords, and without the need for users to memorize yet another password. On many of my personal Unix systems, "sudo" is the only file with "setuid root" permission!

Has there been any consideration of the option to use the advanced (http://www.courtesan.com/sudo/intro.html) features of the "sudo" package? For example, maintaining a single global "sudoers" file on a (secure) central management host, "pushing" copies of this single standard configuration file to all managed Unix servers?

Use of a single global, centrally-managed "sudoers" file offers numerous advantages:

• Simplifies changes that affect many servers, including adding and removing access to commands and user access (allowing for near instantaneous hire/fire access updates).
• Grouping of users, of hosts, and of commands allows discrete access control from a single global file.
• This type of centrally-controlled "sudo" deployment on Solaris is used at many large corporations, including Lockheed Martin.
• Without the need for users (or even most administrators) to know the root password, this password can be stored more securely, and "root" can be a restricted "role" account under Solaris 8 RBAC.
• One single file to audit for access control of root and role account commands for all hosts.
• Automatic generation and reporting of command audit trails, locally and/or to a central log host.

I am aware of a few drawbacks, including the reasons Data Security uses this approach for other configuration files, but not for "sudoers":
Compromise of any host which uses the global "sudoers" file exposes sensitive information about the purpose, users, and access controls on other hosts using the same "sudoers" configuration.
Compromise of the central management host may make it easier to compromise the client hosts.
Effective security requires recompiling "sudo" to use SecurID authentication instead of passwords.

Automatic updating of the "sudoers" file on large numbers of remote hosts can be accomplished in a number of ways. Through the use of "ssh" and "rsync", changes to the global configuration can be distributed, via either "push" or "pull" scripting, quickly and efficiently.