On 10/ 4/10 09:30 PM, Dave Miner wrote:
On 10/ 4/10 02:47 PM, William Schumann wrote:
On 10/ 1/10 05:28 PM, Dave Miner wrote:
...
Delivering them simultaneously is perfectly fine, and as you can gather, I
think preferable. My point of view is that wanboot-cgi
has a quite suitable method already for delivering a bundle of content and
would like to see that leveraged, rather than inventing
yet another mechanism that is specific to system configuration.
Consider the simplicity of MIME as a way to bundle content.
...
I'm well aware that wanboot uses MIME to encode its entire message. I am not yet convinced that we shouldn't just be using its
already-implemented capabilities to return these, however.
Missing from wanboot-cgi:
- means of adding more files to wanbootfs
The proposal mentions an approach to adding a flexible means by which files could be added to wanbootfs, through naming a new entry
in wanboot.conf, specifying a script to locate the profiles and an output directory.
Missing from wanboot (client-side standalone program):
1) x86 support
2) gathering and sending AI client criteria (IP, hostname, memory size, MAC
address, cpu, platform) required for locating profiles
wanboot-cgi sends the wanbootfs in a custom format. This is a relatively small problem, until security is considered: the code to
authenticate and guarantee integrity processes wanbootfs byte-by-byte. An x86 wanboot client would be a user-mode application that
would be different from the SPARC wanboot, which writes the wanbootfs into a ramdisk, doing HMAC calculations on each byte.
Adding support for standalone wanboot to collect and send AI client criteria would be more difficult with Solaris missing. Instead
of attempting to gather criteria standalone, I think that a platform-independent user-mode version of wanboot that supplies the
criteria to wanboot-cgi that is called about the same time in the boot process that the AI manifest is fetched (possibly also
supplying the AI manifest) would be preferable.
Now, wanboot/wanboot-cgi has a big advantage in that it securely delivers the SSL certificates to the AI client. For this, the
user provides a HMAC and a key, totaling about 50 characters. An x86 solution (or for a SPARC box that does not support wanboot in
its OBP) would need some way to get the SSL certificates securely, and porting the wanbootfs fetch to a user-mode application would
accomplish this. (Alternate solutions for the client obtaining the security certificates include certificate server, providing
certificates on install media, reading certificates from removable media, copying certificates from locally secure source.)
Considering the work a Python-based server solution would be responsible for
(disregarding what is common to both approaches):
- client authentication referring to certificates on the AI server in a fashion
compatible with certificates in /etc/netboot
- some simple MIME encoding
The client side would also be a very simple script:
- leveraging Python modules httplib and urllib to form and issue the HTTP POST
- calling existing Python AI code to fetch client criteria
- leveraging the Python email module to unpack the profiles, saving them into
the new /etc/svc/profile.
On the subject of secure network booting from the x86 platform: It is mentioned in the gPXE project
(http://etherboot.org/wiki/soc/2006/derekpryor/proposal) but I didn't see any follow-up on the proposal from users, and it is
unclear how it has been used and tested. So a completely secure x86 network boot seems a future endeavor.
What I can see is that Python scripts leveraging SSL using openssl would offer a very simple, platform-independent solution using
the standardized portions of wanboot. All authentication and encryption would be handled at the SSL socket layer and would be
transparent to both the client and server.
What is less clear to me is how much coding to extend this SPARC-customized
solution to x86 would require.
Also, there is the question of how much to invest in a platform-independent means of AI delivering SSL certificates with the user
providing HMAC and key: how much is this feature worth?
So to recap, to securely deliver profiles, I would propose either:
1) a simple Python client/server solution, obtaining SSL certificates through
other methods, or
2) porting the wanbootfs-fetching client side of wanboot to a cross-platform user-mode application, and adding support to
wanboot-cgi to add in profiles written into wanbootfs on the server side by a profile locator script
Given:
- considerable code porting (SPARC->x86, standalone->user-mode)
- efforts to make code build platform-independent
- the limitations of having a real secure PXE network boot in the first place
- uncertain demand for certificates going to the x86 platform via entering HMAC
and key when other alternatives exist
I would support the Python solution (1) at this time.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
