|
Replies:
18
-
Last Post:
May 26, 2006 9:18 AM
by: philk
|
|
|
Posts:
42
From:
UK
Registered:
6/29/05
|
|
|
|
Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 9:29 AM
|
|
Hi,
I've made the draft for the PSARC fasttrack document available for
review here:
http://www.opensolaris.org/os/project/clearview/ipnet/fasttrack.txt
and would really appreciate any feedback on it. I'm setting a timer for
comments at one week (May 12th).
Thanks
Phil
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
Posts:
42
From:
UK
Registered:
6/29/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 9:39 AM
in response to: philk
|
|
One thing to note in the document is that the classification for the
proposed PRIV_NET_OBSERVABILITY is currently marked as XXX as details
for this are still being worked out.
Phil
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,468
From:
US
Registered:
6/15/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 9:57 AM
in response to: philk
|
|
On Fri, May 05, 2006 at 05:39:59PM +0100, Philip Kirk - Solaris Sustaining wrote:
> One thing to note in the document is that the classification for the
> proposed PRIV_NET_OBSERVABILITY is currently marked as XXX as details
> for this are still being worked out.
Should there be a different privilege for observing loopback vs.
non-loopback traffic?
I ask because it's a good assumption to make that everything you put on
the wire is visible to anonymous eavesdroppers (thus cryptographic
protocols), while the opposite assumption is generally made for loopback
traffic.
Now, if one does deploy appropriate cryptographic protocols then one
might want to grant the privilege for observing non-loopback traffic to
mere mortal users -- i.e., it should be possible to put one's money
where one's mouth is in regards to network security.
Nico
--
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,083
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 4:47 PM
in response to: nico
|
|
> > One thing to note in the document is that the classification for the
> > proposed PRIV_NET_OBSERVABILITY is currently marked as XXX as details
> > for this are still being worked out.
>
> Should there be a different privilege for observing loopback vs.
> non-loopback traffic?
We're not sure -- we've asked for Casper's thoughts on
PRIV_NET_OBSERVABILITY as a whole, but he's on vacation at the moment.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 5:23 PM
in response to: meem
|
|
Peter Memishian wrote On 05/05/06 16:47,:
> > Should there be a different privilege for observing loopback vs.
> > non-loopback traffic?
>
> We're not sure -- we've asked for Casper's thoughts on
> PRIV_NET_OBSERVABILITY as a whole, but he's on vacation at the moment.
Although I'm not sure, either, it's a very good question. Crossbow
is another project that will emphasize and proliferate the concept of
intra-machine traffic moving across internal virtual links, and it
does seem that there are very different security risks between that
and traditional networking. (I'm not saying that virtual links have
greater risks, just that they are so substantially different that
very different privileges are appropriate to observe them. Because
I may trust some data to move in the clear between zones/domains that
I wouldn't place in the clear on a wire, I may trust some people to
snoop at the wire who I don't want snooping my in-memory virtual
links.)
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,935
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 5:59 PM
in response to: mditto
|
|
Mike Ditto writes:
> Although I'm not sure, either, it's a very good question. Crossbow
> is another project that will emphasize and proliferate the concept of
> intra-machine traffic moving across internal virtual links, and it
> does seem that there are very different security risks between that
> and traditional networking. (I'm not saying that virtual links have
> greater risks, just that they are so substantially different that
> very different privileges are appropriate to observe them. Because
> I may trust some data to move in the clear between zones/domains that
> I wouldn't place in the clear on a wire, I may trust some people to
> snoop at the wire who I don't want snooping my in-memory virtual
> links.)
It's always been the case that local connections were more trusted --
not subjected to filtering, exempt from encryption paths, and even
handling credentials securely.
So, yes, adding observability here does sound to me like a potentially
substantial risk (e.g., a good way to expose passwords in the clear),
unless we can tie it into the permissions that the socket user himself
has.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot 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
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,468
From:
US
Registered:
6/15/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 9:04 PM
in response to: mditto
|
|
On Fri, May 05, 2006 at 05:23:06PM -0700, Mike Ditto wrote:
> Peter Memishian wrote On 05/05/06 16:47,:
> > > Should there be a different privilege for observing loopback vs.
> > > non-loopback traffic?
> >
> >We're not sure -- we've asked for Casper's thoughts on
> >PRIV_NET_OBSERVABILITY as a whole, but he's on vacation at the moment.
>
> Although I'm not sure, either, it's a very good question. Crossbow
> is another project that will emphasize and proliferate the concept of
> intra-machine traffic moving across internal virtual links, and it
> does seem that there are very different security risks between that
> and traditional networking. (I'm not saying that virtual links have
> greater risks, just that they are so substantially different that
> very different privileges are appropriate to observe them. Because
> I may trust some data to move in the clear between zones/domains that
> I wouldn't place in the clear on a wire, I may trust some people to
> snoop at the wire who I don't want snooping my in-memory virtual
> links.)
Loopback traffic is substantially different from non-loopback is this
way:
Noone wants to bother with crypto over loopback -- that's a waste of
resources.
The converse, that one badly wants to bother with crypto over
non-loopback follows from the assumption that anything other than
loopback is not secure from eavesdroppers.
I'd like us to be able to push this assumption to its limit: make the
system configurable so any local user can snoop non-loopback traffic,
and *only* non-loopback traffic.
Nico
--
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,468
From:
US
Registered:
6/15/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 9:20 PM
in response to: nico
|
|
On Fri, May 05, 2006 at 11:04:37PM -0500, Nicolas Williams wrote:
> I'd like us to be able to push this assumption to its limit: make the
> system configurable so any local user can snoop non-loopback traffic,
> and *only* non-loopback traffic.
^
, while only privileged users could
snoop loopback traffic.
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
638
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 8, 2006 1:21 PM
in response to: meem
|
|
Peter Memishian wrote:
> We're not sure -- we've asked for Casper's thoughts on
> PRIV_NET_OBSERVABILITY as a whole, but he's on vacation at the moment.
Isn't "observability" a bit too broad here? I would assume observability
includes packet counters (e.g., netstat -i) in addition to being able to
look at the packet content.
I suspect for snoop-type activity we might over time need a range of
visibility, just as I suspect we'll need a set of privileges around
being able to send different degrees of raw packets.
One way of approaching this is to define a small set of "raw" privileges
that can separately capture being able to observe/receive and being able
to transmit.
Another way is to think of both observe/receive and transmit "raw" as a
set of filters (IPFilter extended to support MAC layer filtering and ARP
could be one implementation). The filtering approach is certainly more
general, but begs the question of what the default behavior/filter
should be.
Erik
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,468
From:
US
Registered:
6/15/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 8, 2006 3:08 PM
in response to: nordmark
|
|
On Mon, May 08, 2006 at 01:21:58PM -0700, Erik Nordmark wrote:
> Peter Memishian wrote:
>
> >We're not sure -- we've asked for Casper's thoughts on
> >PRIV_NET_OBSERVABILITY as a whole, but he's on vacation at the moment.
>
> Isn't "observability" a bit too broad here? I would assume observability
> includes packet counters (e.g., netstat -i) in addition to being able to
> look at the packet content.
Looking at counters does not typically require privilege, but maybe it
should require some basic privilege, as counters might leak useful data.
> I suspect for snoop-type activity we might over time need a range of
> visibility, just as I suspect we'll need a set of privileges around
> being able to send different degrees of raw packets.
Well, if you mean ICMP ECHO REQUEST/REPLY, having a syscall (socket?)
interface to do that would save us the bother with privileges for
distinguishing those types of packets from other uses of raw networking,
no?
> One way of approaching this is to define a small set of "raw" privileges
> that can separately capture being able to observe/receive and being able
> to transmit.
Sending and receiving are different things. And for loopback, does
anyone ever want to be able to send packets using a rawip socket? Why?
Because of missing non-raw interfaces or for fault injection?
Anyways, for me the bottom line is: someday have two privileges for
snooping, one for loopback and one for non-loopback. It's hardly an
urgent matter, but getting this right now may save privilege-splitting
headaches later.
Nico
--
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
638
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 9, 2006 11:43 AM
in response to: nico
|
|
Nicolas Williams wrote:
>> Isn't "observability" a bit too broad here? I would assume observability
>> includes packet counters (e.g., netstat -i) in addition to being able to
>> look at the packet content.
>
> Looking at counters does not typically require privilege, but maybe it
> should require some basic privilege, as counters might leak useful data.
My comment was merely that the name for the privilege seems a bit too broad.
>> I suspect for snoop-type activity we might over time need a range of
>> visibility, just as I suspect we'll need a set of privileges around
>> being able to send different degrees of raw packets.
>
> Well, if you mean ICMP ECHO REQUEST/REPLY, having a syscall (socket?)
> interface to do that would save us the bother with privileges for
> distinguishing those types of packets from other uses of raw networking,
> no?
For sending "raw" I can see many different degrees of raw. A
non-exhaustive list:
- being able to send packets with different IPPROTO than TCP, UDP, ICMP
- being able to send IP packets with an arbitrary IP source address,
with an arbitrary IP ident field (IPPROTO_RAW allows this)
- being able to send datalink packets with arbitrary Ethernet type,
arbitrary Ethernet source address
- being able to send Ethernet packets with bad CRC
> Sending and receiving are different things. And for loopback, does
> anyone ever want to be able to send packets using a rawip socket? Why?
> Because of missing non-raw interfaces or for fault injection?
SOCK_RAW is used by ping, and I'm sure some people ping another zone.
> Anyways, for me the bottom line is: someday have two privileges for
> snooping, one for loopback and one for non-loopback. It's hardly an
> urgent matter, but getting this right now may save privilege-splitting
> headaches later.
I agree that two separate privileges for packet capture makes sense.
Erik
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,468
From:
US
Registered:
6/15/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 9, 2006 12:09 PM
in response to: nordmark
|
|
On Tue, May 09, 2006 at 11:43:38AM -0700, Erik Nordmark wrote:
> Nicolas Williams wrote:
> >>Isn't "observability" a bit too broad here? I would assume observability
> >>includes packet counters (e.g., netstat -i) in addition to being able to
> >>look at the packet content.
> >
> >Looking at counters does not typically require privilege, but maybe it
> >should require some basic privilege, as counters might leak useful data.
>
> My comment was merely that the name for the privilege seems a bit too broad.
Ah.
> >Well, if you mean ICMP ECHO REQUEST/REPLY, having a syscall (socket?)
> >interface to do that would save us the bother with privileges for
> >distinguishing those types of packets from other uses of raw networking,
> >no?
>
> For sending "raw" I can see many different degrees of raw. A
> non-exhaustive list:
> - being able to send packets with different IPPROTO than TCP, UDP, ICMP
Yup, this one I expect to be useful in loopback situations.
> - being able to send IP packets with an arbitrary IP source address,
> with an arbitrary IP ident field (IPPROTO_RAW allows this)
This too, particularly given Crossbow. (Hmmm, the ability to simulate
large networks using Zones is appealing, isn't it?)
> - being able to send datalink packets with arbitrary Ethernet type,
> arbitrary Ethernet source address
> - being able to send Ethernet packets with bad CRC
Not useful in loopback situations ever, I think, or am I missing
something.
> >Sending and receiving are different things. And for loopback, does
> >anyone ever want to be able to send packets using a rawip socket? Why?
> >Because of missing non-raw interfaces or for fault injection?
>
> SOCK_RAW is used by ping, and I'm sure some people ping another zone.
Yes, but I'm still mystified as to why there is not a better API for
ping all these years later.
> I agree that two separate privileges for packet capture makes sense.
Cool.
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,114
From:
Registered:
6/8/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 2:03 PM
in response to: philk
|
|
On /dev/lo0.
Why are we fabricating the ethernet header rather than having
snoop ask lo0 what MAC type it is and using that to understand
that there is no MAC header to speak of?
The insertion of a fake ethernet header incorrectly leads one
to believe that it is an ethernet medium and/or could be used
with ethernet filtering expressions. For example, if you're
pretending lo0 is ethernet for IPv4, where are my ARP packets?
Another kludge that this path requires is to assume that the
ethernet address of 00:00:00:00:00:00 is available for this
kind of hack. It's not exactly clear to me that it is or isn't
and could probably be argued either way.
I think you would be better off adding a new ioctl that would
return the data link layer type and changed snoop to use that
when it is forming knowledge about how to write its filter
expressions. If doing that ioctl fails then fallback to using
ethernet. This would limit the amount of work to just adding
the ioctl to your new lo driver. It would also be useful for
later building on support for porting the BPF driver to Solaris
and should be part of what is used and ends up in libdlpi.so.
The current plan just seems wrong here...very very wrong.
How will the inter-zone obersvability play with pfhooks?
And how will this compare with seen with packet going in
out of a physical interface? For example, now with snoop,
you see all packets that are "on the wire" - how does this
translate to inter-zone traffic with pfhooks and snoop?
On the topic of zones, you mention that you'll publish the
appropriate zoneid "where available." Are you making any
changes to IP to increase or improve the availability of
zone information with respect to packets?
e.g the problem observed in this bug might be relevant:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6352430
In your document, you write:
> However,
> right now there is no generic hook framework or PEF and so the only choice is
> to implement our own. The Packet Filtering Hook case does not provide a generic
> framework.
Would you like to expand on where the pfhooks case does not provide
you with a generic framework?
If the NH_PHYSICAL_IN/NH_PHYSICAL_OUT/NH_LOOPBACK_IN/NH_LOOKBACK_OUT
do not provide you with the correct locations then it could be worth
your while mentioning this.
It is true that the framework only supports one consumer of events at
any given time but this is a different limitation.
The description of dl_netinfo_t needs some work. Rather
than using uint64_t for zones, you should be using zoneid_t.
It's more important to use the correct type for storing data
than it is to use a specific size. If you're really concerned
about the field width thing, consider using a union to pad it
up but use the zoneid_t field as the active member.
Also, the current sizing of fields doesn't lead to useful
packing (there's a 32 bit hole between dli_len and dli_srczone.)
Consider making dli_version sa_family_t and assigning it either
AF_INET or AF_INET6, appropriately, rather than a magical 4 or 6.
Also, for dli_len, consider using something like size_t rather
than an intX_t.
struct dl_netinfo_s {
uint16_t dli_version;
sa_family_t dli_family;
uint32_t dli_len;
union {
unit64_t dliu_spad;
zoneid_t dliu_srczone;
} dli_srcun;
union {
unit64_t dliu_dpad;
zoneid_t dliu_dstzone;
} dli_dstun;
};
#define dli_srczone dli_srcun.dliu_srczone
#define dli_dstzone dli_srcun.dliu_dstzone
...the only problem (for packing) is that size_t will be 64bits
on UltraSPARC.
But so long as dli_version always comes first and remains the
same size forever, how the rest of the structure is packed
should not be a problem.
Regarding changes to other software...
Why are we changing 3rd party software to interface with
libdlpi.so and not snoop as well?
Is there any value in snoop'ing based on zones when Solaris
isn't correctly tagging packets with the right zone?
(See above.)
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 2:41 PM
in response to: darrenr
|
|
Darren Reed wrote On 05/05/06 14:03,:
> On /dev/lo0.
>
> Why are we fabricating the ethernet header rather than having
> snoop ask lo0 what MAC type it is and using that to understand
> that there is no MAC header to speak of?
Hear, hear. Software that assumes that all packets are carried
over Ethernet should be squashed, not coddled.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,083
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 2:47 PM
in response to: mditto
|
|
> >
> > Why are we fabricating the ethernet header rather than having
> > snoop ask lo0 what MAC type it is and using that to understand
> > that there is no MAC header to speak of?
>
> Hear, hear. Software that assumes that all packets are carried
> over Ethernet should be squashed, not coddled.
Since Phil's asleep and this thread may otherwise run amok: we are
fabricating an Ethernet header because that's what /dev/lo0 on other
Unix-like systems do. We agree it sucks, but the whole idea of the
/dev/lo0 device is to provide compatibility; if we're not going to follow
the same packet format, we might as well just scrap it entirely and force
applications to use /dev/ipnet/lo0.
BTW, we originally did not have /dev/lo0 at all, but added it based
on previous feedback.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,114
From:
Registered:
6/8/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 3:05 PM
in response to: meem
|
|
Peter Memishian wrote:
> > >
> > > Why are we fabricating the ethernet header rather than having
> > > snoop ask lo0 what MAC type it is and using that to understand
> > > that there is no MAC header to speak of?
> >
> > Hear, hear. Software that assumes that all packets are carried
> > over Ethernet should be squashed, not coddled.
>
>Since Phil's asleep and this thread may otherwise run amok: we are
>fabricating an Ethernet header because that's what /dev/lo0 on other
>Unix-like systems do.
>
Such systems being?
None of the BSDs do this, they all use an ioctl to ask the driver
what MAC tpe it is (NULL) and adjust their output similarly:
14:53:46.714843 AF IPv4 (2), length 88: 127.0.0.1 > 127.0.0.1: ICMP echo
request, id 63821, seq 1, length 64
I can point you at the source code, if you need convincing.
I'm sure the same would carry over to Tru64 (I can test that
on the weekend, if you're doubting) and others - except for
HP-UX (which suffers from he Mentat STREAMS disease.)
This appears top be a Linux-specific hack and doesn't need
to be replicated in Solaris. Why it is being done like that,
I don't know. Probably because someone was lazy and wanted
to assume that all NICs are "ethernet". FWIW, libpcap does
understand that DLT_LOOP (used by Linux in the past) is
different and has correctly functioned with it:
http://www.tcpdump.org/lists/workers/2003/08/msg00378.html
We don't need to blindly follow Linux down this path.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,083
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 3:13 PM
in response to: darrenr
|
|
> > > > Why are we fabricating the ethernet header rather than having
> > > > snoop ask lo0 what MAC type it is and using that to understand
> > > > that there is no MAC header to speak of?
> > >
> > > Hear, hear. Software that assumes that all packets are carried
> > > over Ethernet should be squashed, not coddled.
> >
> >Since Phil's asleep and this thread may otherwise run amok: we are
> >fabricating an Ethernet header because that's what /dev/lo0 on other
> >Unix-like systems do.
>
> Such systems being?
I will let Phil answer, as he's the one that's collected the data on this.
In any case, this is a trivial thing to adjust in the proposal, if need be.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
42
From:
UK
Registered:
6/29/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 26, 2006 9:18 AM
in response to: darrenr
|
|
Hi Darren,
Thanks for the comments.
> Why are we fabricating the ethernet header rather than having snoop
> ask lo0 what MAC type it is and using that to understand that there
> is no MAC header to speak of?
The reason for this was to allow existing applications to work without
modification. However, given we will be getting libpcap updated to support
the new DL_IPNET type we will also make /dev/lo0 of type DL_IPNET.
> How will the inter-zone obersvability play with pfhooks? And how will
> this compare with seen with packet going in out of a physical
> interface? For example, now with snoop, you see all packets that are
> "on the wire" - how does this translate to inter-zone traffic with
> pfhooks and snoop?
It will mirror the behaviour of what's seen for physical interfaces.
> On the topic of zones, you mention that you'll publish the
> appropriate zoneid "where available." Are you making any changes to
> IP to increase or improve the availability of zone information with
> respect to packets?
>
> e.g the problem observed in this bug might be relevant:
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6352430
There are no plans on adding anything formal in this space.
> In your document, you write:
>> However,
>>
>> right now there is no generic hook framework or PEF and so the only
>> choice is to implement our own. The Packet Filtering Hook case
>> does not provide a generic framework.
>
>
> Would you like to expand on where the pfhooks case does not provide
> you with a generic framework?
Perhaps the wording isn't clear here. As we've discussed before it's the
lack of multiple consumers that's the issue, not the location of hooks.
When this was discussed adding support for multiple consumers wasn't
something people wanted to tackle right now. I can modify the text to make
the problem clearer if it's necessary.
> The description of dl_netinfo_t needs some work. Rather than using
> uint64_t for zones, you should be using zoneid_t.
We disagree here. Consumers still need make assumptions about the actual
representation of zoneid_t to use it (eg. print it out). By using the
widest fixed width integral type (uint64_t) we avoid the problem. We've
asked the zones team for their advice over whether using uint64_t is ok
here and they have no problem with it.
> Regarding changes to other software...
>
> Why are we changing 3rd party software to interface with libdlpi.so
> and not snoop as well?
The plan is to make 3rd party applications work with the new DL_IPNET
devices, this may not require changing the applications to use libdlpi.
In answer to you question about snoop, snoop will be modified to use
libdlpi.
> Is there any value in snoop'ing based on zones when Solaris isn't
> correctly tagging packets with the right zone? (See above.)
I think so. On a system where you've multiple zones configured
administrators might prefer not to think in terms of addresses, they
might prefer to deal in terms of zones. Of course they could also use
hostnames, adding the zones flags is there to make things easier.
Thanks
Phil
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,114
From:
Registered:
6/8/05
|
|
|
|
Re: Clearview: Draft PSARC fasttrack for IP
observability devices
Posted:
May 5, 2006 6:12 PM
in response to: philk
|
|
Philip Kirk - Solaris Sustaining wrote:
> Hi,
>
> I've made the draft for the PSARC fasttrack document available for
> review here:
>
> http://www.opensolaris.org/os/project/clearview/ipnet/fasttrack.txt
This document doesn't make any reference to Trusted Solaris
and the labelled networking that came with it.
You might like to include some reference to it, whether security
labels are ignored or respected.
Whilst the Trusted Solaris extensions make use of zones, I'm not
sure it is enough to rely on them to enforce the correct security
policy, especially if you'll be providing access to data between
zones (its not clear if a label security policy would be enforced
before or after this access) and providing a new means to access
raw data in the global zone.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
