John Danielson writes:
> 2. Domains service
>
> Solaris zones provides a simple transient service that allows autobooting
> of zones when the control plane (global zone) is booted, and graceful
> shutdown at shutdown/reboot time. In a similar fashion this amendment is
> for the tr
James Carlson writes:
> Norm Jacobs writes:
>> James Carlson wrote:
>> > What about Avahi?
>> >
>> Most of the printers that I have come across don't support mDNS. A
>> couple of the newer ones that I have tested with do. I am looking at
>> incorporating it as a discovery method. mDNS suppor
On Thu, Aug 30, 2007 at 08:30:46AM +1000, Boyd Adamson wrote:
> It seems that a similar thing may be of interest with Xen
> domains. Perhaps an implementation where each domain is an instance of
> svc:/system/xctl/domains could allow dependencies? e.g.:
>
> svc:/system/xctl/domains:domain-a
> svc
John Plocher wrote:
> Danek Duvall wrote:
>> in our environment, would all 5000
>> printers show up, or some subset of those?
>
>
> I assume that, like today, if the user has a ~/.printers file,
> its "all:" entry will be used. If this is done naively, it could
> completely hide any auto-discov
On Thu, 2007-08-30 at 10:34 +0100, Darren J Moffat wrote:
> 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.
So we're ok at the transport layer, but I think we also need an
applicati
Bill Sommerfeld wrote:
> On Thu, 2007-08-30 at 10:34 +0100, Darren J Moffat wrote:
>
>> 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.
>>
>
> So we're ok at the transport
> > 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
> understa
> So we're ok at the transport layer, but I think we also need an
> application-layer analysis.
I suspect even with TX.
> At least some of what people send to printers tends to be sensitive.
And for TX, I'd hope this is covered. How does this project relate
to TX? Do
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 th
On Thu, 2007-08-30 at 07:52 -0700, Gary Winiger wrote:
> 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).
The SBD policy is higher level than that,
Artem Kachitchkine wrote:
> An example network attached printer entry looks remarkably like this:
>
> udi = '/org/freedesktop/Hal/devices/network_attached/192_168_0_15'
What would happen if a user has a printer at work at (private) IP
address 192.168.0.15, and has a completely different print
Erik Nordmark wrote:
> Artem Kachitchkine wrote:
>
>> An example network attached printer entry looks remarkably like this:
>>
>> udi = '/org/freedesktop/Hal/devices/network_attached/192_168_0_15'
>
>
> What would happen if a user has a printer at work at (private) IP
> address 192.168.0.15, and
Darren J Moffat wrote:
> 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.
I defer to your expertise :-)
My concern was one of 2nd-order exposure:
I (the bad guy) place a box on the
Gary Winiger wrote
>
>
>> At least some of what people send to printers tends to be sensitive.
>>
>
> And for TX, I'd hope this is covered. How does this project relate
> to TX? Does HAL run in each of the labeled zones and pick up
> network printers at that label?
Ar
John Plocher wrote:
> Darren J Moffat wrote:
>> 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.
>
> I defer to your expertise :-)
>
> My concern was one of 2nd-order exposure:
>
>
Norm Jacobs writes:
> John Plocher wrote:
> > Darren J Moffat wrote:
> > Q: is there anything I could do to you or find out about you at this
> > point, before any print jobs are sent?
> NO
Not quite true. You'll have an open UDP port to receive those SNMP
replies. If a Bad Guy on the network ca
>Norm Jacobs writes:
>> John Plocher wrote:
>> > Darren J Moffat wrote:
>> > Q: is there anything I could do to you or find out about you at this
>> > point, before any print jobs are sent?
>> NO
>
>Not quite true. You'll have an open UDP port to receive those SNMP
>replies. If a Bad Guy on the
On Thu, Aug 30, 2007 at 08:09:44PM +0200, Casper.Dik at Sun.COM wrote:
>
> >Norm Jacobs writes:
> >> John Plocher wrote:
> >> > Darren J Moffat wrote:
> >> > Q: is there anything I could do to you or find out about you at this
> >> > point, before any print jobs are sent?
> >> NO
> >
> >Not quite
Nicolas Williams writes:
> On Thu, Aug 30, 2007 at 08:09:44PM +0200, Casper.Dik at Sun.COM wrote:
> >
> > >Norm Jacobs writes:
> > >> John Plocher wrote:
> > >> > Darren J Moffat wrote:
> > >> > Q: is there anything I could do to you or find out about you at this
> > >> > point, before any print j
On Thu, Aug 30, 2007 at 02:22:07PM -0400, James Carlson wrote:
> Nicolas Williams writes:
> > What if the software uses only "connected" UDP sockets? Will UDP
> > datagrams sent to that port by nodes which are not the remote side of a
> > connected UDP socket elicit an ICMP?
>
> How are you going
Nicolas Williams writes:
> On Thu, Aug 30, 2007 at 02:22:07PM -0400, James Carlson wrote:
> > Nicolas Williams writes:
> > > What if the software uses only "connected" UDP sockets? Will UDP
> > > datagrams sent to that port by nodes which are not the remote side of a
> > > connected UDP socket eli
Casper.Dik at sun.com wrote:
>> Norm Jacobs writes:
>>
>>> John Plocher wrote:
>>>
Darren J Moffat wrote:
Q: is there anything I could do to you or find out about you at this
point, before any print jobs are sent?
>>> NO
>>>
>> Not quite true. You'll
Norm Jacobs writes:
>1. It doesn't send out a response to any queries on the network.
Just being open is enough. The fact that it's open is easily
detectable, because the system won't send back an ICMP Destination
Unreachable / Port Unreachable when a packet for that port is
received. Scanne
> This case was approved during today's PSARC meeting. Gary and I will
> work offline with Alan to update the spec in the case directory.
I've placed the spec the project team sent me in final.materials.
Gary..
James Carlson wrote:
> Norm Jacobs writes:
>
>>1. It doesn't send out a response to any queries on the network.
>>
>
> Just being open is enough. The fact that it's open is easily
> detectable, because the system won't send back an ICMP Destination
> Unreachable / Port Unreachable when
On Thu, Aug 30, 2007 at 05:09:44PM -0400, James Carlson wrote:
> Norm Jacobs writes:
> >1. It doesn't send out a response to any queries on the network.
>
> Just being open is enough. The fact that it's open is easily
> detectable, because the system won't send back an ICMP Destination
> Unre
26 matches
Mail list logo