security review of Serviceability spec

I realize that it's getting late in the process, but better late than
never (<insert various work-related excuses here>)... 
I've looked at the Serviceability spec (cglreq_v30_draft5_Serv.doc) from
a security point of view and have the following comments/questions: 
SVC.1.1 Remote Management Standards :
	The description section should explicitly specify version 3 of
SNMP (SNMPv3).

	There are many ways to create a more secure SNMP configuration
using SNMPv3 but rather than try to specify how an admin might want a
system configured it is more appropriate to simply require a secure
default setting and if/when the admin makes changes assume that he/she
knows what he/she is doing.  IMO, there are two options for a secure
initial SNMP configuration:  off with no user prompt and user prompt
with secure defaults.  In the latter case, the admin would be required
to enter some information (username, password, etc.) at firstboot or
install time but the defaults provided would be fairly secure (i.e.
authentication and privacy enabled).  This has the advantage of making
the system SNMP capable without the admin having to explicitly configure
it after the fact.  The option of SNMP off doesn't require the user to
enter any info at firstboot or install but still leaves the system
secure (since SNMP would be disabled and thus not exploitable).  It has
the benefit of avoiding the temptation of the admin to just enter
anything during firstboot/install to get going and thus possibly
weakening the security (what I'm worried about is the admin picking a
weak password or other just-to-get-by choice).  By forcing the admin to
explicitly go and configure SNMP, presumably she/he would take more time
to configure it correctly.

	In my past life working on network management software it was
the case that there were two types of admins in most large companies,
system and network.  I would expect that SNMP would mostly be used by
the network admins, as there are much better choices for system
administration.  Thus, it would seem like the SNMP configuration would
be best done by a network admin or in consultation with a network admin,
which I wouldn't expect to be done at firstboot or install time.  So, I
think that a requirement should be added that SNMP is disabled by
default.

SVC.1.7 Diagnostic Monitoring Framework:
	Most of the sub-items do not expose any sensitive information
and so simply reading their values over an un-authenticated,
un-encrypted connection should not pose any security risks.  However,
the CPU Diagnostic Monitoring (SVC.1.7.6) and Memory Diagnostic
Monitoring (SVC.1.7.7) items do expose process and thread information.
Such information could be used by attackers to determine systems with
vulnerable software and/or systems with high-value data (e.g. if it is
running a database or has a hardware security module).  I think that
most administrators would want this diagnostic information to be
protected by authentication and encryption (and you could toss in
integrity and auditing for good measure).  Since it is the remote aspect
of this that has security issues and local PoCs exist
(http://linux-diag.sourceforge.net/), I'd recommend that a requirement
be added that remote access to diagnostic information requires an
authenticated and encrypted transport and that ssh be used as the PoC
(run the local tools over a remote secure shell).

SVC.2.1 Remote Package Update and Installation:
SVC.2.3 Version and Dependency Checking via RPM:
	A requirement should be added that remote update requires that
all update functionality (query, update command, data, etc.) must be
performed over a secure connection (authentication, integrity, auditing,
maybe encryption).  I would expect that this can be satisfied by running
existing update software over secure transports (SSL/TLS/ssh/etc.).
Note that this is not requiring that the update content be verified
(e.g. checksum'ed, signed, etc.)--that would be for a different spec.

	SVC.2.4 addresses the logging aspect (though it should specify
that the log will be secure as defined by the security spec).  It also
implies that the remote updates are authenticated.

SVC.3.2 Live Kernel Remote Debugger:
	The requirement should state that remote debugging must be
performed over a secure transport.

_______________________________________________
cgl_discussion mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/cgl_discussion