Clearview IP observability -------------------------- release binding: patch Problem ------- Currently in Solaris there is no way of observing local IP traffic. This includes traffic on 127.0.0.1 as well as traffic between addresses hosted on the same machine. Prior to Solaris 10 and the introduction of zones this lack of observability was problematic but not generally a major problem. With the introduction of zones this lack of observability means there is no way of viewing interzone traffic or intrazone traffic. This lack of observability is now a major problem. The reason there is no visibility into this traffic is due to the ip module short-circuiting the data path, and when it sees traffic that is destined for a local address loops this traffic back itself. In addition to the ip module short-circuiting the data path, bugid 4821256 introduced tcp fusion which means that local TCP traffic is short-circuited in the tcp module. This bug fix was integrated into Solaris 10. The bugid's related to this problem are: 4085089 add a feature to enable 'snooping' of the loopback traffic 5097626 snoop should be able to see network traffic between zones. 4195614 Loop back snooping capabilities Proposed solution ----------------- This project will solve the lack of observability by introducing a new ipnet namespace under /dev/. The /dev/ipnet directory will contain a DLPI style-1 device for each IP interface on the system. The devices will provide access to all packets sent and received by IP on a network interface. For instance, /dev/ipnet/bge0 will provide observability to packets sent and received by IP on bge0 subject to the zone restrictions specified below. To provide access to the packets we will add hooks into the ip module which will call our callback function. In addition, some Unix variants provide IP-level loopback observability through a special /dev/lo0 device. For compatibility, we will also provide a /dev/lo0 device. In the case of /dev/lo0 there is a potential issue with the SVVS test suite. This is described later in the case as well as the solution. Handling tcp fusion ------------------- Currently, local connections are short-circuited in the tcp module where this is possible. Such connections are termed fused. This means that these connections are not visible when observing at the ip module. To handle this, fused connections will be unfused when an application starts observing loopback traffic, and re-fused when when observation stops. Also new connections will not be fused until fusion is re-enabled. The proposal achieves the unfuse by setting do_tcp_fusion to 0 which disables fusion and adds a check for do_tcp_fusion to the code path for determining whether a connection should be fused or unfused. This code works but is clearly global, effecting all local connections on the machine while the new devices are been used to observe traffic. Below are some performance figures for when fusion is enabled and disabled, both on a current Nevada build and on Clearview's current development build. Testing was done on a 4-processor E420R server. In both tests non-debug builds were used. As can be seen, with no open ipnet devices, and therefore with fusion enabled there is no negative performance difference. tcp-t tcp-r KB/sec calls/sec KB/sec calls/sec onnv64+fusion 98725.79 12340.83 98710.38 12339.00 onnv64-fusion 92784.93 11598.21 92763.60 11595.64 cv+fusion 113303.40 14163.04 113300.18 14162.76 cv-fusion 98770.27 12346.39 98720.93 12340.32 cv+snoop 80524.94 10065.70 80523.05 10065.55 Testing was done using ttcp -r -s 127.0.0.1 for the receiver, and ttcp -t -s -n120000 127.0.0.1. Interaction with other performance optimizations ----------------------------------------------- As well as tcp fusion there are other performance optimizations such as multidata transfer (MDT) and large send offload (LSO). However, this project has no affect on these features and likewise the features have no affect on this project. ipnet device ------------ The ipnet device will be responsible for managing the devices in /dev/ipnet and passing up IP traffic to listeners using these devices. For management of nodes in /dev/ipnet/ we will rely on the netinfo interface which is part of the "Packet Filtering Hooks API" case (PSARC/2005/334). For receiving packets sent to/received from the ip module this project will introduce hooks into the ip module. These hooks will be used by the /dev/lo0 device as well as the ipnet device. The addition of another set of hooks into the ip module is potentially contentious. 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 in that it only allows a single consumer. Making the framework support multiple consumers was not a task they wished to undertake given the potential problems handling multiple consumers introduces and the timescales for their project. As mentioned already the /dev/ipnet namespace will contain devices providing access to packets passing through the ip module. For every IP interface on the system there will be a node create in /dev/ipnet. As an example suppose ifconfig -a returns: # ifconfig -a lo0: flags=2001000849 mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 lo0:1: flags=2001000849 mtu 8232 index 1 zone Z1 inet 127.0.0.1 netmask ff000000 lo0:2: flags=2001000849 mtu 8232 index 1 zone Z2 inet 127.0.0.1 netmask ff000000 bge0: flags=1000843 mtu 1500 index 2 inet 192.168.0.1 netmask ffffff00 broadcast 192.168.0.255 ether 8:0:20:f0:5a:8 eri0: flags=1000843 mtu 1500 index 3 inet 10.0.0.1 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:f0:5a:8 eri0:1: flags=1000843 mtu 1500 index 3 zone Z1 inet 10.0.0.2 netmask ff000000 broadcast 10.255.255.255 eri0:2: flags=1000843 mtu 1500 index 3 zone Z2 inet 10.0.0.3 netmask ff000000 broadcast 10.255.255.255 With this configuration the following devices will be created in /dev/ipnet: /dev/ipnet/lo0 /bge0 /eri0 Opening these devices will provide access to all IP packets with addresses associated with the interface. This includes both IPv4 and IPv6 traffic, and addresses hosted on logical interfaces. For this reason, there is no /dev/ipnet/eri0:1; instead opening /dev/ipnet/eri0 will provide all traffic that is destined for, or originating from, any address hosted on eri0. If administrators want to see packets from a particular address, then they will be able to use filters, just as they can now when running snoop on a data link. The ipnet node related to the address associated with a non-global zone will be visible from within that zone. There are restrictions though on what traffic will be visible when opening the ipnet device from a non-global zone and these are detailed below. Allowing access to local IP traffic also presents new security implications and these are discussed later. A packet will be passed to a consumer if: The packet passes the ip module's checks for validity AND either (1) or (2) are true. 1. The source or destination address of the packet is one of the addresses assigned to the interface AND the consumer is in the global zone or in a non-global zone to which the packet is destined OR, 2. DL_PROMISC_PHYS is enabled and the interface was used for input or output of the packet to or from the link-layer AND the consumer is in the global zone. Two interesting cases for reception of packets are broadcast and multicast. In the multicast case, the ip module does not by default receive all multicast traffic, it will only receive traffic for those applications that have bound to specific multicast addresses. To ensure all multicast traffic is seen when a user opens an ipnet device and issues a DL_ENABMULTI_REQ, the ipnet driver will send a DL_ENABMULTI_REQ down to the underlying ill_t associated with the ipnet device that is being opened. Code already exists in ip to achieve this so the same code will be used by the ipnet device. When the ipnet is closed, assuming no other user has also issued a DL_PROMISC_MULTI request, the ipnet device will send a DL_DISABMULTI_REQ to turn promiscuous mode off. Enabling promiscuous mode will have a slight overall performance impact, and therefore a user with the privileges needed to use ipnet devices from inside a zone can potentially impact the performance outside their zone. However, this is already true for multicast applications operating in a zone today, and therefore is not a new concern. Broadcast traffic will be seen as expected. From within a non-global zone an administrator will be able to access the ipnet device on which the IP address associated with the zone is hosted. However, they will be restricted to only seeing traffic associated with that zone, not all traffic associated with that data-link. The ipnet devices will have a new DLPI mac type of DL_IPNET which will require snoop to be modified. The strategy for handling 3rd party tools that may wish to use the new devices is described later. In addition to having a new mac type it will also have an ancillary data header which will contain the source and destination zone of a packet where the zoneid is known. In the case where a zoneid is unknown the zoneid will be -1, ALL_ZONES. An example of where the zoneid might not be known is in the case of forwarded traffic. The ancillary data header proposed for the ipnet device will be of fixed length, and contain a version number to aid expansion in the future as needed. The structure of the header is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vers | type | len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + srczone + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + dstzone + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and in C expressed as: typedef struct dl_ipnetinfo { uint8_t dli_version; /* Current version*/ uint8_t dli_ipver; /* IP version */ uint16_t dli_len; /* sizeof dl_ipnetinfo_t */ uint32_t dli_pad; /* Padding for alignment */ uint64_t dli_srczone; /* Source of zoneid where known. */ uint64_t dli_dstzone; /* Destination zoneid where known. */ } dl_ipnetinfo_t; In the case of dli_srczone and dli_dstzone uint64_t is used instead of zoneid_t to ensure field width. As a consequence of ensuring field width we also guarantee field alignment. The current version will be held in the following constant: #define DL_IPNETINFO_VERSION 1 The header will be stored in big endian which matches the existing snoop header format. By default, the ipnet device will only pass up packet data. To get the ancillary data header, an application will need to issue the new DL_IOC_IPNET_INFO ioctl. The new ioctl will take a boolean parameter to enable or disable the facility. Although the header will be of fixed size, the actual length will be dependent on the version. An application will issue a DL_IOC_IPNET_INFO request passing in 1 to enable the facility. The device will return a non-zero value indicating the current DL_IOC_IPNET_INFO version. Below is an example of the output an administrator will see when running snoop against an ipnet device in verbose summary and verbose mode: #snoop -I -d lo0 -V Using device /dev/ipnet/lo0 (promiscuous mode) ________________________________ foo.UK.Sun.COM -> bar.UK.Sun.COM IPNET SRCZONE=0 DSTZONE=0 foo.UK.Sun.COM -> bar.UK.Sun.COM IP D=129.156.210.76 S=129.156.209.54 LEN=296, ID=24464, TOS=0x0, TTL=255 foo.UK.Sun.COM -> bar.UK.Sun.COM UDP D=56603 S=39647 LEN=276 foo.UK.Sun.COM -> bar.UK.Sun.COM RPC R XID=1141508787 Success #snoop -I -d lo0 -v IPNET: ----- IPNET Header ----- IPNET: IPNET: Packet 1 arrived at 14:27:44.06057 IPNET: Packet size = 1524 bytes IPNET: IPNET version = 1 IPNET: IP type = IPv4 IPNET: Source zone = 0 IPNET: Destination zone = 0 IPNET: IP: ----- IP Header ----- /dev/lo0 device --------------- The /dev/lo0 device introduced by this project will behave in the same manner as /dev/lo0 on other Unix variants, namely, it will provide access to IP traffic local to the machine. Local traffic includes 127.0.0.1 traffic as well as other addresses hosted locally on the machine. The /dev/lo0 device will have a DLPI mac type of DL_IPNET, the same as the ipnet devices described above. In the same way that using the ipnet devices in a zone has restrictions on what traffic you will see the /dev/lo0 devices will enforce similar restrictions, namely you will only see traffic for the zone you are in. SVVS Impact of /dev/lo0 ----------------------- Unfortunately, the SVVS test suite currently includes "/dev/lo[0-4]" devices which are used as part of testing System V conformance. These devices are an implementation artifact of the SVVS test suite itself, are of no general purpose, and are not part of the System V Interface Definition. Further, since the SVVS test suite is not shipped with Solaris, these /dev/lo devices are not part of Solaris proper. Accordingly, we propose to rename the SVVS device to /dev/svvslo[0-4], and update the SVVS test suite to use the new device names -- thus allowing us to provide the /dev/lo0 node proposed earlier in the case. (Note that simply avoiding the name "/dev/lo" is not an option since it will introduce an inconsistency with respect to other Unix-like systems.) Initially, there was concern that making a change to the SVVS test suite would prove problematic. Specifically, the concern was that other partners, such as Fujitsu, may have their own private SVVS test suite trees which would also require updates. However, based on data from a similar case during Solaris 9 development, we believe these concerns are unfounded. In particular, the fix for 4438982 removed the misguided shminfo_shmseg /etc/system tunable, which SVVS used to test. The impact was worse than a test failure -- instead, SVVS would simply consume all memory and cause the system under test to hang; this was fixed by removing the bogus SVVS test (4446696). However, five years later, no one outside Sun has ever reported this issue. Further, we believe it would be wrong to compromise the preferred name for the loopback device in order to work around a namespace clash with a device that has never been included with a shipped version of Solaris. Security implications --------------------- For these devices the project will introduce a new privilege, PRIV_IP_OBSERVABILITY. This will just allow access to the ipnet devices where packets can only be observed not sent. Although the new privilege only allows observation of traffic it does present additional risks to those associated with PRIV_NET_RAWACCESS. Local connections have always been more trusted than connections on the wire. For connections on the wire there is always the possibility of anonymous eavesdroppers, the same is not true for local connections. Given this, traffic on the wire might be subject to encryption whilst local traffic may not under the assumption there is no problem of someone eavesdropping. Allowing observation of local traffic clearly breaks this assumption. Given the new risks exposing observation of local traffic brings, the proposed new privilege may be refined in the future, adding finer grained privileges. As an example of how this privilege might be refined, there could be separate privileges for observing intrazone, interzone, and inter-machine traffic. However, for now we plan on keeping one high level privilege, which only uid 0 will be granted by default. Given that Trusted Extensions architecture is built upon zones it is clear that the ipnet architecture must also respect labelling information if the trusted extensions facility is being used. Where hooks are placed we check whether the system is lableled and if it is check what the zoneid should be based on the labelling information. Hook insertion in the ip module ------------------------------- The hook framework this project plans on adding to the ip module will be a very simple callback mechanism. The ipnet device and /dev/lo0 device will register with the ip module by calling ips_register_hook() and passing in a callback function. In the case of ipnet, registration with the ip module will occur once there are devices in /dev/ipnet/ and unregister with the ip module in the event there are no IP interfaces configured and thus no devices in /dev/ipnet/. In the ip module the registered callback functions are stored in a list, when a hook is run each callback will be called and data passed back to the caller. Both ipnet and /dev/lo0 will process these messages from within their srv(9E) routines to avoid blocking the ip module. The callback interfaces will be Project Private. The devices unregister with the ip module by calling ips_unregister_hook(). Given the simplicity of the callbacks this project plans on adding there should be nothing to prevent them been re-implemented using PEF (packet event framework) should it ever become available or another more generic mechanism. The framework could be extended fairly easily to allow packets to be passed to the ipnet device before or after processing by IPsec. Modifying the framework to do this would just involve adding new hooks at the right points in the code path and potentially extending the data passed back to include whether the packet has been processed by IPsec. How this view would be exposed to the user is more interesting and there are several possibilities -- for example, new directories could be added to the /dev/ipnet namespace which would indicate whether you wanted to see packets before or after processing by IPsec, or a new ioctl could be created which would tell the ipnet driver that you wished to see packets pre or post processing. This project is not concerned with how this functionality will be implemented. snoop(1M) changes ----------------- The snoop utility will be updated to support the new DLPI mactype and as such will introduce new verbose (-v) and verbose summary (-V) output format for the type shown above. In addition to this a new keyword to filter on zone id will be introduced plus a new '-I' option to specify that the /dev/ipnet/* device is to be used. Changes to 3rd party software ----------------------------- In order to ensure that popular third-party packet observability tools such as ethereal and tcpdump can benefit from the new DL_IPNET devices, we will work with the open-source communities to enhance the libpcap library (which those tools use for packet capture) to support DL_IPNET. Moreover, in order to shield applications from the details of accessing these and other upcoming DLPI devices proposed by Clearview, we will be proposing a public libdlpi.so library as part of an upcoming case. Essentially the main changes needed to be made to libpcap are adding support for a decode function for the new DL_IPNET header format and support for the new DL_IOC_IPNETINFO ioctl. The common use case will be that DL_IOC_IPNETINFO will be issued so that the DL_IPNET ancillary header will be passed up by default. The data contained in the ancillary header will make diagnosibility of certain problems much easier. Interface changes ----------------- Interfaces Imported Interface Classification Comments netinfo(9f) Uncommitted PSARC/2005/334 Interfaces Exported Interface Classification Comments DL_IOC_IPNET_INFO Committed inet/ipnet.h struct dl_ipnet_info Committed inet/ipnet.h DL_IPNETINFO_VERSION Committed inet/ipnet.h DL_IPNET Committed sys/dlpi.h ips_register_hook() Project Private inet/ip.h ips_unregister_hook() Project Private inet/ip.h PRIV_IP_OBSERVABILITY Committed sys/priv_names.h /dev/lo0 Committed lo0 (7D) /dev/ipnet/* Committed ipnet (7D) Committed zoneid Committed snoop (1m) net_getlifzone() Committed neti.h net_getlif_flags() Committed neti.h NE_SET_ZONE Committed hook_event.h NE_LIF_UP Committed hook_event.h NE_LIF_DOWN Committed hook_event.h man page changes ---------------- There will be four new man pages introduced, one for ipnet device, one for the /dev/lo0 device, one for net_getlifzone and one for net_getlif_flags. The snoop man page will be updated to reflect the new -I option used to specify the ipnet devices and the new zone filtering expression. The privileges(5) will be updated with the new PRIV_IP_OBSERVABILITY privilege.The proposed content of the man pages is below. Devices lo0(7D) NAME lo0 - SUNW,lo0 ip loopback device driver SYNOPSIS /dev/lo0 DESCRIPTION The SUNW,lo0 driver is a software driver for all loopback traffic. Such traffic includes 127.0.0.1 traffic as well as traffic between addresses hosted on the same machine. APPLICATION PROGRAMMING INTERFACE lo0 and DLPI The lo0 driver is a style-1 Data Link Service provider. All M_PROTO and and M_PCPROTO type messages are interpreted as DLPI primitives. Given the device is a read only device and packets can only be observed by opening it, only a sub-set of DLPI primitives are supported. These are listed below: DL_INFO_REQ DL_BIND_REQ DL_UNBIND_REQ DL_PROMISCON_REQ DL_PROMISCOFF_REQ DLIOCRAW The values returned by the driver in the DL_INFO_ACK primitive in response to the DL_INFO_REQ from the user are as follows: o The maximum SDU is UINT_MAX. o The minimum SDU is 0. o The dlsap address length is 0 o The MAC type is DL_IPNET. o The sap length values is -2. o The service mode is DL_CLDLS. o No optional quality of service (QOS) support is so the QOS fields are 0. o The provider style is DL_STYLE1 o The version is DL_VERSION_2 The lo0 device will only allow binding to IP_DL_SAP, IP6_DL_SAP or 0. Binding to anything other than these will cause a DL_ERROR_ACK in response. The error returned will be DL_BAD_SAP. If sap 0 is bound to then both IPv6 and IPv4 traffic will be returned. lo0 primitives The DL_PROMISCON_REQ and DL_PROMISCOFF_REQ primitives with the DL_PROMISC_PHYS flag set in the dl_level field enables/disables the reception of all packets. In the disabled case only packets with addresses matching any of the configured addresses on the datalink will be received. When used with the DL_PROMISC_MULTI flag set this enables/disables reception of all multicast group addresses. When used with the DL_PROMISC_SAP flag set this enables/disables the reception of all IPv4/IPv6. The DLIOCRAW ioctl is supported but has no effect on the data returned from the device. FILES /dev/lo0 lo0 special character device /kernel/drv/lo0.conf SEE ALSO dlpi(7P) Devices ipnet(7D) NAME ipnet - ipnet device driver SYNOPSIS /dev/ipnet/* DESCRIPTION The ipnet device driver exists to handle the creation and removal of nodes from the /dev/ipnet/ namespace, and to manage the device nodes once they have been created. For every IP interface on the system there will be a node created in /dev/ipnet. This includes interfaces that exist only in software and for which there is no hardware device. These devices will provide access to all IP traffic to and from the system. APPLICATION PROGRAMMING INTERFACE ipnet and DLPI The device nodes created in /dev/ipnet are DLPI style-1 devices. All M_PROTO and and M_PCPROTO type messages are interpreted as DLPI primitives. Given the device is a read only device and packets can only be observed by opening it, only a sub-set of DLPI primitives are supported. These are listed below: DL_INFO_REQ DL_BIND_REQ DL_UNBIND_REQ DL_PROMISCON_REQ DL_PROMISCOFF_REQ DLIOCRAW The values returned by the driver in the DL_INFO_ACK primitive in response to the DL_INFO_REQ from the user are as follows: o The maximum SDU is UINT_MAX. o The minimum SDU is 0. o The dlsap address length is 0 o The MAC type is DL_IPNET. o The sap length values is -2. o The service mode is DL_CLDLS. o No optional quality of service (QOS) support is so the QOS fields are 0. o The provider style is DL_STYLE1 o The version is DL_VERSION_2 The devices in /dev/ipnet/ only allow binding to IP_DL_SAP, IP6_DL_SAP or 0. Binding to anything other than these will cause a DL_ERROR_ACK in response. The error returned will be DL_BAD_SAP. If sap 0 is bound to then both IPv6 and IPv4 traffic will be returned. ipnet primitives The DL_PROMISCON_REQ and DL_PROMISCOFF_REQ primitives with the DL_PROMISC_PHYS flag set in the dl_level field enables/disables the reception of all packets. In the disabled case only packets with addresses matching any of the configured addresses on the datalink will be received. When used with the DL_PROMISC_MULTI flag set this enables/disables reception of all multicast group addresses. When used with the DL_PROMISC_SAP flag set this enables/disables the reception of all IPv4/IPv6. The DLIOCRAW ioctl is supported but has no effect on the data returned from the device. The DL_IOC_IPNET_INFO ioctl enables/disable the passing up of the ancillary data header with the packet data. When the facility is enabled a non-zero integer is returned reflecting the current DL_IOC_IPNET_INFO version. The ancillary data header returned is of fixed length and has the following format: uint8_t dli_version; /* Current version */ uint8_t dli_ipver; /* IP version */ uint16_t dli_len; /* sizeof dl_ipnetinfo_t */ uint64_t dli_srczone; /* Source of zoneid where known. */ uint64_t dli_dstzone; /* Destination zoneid where known. */ FILES /dev/ipnet ipnet special character device /kernel/drv/ipnet.conf SEE ALSO dlpi(7P) Change to snoop.1m manpage. ------- snoop.1m ------- *** /tmp/sccs.pDaOse Thu Mar 23 19:43:19 2006 --- snoop.1m Thu Mar 23 19:31:36 2006 *************** *** 4,10 **** snoop - capture and inspect network packets SYNOPSIS ! snoop [-aqrCDNPSvV] [ -t [r | a | d] ] [-c maxcount] [-d device] [-i filename] [-n filename] [-o filename] [ -p first [ , last]] [-s snaplen] [ -x offset [ , length]] [expres- sion] --- 4,10 ---- snoop - capture and inspect network packets SYNOPSIS ! snoop [-aqrCDINPSvV] [ -t [r | a | d] ] [-c maxcount] [-d device] [-i filename] [-n filename] [-o filename] [ -p first [ , last]] [-s snaplen] [ -x offset [ , length]] [expres- sion] *************** *** 55,60 **** --- 55,63 ---- where. Packets are not displayed when this flag is used. + -I Capture packets using the devices in + /dev/ipnet. + -P Capture packets in non-promiscuous mode. Only broadcast, multicast, or packets addressed to the host *************** *** 397,402 **** --- 400,410 ---- from qualifier may be used to select either call or reply packets only. + zone zoneid + + True if zoneid matches either the src or destination + zoneid of a packet received on an ipnet device. + ldap True if the packet is an LDAP packet on port 389. *************** *** 672,678 **** SEE ALSO netstat(1M), hosts(4), rpc(4), services(4), attributes(5), ! audio(7I), bufmod(7M), dlpi(7P), pfmod(7M), tun(7M) Callaghan, B. and Gilligan, R. RFC 1761, Snoop Version 2 Packet Capture File Format. Network Working Group. February --- 680,686 ---- SEE ALSO netstat(1M), hosts(4), rpc(4), services(4), attributes(5), ! audio(7I), bufmod(7M), dlpi(7P), ipnet(7D), pfmod(7M), tun(7M) Callaghan, B. and Gilligan, R. RFC 1761, Snoop Version 2 Packet Capture File Format. Network Working Group. February Change to privileges(5) manpage. ------- privileges.5 ------- *** /tmp/sccs.q9aOwE Fri Apr 21 11:51:35 2006 --- privileges.5 Fri Apr 21 11:54:11 2006 *************** *** 173,178 **** --- 173,183 ---- Allow a process to send and receive ICMP packets. + PRIV_IP_OBSERVABILITY + + Allow a process to open a device for just receiving + network traffic, sending traffic is disallowed. + PRIV_NET_PRIVADDR Allow a process to bind to a privileged port number. The Kernel functions net_getlifzone(9F) NAME net_getlifzone - determine the zone id for a given interface SYNOPSIS #include zoneid_t net_getlifzone(phy_if_t phy, lif_if_t lif); INTERFACE LEVEL Solaris DDI specific (Solaris DDI) PARAMETERS phy value returned from a successful call to net_phylookup or net_phygetnext, indicating which network interface the information should be returned from. lif value returned from a successful call to net_lifgetnext, indicating which logical interface to fetch the zoneid for. DESCRIPTION RETURN VALUES This function returns the zone id associated with the interface passed in. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Consolidation Private | |_____________________________|_____________________________| SEE ALSO net_phylookup(9f), net_phygetnext(9f) Kernel functions net_getlif_flags(9F) NAME net_getlif_flags - determine the current interface flags for a given interface SYNOPSIS #include uint64_t net_getlif_flags(phy_if_t phy, lif_if_t lif); INTERFACE LEVEL Solaris DDI specific (Solaris DDI) PARAMETERS phy value returned from a successful call to net_phylookup or net_phygetnext, indicating which network interface the information should be returned from. lif value returned from a successful call to net_lifgetnext, indicating which logical interface to fetch the interface flags for. DESCRIPTION This function returns the interface flags for the interface passed in. RETURN VALUES This function returns the interface flags associated with the interface passed in. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO net_lifgetnext(9f)