On 07/ 6/10 11:07 PM, Dave Miner wrote:
William, a few comments/questions in line. Overall I think we're
getting near a workable answer.
On 07/ 2/10 12:59 PM, William Schumann wrote:
SC Manifest Security
The SC manifest includes system configuration information that can be
considered sensitive to users, and perhaps none more so than the root
password. Under AI, the SC manifest is transmitted over the network.
There are some basic security vulnerabilities:
-File and directory protection attributes should be set so that the SC
manifests on the AI server cannot be read by 'everyone', i.e.,
unauthorized users of Solaris on the AI server computer.
-The SC manifests can presently be downloaded by anyone who can properly
formulate the HTTP request; in a web browser, for example.
-Although passwords are encrypted in SC manifests, they can be decrypted
with some effort.
-There is no network encryption.
-There is no way to authenticate either the client or server; i.e.,
certify identities of either client or server to each other.
A basic list of important security features includes:
- encryption - nullifies net snooping and exposing user account
information in the SC manifests on the network
- server authentication - the AI client is guaranteed that the SC
manifest is from the intended AI server (no accidental or falsified AI
servers)
- client authentication - the AI client must provide proof to the AI
server that it is authorized to receive the SC manifest
One thing here is that, if the manifests are only supplied to clients
whose criteria match, that would seem to cover us in a basic sense
even without all the crypto and authentication additions (and thus
provide protection against manifest harvesting). Or is there an issue
I'm not seeing?
It depends on the user's security concerns. The criteria can be
falsified through spoofing, and can be accidental, particularly in the
case of virtual machines with virtual MAC addresses. Encryption is
useful to protect against snooping on the network. The encryption and
authentication might be more strict than some users need, in which case
they can just dispense with authentication and encryption entirely by
disabling it in wanboot.conf.
- guaranteeing integrity of the data - the SC manifest cannot be altered
in any way during transmission
AI uses the HTTP protocol to download. The typical security enhancement
for this model is HTTPS, or SSL/TLS.
The SPARC wanboot program supports the full range of requirements for
network security listed above, through:
- hash digests, which both insure data integrity and provide client
authentication
- encryption keys, which conceal the SC manifests in transit
- certificates, which can be used on the client and server for two-way
authentication
It was designed and implemented with high security standards. AI
presently uses wanboot for SPARC, but only to fetch the bootfile, and it
does not make use of its security features. It seems logical to leverage
this established software.
What does wanboot do?
http://docs.sun.com/app/docs/doc/821-0439/wanboottasks2-82?l=en&a=view
http://docs.sun.com/app/docs/doc/817-5504/6mkv4nh75?l=en&a=view#waninstalltasks-9
To provide two-way authentication for SPARC, wanboot requires a key and
a hash value to be input by the user on the client. Here is an example
of OBP being used to permanently store the hash digest and encryption
key:
ok set-security-key wanboot-hmac-sha1
b482aaab82cb8d5631e16d51478c90079cc1d463 - HMAC hash digest
ok set-security-key wanboot-3des
9ebc7a57f240e97c9b9401e9d3ae9b292943d3c143d07f04 - private key
What does IPS do?
What IPS does is interesting as a possible model for SC manifests, and
also because the installer would have to provide authentication
information for secured package repositories. IPS supports HTTPS
security, allowing the user to specify a key and a certificate with an
image for two-way authentication. For example, the key and certificate
for the OpenSolaris 'extra' repository are available online; the user
must establish an account to gain access. Although the same in SSL
principles, functionally it differs from the key and hash digest entry
used in wanboot in that the key and HMAC must first be extracted.
Proposed:
Propose a client authentication system resembling the /etc/netboot
hierarchy, where keys and certificates are placed on the server in
locations that protect files in that directory and all subdirectories.
Top-level keys and certificates protect everything under them. Keys and
certificates at a path identifying a corresponding to AI service (or
custom client) protects the AI service (or custom client). For example,
in wanboot, to protect a particular MAC address on a particular network,
the keys and certificates are placed on the netboot hierarchy at:
/etc/netboot/<net ip>/<CID>, where CID, or Client ID, is "01" + MAC
address. A new hierarchy is proposed that is based on AI services
(rather than network IP): <service name>/<CID>
I'm not sure this maps exactly to the Image Management design. In
particular, I'm modifying wanboot-cgi to allow client configuration to
be service-independent, thus allowing /etc/netboot/<CID> to be global
for a given client. Do we actually need your proposed <service
name>/<CID> in that scenario? I don't think so, but again, perhaps
there's a reason I'm missing.
In that case, the CID directory could be at the same level as the
service directory. Note that this would not change the search order:
1) CID
2) AI service default
3) AI server default
Also proposed is to modify wanboot:
- adding cross-platform support
- add SC manifests to the wanbootfs, whose transmission is secured
Advantages of leveraging wanboot:
- time-tested
- supports high level of security as well as encryptions that are more
difficult to decrypt without keys
- hash digest computation is optimized
Disadvantages of leveraging wanboot:
- ON consolidation, not install consolidation
- must add x86 support, although research indicates that the SPARC-only
wanboot code is mostly high-level, and lower level code is supported
cross-platform
- encryption options limited to 3des and aes key types
- only sha1 hash supported
- perhaps more maintainable, extensible, flexible with more code modules
to leverage if rewritten in Python
- receipt of wanbootfs would have to be decoupled from ramdisk code
under SPARC to instead write the wanbootfs (hsfs) to /tmp for x86
- client cannot presently submit a certificate as for IPS - the key and
HMAC must first be extracted
I'm not sure I understand exactly how you'll leverage the existing
wanboot program. It's a standalone second stage boot loader for
SPARC, so it seems like you'd have to rebuild it for x86 as a userland
program?
Yes, that would be the plan. As indicated above, most of the code is
platform-independent - only the highest-level code (wanboot.c) is
SPARC-only. How this would be done within the existing ON consolidation
source framework without replicating code might be considerably more
difficult than coding it separately in the install consolidation in Python.
As an aside, I expect we'll have to look at enhancing wanboot to
support a stronger hash than SHA-1.
OK. That supports the notion that a more flexible solution offering a
wider variety of selectable ciphers may be in order.
To be considered: command set for managing keys and certificates for
client and server authentication. wanboot-cgi requires that this be done
manually, offering tools to help in the process (wanbootutil(1M)), but
they only do creation and extraction and there are no tools for listing
the hierarchy or deleting keys and certificates.
This would be part of installadm, right?
I was thinking of adding the support to wanbootutil(1M), although it
might be simpler to do from installadm with a similar set of
subcommands: keygen, keymgmt, p12split.
To be considered: what methods for the installing user to provide key
and certificate information are feasible:
- hand-typing
- copying from or referencing removable media such as:
--- USB stick
--- bootable AI media
- copying from a secure network local to the AI client: wget, web
browser, NFS, scp
- secure authentication server - from console web browser, user supplies
password to receive certificate which can be used to fetch SC manifest
Any reason we wouldn't allow all of the above?
They can all be allowed. Means of providing keys or certificates to the
client can be considered orthogonal to security on the AI server.
Additional security notes
George Davis has been so kind as to post a menu-driven script to
automate and guide the user through generation, placement, and
extraction of the keys and certificates:
http://www.sun.com/bigadmin/jsp/descFile.jsp?url=descAll/solaris_wanboot_set
The notion of client authentication opens another possibility for SC
manifests and install security in general: a specific user can be
identified via the client certificate, and the user receives an SC
manifest based on that identity instead of other criteria, such as AI
service or MAC address. For example, if a client certificate is used for
a specific installing user, an SC manifest named after that user could
be automatically sent without the need for a custom client. This is not
proposed - just offered for consideration.
I think it's useful to consider, though wouldn't we need cert support
in OBP?
Not if the boot were restructured: first download the generic bootfile,
run it, then supply the certificate later. Neither the bootfile nor the
rootfs are encrypted presently.
HTTP GET request security: if the HTTP QUERY_STRING is used to send AI
client information, the information in that string must be evaluated in
terms of security, since the HTTP GET request can be snooped. If any
sensitive information is identified, the GET request must be issued via
HTTPS, which will affect such things as the URL specified in the -B
install_service kernel option in GRUB. If the QUERY_STRING is deemed not
sensitive but the SC manifest payload is sensitive, a simple redirection
from http->https can be done by the webserver.
Wouldn't this be covered by providing an https URL in the DHCP options
(or in the network-boot-arguments provided to OBP)?
Indeed.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
