PSARC/2007/499 Automatic discovery of network attached printers
James Carlson
james.d.carlson at sun.com
Thu Aug 30 08:50:13 PDT 2007
Gary Winiger writes:
>
> > > I'm a bit worried about the "out of the box" use-case; the usability
> > > of the system seems to be directly tied to this being on, yet network
> > > secure-by-default means that it probably should be off...
> >
> > I'm not sure that secure-by-default does require that this be off. As I
> > understand this case it is egress probing not a daemon listening of
> > ingress requests.
>
> The SMF policy requires that the manifest be delivered with
> services disabled. The SBD policy requires listening services
> be administratively enabled, or listen local only. Non-listening
> services (outbound only) may be enabled in the default profile(s).
This is one of the sticky parts of SBD. I don't think "outbound only"
makes a lot of sense in the context of UDP.
For this service, the daemon would end up establishing a listening
socket. It would then periodically send out broadcast "query"
messages to try to prod other systems into responding, but that
listening socket would always be open and always listening. A system
that wanted to could ignore (or just not wait for) the query and send
a packet destined for the open socket.
Is that an "outbound only" service, an "inbound" one, or something
else? I think many of those terms from SBD make some sense when
applied to TCP and to some particular application protocols, but
making sense of it in this context is difficult at best. That's why I
was so critical of SBD during the many reviews.
To comply with the letter of the SBD law, I believe this does need to
be shut down by default, and enabled only when requested. Yes, that
does mean that usability suffers at the hands of security, but that's
exactly what we signed up to do when we adopted SBD.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
More information about the opensolaris-arc
mailing list