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
- 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>
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
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.
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
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.
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.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
