From sacadmin Tue Sep 16 08:52:20 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8GFqK8s012334; Tue, 16 Sep 2008 08:52:20 -0700 (PDT) Received: (from dr146992@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m8GFqJ9v012330; Tue, 16 Sep 2008 08:52:19 -0700 (PDT) Date: Tue, 16 Sep 2008 08:52:19 -0700 (PDT) From: Darren Reed Message-Id: <200809161552.m8GFqJ9v012330@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Solaris host-based firewall [PSARC/2008/580 FastTrack] Status: RO Content-Length: 558 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Solaris host-based firewall 1.2. Name of Document Author/Supplier: Author: Tony Nguyen 1.3 Date of This Document: 16 September, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Reed@Sun.COM Wed Sep 24 03:14:52 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8OAEqaT006679 for ; Wed, 24 Sep 2008 03:14:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8OAEqkH007493 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 24 Sep 2008 03:14:52 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7P0030334R9W00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 04:14:51 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7P00BAU34QD4D0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 04:14:51 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8OAEoPt027704 for ; Wed, 24 Sep 2008 10:14:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7P00K0125SNC00@fe-emea-09.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 11:14:50 +0100 (BST) Received: from [129.157.18.45] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7P009KH34BZQ70@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 11:14:36 +0100 (BST) Date: Wed, 24 Sep 2008 12:14:33 +0200 From: Darren Reed Subject: Solaris host-based firewall [PSARC/2008/580 FastTrack] Sender: Darren.Reed@Sun.COM To: psarc-ext@Sun.COM Cc: Tony Nguyen Message-id: <48DA1309.9060408@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_MLtqezvVqHSXWyNZ9UbvTg)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 41705 This is a multi-part message in MIME format. --Boundary_(ID_MLtqezvVqHSXWyNZ9UbvTg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I am submitting this case on behalf of Tony Nguyen. This case seeks to enable tieing together service availability in SMF with IPFilter for firewalling of access to them. This case is requesting patch/micro binding. The timeout has been set for Wednesday next week (30/9/2008.) Completed versions of the man pages being altered (ipf.1m, ipfilter.5) can be found in the case directory - only diffs are included in this email. Darren --Boundary_(ID_MLtqezvVqHSXWyNZ9UbvTg) Content-type: text/plain; name=svc.ipfd.1m Content-transfer-encoding: 7BIT Content-disposition: inline; filename=svc.ipfd.1m System Administration Commands svc.ipfd(1M) NAME svc.ipfd - IPfilter firewall monitoring daemon SYNOPSIS /lib/svc/bin/svc.ipfd svc:/network/ipfilter:default DESCRIPTION svc.ipfd monitors actions to services with firewall configuration and initiates update services' IPfilter configuration. The daemon allows us to react to changes in system's firewall configuration in an incremental fashion, at per service level. A service's firewall policy is activated when it's enabled, deactivated when it's disabled, and updated when its configuration property group is modified. svc.ipfd monitors SMF repository for these actions and invokes IPfilter rule generation process to carry out the service's firewall policy. Environment Variables and Context This daemon is started by the network/ipfilter service either through the start or refresh method. Thus, the daemon inherits the environment variables and credentials from the method and runs as root user the variable: SMF_FMRI=svc:/network/ipfilter:default FIREWALL STATIC CONFIGURATION Static definition describing service's network resource configuration that is used to generate service specific ipf rules. A new per service "firewall_context" property group contains a service's static definition, similar to "inetd" property group in inetd managed services. - firewall_context/name, IANA name or RPC name for non-inetd service, equivalent to inetd/name property - firewall_context/isrpc, a boolean property where a "true" value indicates an RPC service, equivalent to inetd/isrpc property. For RPC services, the value of firewall_context/name is not an IANA name but is either an RPC program number or name, see rpc(4). Additionally, some services may require a mechanism to generate and supply their own ipf rules. An optional property ipf_method, provides a mechanism to allow custom rule generation. - firewall_context/ipf_method, a command, normally a script that generates ipf rules for a service. The framework does not generate rules for services with this property definition but expect these services to provide their own rules. A service's ipf_method specifies a command that takes an additional argument, its own fmri and generates the service's firewall rules and output the rules to stdout. To generate rules for a service with ipf_method property, the framework execs the command specified in ipf_method, passing the service fmri as the additional argument and stores the rules for that service by redirecting the command output, the rules, to the service's rule file. Because an ipf_method is exec'ed from the context of either network/ipfilter start or refresh method process, it inherits the execution context and runs as root. Administrative Privilege The service static configuration, is delivered by service developer and and not intended to be modified by users. These properties are only modified upon installation of an updated service definition. FIREWALL POLICY CONFIGURATION A per service property group, firewall_config, stores the services' firewall policy configuration. Since network/ipfilter:default is responsible for two firewall policies, Global Default and Global Override system-wide policies as explained in ipfilter(5), it has two property groups, firewall_config_default and firewall_config_override, to store the respective sytem-wide policies. Below are the properties, their possible values and correspoding semantics: policy "none" policy mode - no access restriction. For a global policy, this mode allows all incoming traffic. For a service policy, this mode allows all incoming traffic to its service. "deny" policy mode: more restrictive than "none". This mode allows incoming traffic from all sources except those specified in the "apply_to" property. "allow" policy mode: most restrictive mode. This mode blocks incoming traffic from all sources except those specified in the "apply_to" property. apply_to A multi-value property listing network entities to enforce the chosen policy mode. Entities listed in apply_to property will be denied if policy is "deny" and allowed if policy is "allow". The syntax for possible values are: host: host:IP "host:192.168.84.14" subnet: network:IP/netmask "network:129.168.1.5/24" interface: if:interface_name "if:e1000g0" exceptions A multi-value property listing network entities to be excluded from the "apply_to" list. For example, when deny policy is applied to a subnet, exceptions can be made to some hosts in that subnet by specifying them in the "exceptions" property. This property has the same value syntax as "apply_to" property. For individual network services only: firewall_config/policy A service's policy can also be set to "use_global". Services with "use_global" policy mode inherits the Global Default firewall policy. For the Global Default only: firewall_config_default/policy - can also be set to "custom" Global Default policy, firewall_config property group in svc:/network/ipfilter:default, can also be set to "custom". Users can set policy to "custom" to use prepopulated IPfilter configuration, e.g. existing IPfilter configuration or custom configurations that can't be provided by the framework. This Global Default only policy mode allows users to supply a text file containing the complete set of ipf rules. When "custom" mode is selected, the specified set of ipf rules is *complete* and the framework will not generate ipf rules from configured firewall policies. firewall_config_default/custom_policy_file A file path to be used when Global Default policy is set to "custom". The file contains a set of ipf rules which provide the desired IPfiler configuration. firewall_config_default/open_ports Non-service program requiring allowance of its incoming traffic can request the firewall to allow traffic to its communication ports. This multi-value property property contains protocol and port(s) tuple in the form "{tcp | udp}:{PORT | PORT-PORT}" Initially, the system-wide policies are set to "none" and network services' policies are set to "use_global". Enabling network/ipfilter activates the firewall with an empty set of ipfilter rules, since system-wide policy is "none" and all services inherit that policy. To configure a more restrictive policy, use svccfg(1M) to modify network services and system-wide policies. Administrative Privilege User configures firewall policy by modifying the service's firewall_config property group. A new authorization "solaris.smf.value.firewall.config" is created to allow delgation of firewall administration privilege to users. The Service Operator users will need this new authorization to be able to configuration firewall policy. DEVELOPER DOCUMENTATION Services providing remote capabilities are encouraged to participate in the firewall framework to control network access to the service. While framework integration isn't mandatory, remote access to services that are not integrated in the framework may not function correctly when a system-wide policy is configured. Integrating a service into the framework is as straightforward as defining two additional property groups and their corresponding properties in the service manifest. IPfilter rules are generated when user enables the service. In the non-trivial case of custom rule generation where a shell script is required, there are existing scripts that can be used as examples. The additional property groups, firewall_config and firewall_context store firewall policy configuration and provides static firewall definition, respectively. Below is a summary of new property groups and properties and their appropriate default values. Firewall policy configuration: firewall_config See FIREWALL POLICY CONFIGURATION section for more information. Access to is protected by a new authorization definition and a user-defined property type. The new authorization should be assigned to the property group value_authorization property such as Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_configuration" as the property type. firewall_config/policy This property's initial value should be "use_global" since services, by default, inherit the Global Default firewall policy. firewall_config/apply_to An empty property, this property has no initial value. firewall_config/exceptions An empty property, this property has no initial value. Firewall static definition: firewall_context See FIREWALL STATIC CONFIGURATION section for more information. Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_definition" as the property type. firewall_context/name Service with well-known, IANA defined port which can be obtained by getservbyname(3SOCKET), the service's IANA name is stored in this property. For RPC services, the RPC program number is stored in this property. firewall_context/isrpc For RPC services, this property should be created with its value set to "true" firewall_context/ipf_method In general, the specified firewall policy is used to generate IPfilter rules to the service's communication port, derived from firewall_context/name property. Services which don't have IANA defined ports and are not RPC services, will need to generate their own IPfilter rules. Services that generate their own rules may choose not to have firewall_context/name and firewall_context/isrpc properties. See the following services svc:/network/ftp:default svc:/network/nfs/server:default svc:/network/ntp:default and others with existing ipf_method for guidance. ATTRIBUTES See attributes(5) for descriptions of the following attributes: System Administration Commands svc.ipfd(1M) ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu SUNWipfr | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO ipfilter(5), ipf(4), rpc(4), svcs(1), svcprop(1), svcadm(1M), svccfg(1M), attributes(5), smf(5) --Boundary_(ID_MLtqezvVqHSXWyNZ9UbvTg) Content-type: text/plain; name=arc_proposal Content-transfer-encoding: 7BIT Content-disposition: inline; filename=arc_proposal Solaris host-based firewall Truong Q. Nguyen (Tony Nguyen) 09/08/2008 1. Introduction Currently, Solaris has IPfilter which allows user to set up system and service firewall policies. The project delivers a framework to simplify system and services IPfilter configuration. IPfilter uses a set of ipf rules from which it determines whether an IP packet should be allowed in or out of the system. Although ipf rule syntax is fairly simple and straightforward, it still demands good understanding of networking and security concepts, a non-trivial learning curve for 'casual' Solaris users. Moreover, the task of creating and testing ipf rules are mostly manual and can become a management burden in systems where large number of rules are used. Instead of manually construct and specify ipf rules, the proposed framework allows users to express system and services' firewall policies which it uses to generates a set of IPfilter rules to enforce the desired behavior. Essentially, users specify system and service firewall policies that allow or disallow network traffic from certain hosts, subnets, and interface(s). The policies can be translated into a set of active ipf rules to enforce the specified firewall policies. Existing firewall tools, fwbuilder being a good example, may provide highly customized configuration but have other drawbacks. Our proposed solution which targets casual OpenSolaris users, has clear advantages. - Very simple user model. While FirewallBuilder is able to produce highly customized configurations, it requires good understanding of firewall concept and knowledge of the system networking configuration. Setting up FirewallBuilder requires specifying a path, a file, local address, create objects for each service, *configure* firewall for the objects, compile, and run. Our firewall only requires setting policy by changing properties and enable service(s). - Well-integrated with Solaris - Supports IPfilter configuration generated by other tools. Our framework should satisfy the needs of most casual users. However, advanced users can always use tools such as FirewallBuilder to generate IPfilter rules that can be consumed by the proposed framework. 2. Scope Our goal is to provide casual OpenSolaris users and developers a simple way to harden their systems. System administrators can certainly use the firewall framework but may find some deficiencies such as inability to synchronize policies across a group of Solaris systems. The propose project is NOT a firewall configuration tool but an IPfilter-based firewall framework that allows high-level firewall policies and translates those policies to IPfilter rules. Generic firewall construction tools, if possible, should use the proposed framework to configure IPfilter for Solaris machines. The proposed framework isn't a full IPfilter configuration tool, thus it won't generate every possible IPfilter configuration. However, users can specified a custom ipf rule set to be used if the framework can't provide the desired IPfilter configuration. 3. Design Model: The proposed firewall framework provides a simple mechanism to restrict incoming network traffic to a Solaris machine. Network traffic is normally from remote servers and clients to local clients and servers(local network services), respectively. Other types of network traffic include broadcasts and ICMP messages. The goal of any firewall is to block unwanted incoming network traffic and/or restrict access to certain source(s) while allow local client programs to work seamlessly. A three layer approach with different precedence levels helps us achieve the desired behaviors. Global Default - default system-wide policy. This policy is automatically inherited by all services unless services modify their firewall policy. Network Services - higher precedence than Global Default. A service's policy allows/disallows traffic to its specific ports, regardless of Global Default policy. Global Override - another system-wide policy that takes precedence over the needs of specific services in Network Services layer. Global Override | | Network Services | | Global Default A firewall policy includes a firewall mode and an optional set of network sources. Network sources are IP addresses, subnets, and local network interfaces, from which a system can receive incoming traffic. The basic set of firewall modes are: None - no firewall, allow all incoming traffic Deny - allow all incoming traffic but deny from specified source(s) Allow - deny all incoming traffic but allow from specified source(s) Layers in Detail: The first system-wide layer, Global Default, defines a firewall policy that applies to *any* incoming traffic, e.g. allowing or blocking all traffic from an IP address. This makes it simple to have a policy that blocks all incoming traffic or all incoming traffic from unwanted source(s). The Network Services layer contains firewall policies for local programs that provide service to remote clients, e.g. telnetd, sshd, and httpd. Each of these programs, a network service, has its own firewall policy that controls access to its service. Initially, a service's policy is set to inherit Global Default policy, a "Use Global Default" mode. This makes it simple to set a single policy, at the Global Default layer, that can be inherited by all services. When a service's policy is different from Global Default policy, the service's policy has higher precedence. If Global Default policy is set to block all traffic from a subnet, the SSH service could be configured to allow access from certain hosts in that subnet. The set of all policies for all network services comprises the Network Service layer. The second sytem-wide layer, Global Override, has a firewall policy that also applies to any incoming network traffic. This policy has highest precedence and overrides policies in other layers, specifically overriding the needs of network services. The example is when it's desirable block known malicious source(s) regardless of services' policies. User Interaction: This framework leverages IPfilter functionality and is only active when svc:/network/ipfilter is enabled. Similarly, a network service's firewall policy is only active when that service is enabled. A system with an active firewall has IPfilter rules for each running/enabled network service and for system-wide policy(s) with firewall mode other than "None". User's enabling and disabling action for a service corresponds to firewall policy activation and deactivation for that service. A user changes firewall settings by modifying a service and/or system-wide firewall policy. The firewall framework composes of policy configuration and a mechanism to generate ipfilter rules from the policy and applying those rules to get the desired IPfilter configuration. A quick breakdown of the design: - system-wide policy(s) are stored in network/ipfilter - network services' policies are stored in each SMF service - activate firewall by enabling network/ipfilter - activate/deactivate per-service firewall policy by enabling/disabling that network service - changing a system-wide or per-service firewall policy results in an update to the system's firewall rules 4. Configuration See the new svc.ipfd.1m 5. Exported Interfaces Service static configuration property group and properties: firewall_context/name Committed firewall_context/isrpc Committed firewall_context/ipf_method Committed Service firewall configuration property groups and properties: firewall_config/policy Committed firewall_config/apply_to Committed firewall_config/exceptions Committed Global Default policy property groups and properties: firewall_config_default/policy Committed firewall_config_default/apply_to Committed firewall_config_default/exceptions Committed firewall_config_default/custom_policy_file Committed firewall_config_default/open_ports Committed Global Override policy property groups and properties: firewall_config_override/policy Committed firewall_config_override/apply_to Committed firewall_config_override/exceptions Committed FMRIs for system-wide policies: svc:/network/ipfilter:default Committed 6. Imported Interfaces libnsl(3LIB) libsocket(3LIB) 7. Documentation changes The SMF FAQ on opensolaris.org will be updated to contain a how-to for both users and service developers. svc.ipfd.1m(new) System Administration Commands svc.ipfd(1M) NAME svc.ipfd - IPfilter firewall monitoring daemon SYNOPSIS /lib/svc/bin/svc.ipfd svc:/network/ipfilter:default DESCRIPTION svc.ipfd monitors actions to services with firewall configuration and initiates update services' IPfilter configuration. The daemon allows us to react to changes in system's firewall configuration in an incremental fashion, at per service level. A service's firewall policy is activated when it's enabled, deactivated when it's disabled, and updated when its configuration property group is modified. svc.ipfd monitors SMF repository for these actions and invokes IPfilter rule generation process to carry out the service's firewall policy. Environment Variables and Context This daemon is started by the network/ipfilter service either through the start or refresh method. Thus, the daemon inherits the environment variables and credentials from the method and runs as root user the variable: SMF_FMRI=svc:/network/ipfilter:default FIREWALL STATIC CONFIGURATION Static definition describing service's network resource configuration that is used to generate service specific ipf rules. A new per service "firewall_context" property group contains a service's static definition, similar to "inetd" property group in inetd managed services. - firewall_context/name, IANA name or RPC name for non-inetd service, equivalent to inetd/name property - firewall_context/isrpc, a boolean property where a "true" value indicates an RPC service, equivalent to inetd/isrpc property. For RPC services, the value of firewall_context/name is not an IANA name but is either an RPC program number or name, see rpc(4). Additionally, some services may require a mechanism to generate and supply their own ipf rules. An optional property ipf_method, provides a mechanism to allow custom rule generation. - firewall_context/ipf_method, a command, normally a script that generates ipf rules for a service. The framework does not generate rules for services with this property definition but expect these services to provide their own rules. A service's ipf_method specifies a command that takes an additional argument, its own fmri and generates the service's firewall rules and output the rules to stdout. To generate rules for a service with ipf_method property, the framework execs the command specified in ipf_method, passing the service fmri as the additional argument and stores the rules for that service by redirecting the command output, the rules, to the service's rule file. Because an ipf_method is exec'ed from the context of either network/ipfilter start or refresh method process, it inherits the execution context and runs as root. Administrative Privilege The service static configuration, is delivered by service developer and and not intended to be modified by users. These properties are only modified upon installation of an updated service definition. FIREWALL POLICY CONFIGURATION A per service property group, firewall_config, stores the services' firewall policy configuration. Since network/ipfilter:default is responsible for two firewall policies, Global Default and Global Override system-wide policies as explained in ipfilter(5), it has two property groups, firewall_config_default and firewall_config_override, to store the respective sytem-wide policies. Below are the properties, their possible values and correspoding semantics: policy "none" policy mode - no access restriction. For a global policy, this mode allows all incoming traffic. For a service policy, this mode allows all incoming traffic to its service. "deny" policy mode: more restrictive than "none". This mode allows incoming traffic from all sources except those specified in the "apply_to" property. "allow" policy mode: most restrictive mode. This mode blocks incoming traffic from all sources except those specified in the "apply_to" property. apply_to A multi-value property listing network entities to enforce the chosen policy mode. Entities listed in apply_to property will be denied if policy is "deny" and allowed if policy is "allow". The syntax for possible values are: host: host:IP "host:192.168.84.14" subnet: network:IP/netmask "network:129.168.1.5/24" interface: if:interface_name "if:e1000g0" exceptions A multi-value property listing network entities to be excluded from the "apply_to" list. For example, when deny policy is applied to a subnet, exceptions can be made to some hosts in that subnet by specifying them in the "exceptions" property. This property has the same value syntax as "apply_to" property. For individual network services only: firewall_config/policy A service's policy can also be set to "use_global". Services with "use_global" policy mode inherits the Global Default firewall policy. For the Global Default only: firewall_config_default/policy - can also be set to "custom" Global Default policy, firewall_config property group in svc:/network/ipfilter:default, can also be set to "custom". Users can set policy to "custom" to use prepopulated IPfilter configuration, e.g. existing IPfilter configuration or custom configurations that can't be provided by the framework. This Global Default only policy mode allows users to supply a text file containing the complete set of ipf rules. When "custom" mode is selected, the specified set of ipf rules is *complete* and the framework will not generate ipf rules from configured firewall policies. firewall_config_default/custom_policy_file A file path to be used when Global Default policy is set to "custom". The file contains a set of ipf rules which provide the desired IPfiler configuration. firewall_config_default/open_ports Non-service program requiring allowance of its incoming traffic can request the firewall to allow traffic to its communication ports. This multi-value property property contains protocol and port(s) tuple in the form "{tcp | udp}:{PORT | PORT-PORT}" Initially, the system-wide policies are set to "none" and network services' policies are set to "use_global". Enabling network/ipfilter activates the firewall with an empty set of ipfilter rules, since system-wide policy is "none" and all services inherit that policy. To configure a more restrictive policy, use svccfg(1M) to modify network services and system-wide policies. Administrative Privilege User configures firewall policy by modifying the service's firewall_config property group. A new authorization "solaris.smf.value.firewall.config" is created to allow delgation of firewall administration privilege to users. The Service Operator users will need this new authorization to be able to configuration firewall policy. DEVELOPER DOCUMENTATION Services providing remote capabilities are encouraged to participate in the firewall framework to control network access to the service. While framework integration isn't mandatory, remote access to services that are not integrated in the framework may not function correctly when a system-wide policy is configured. Integrating a service into the framework is as straightforward as defining two additional property groups and their corresponding properties in the service manifest. IPfilter rules are generated when user enables the service. In the non-trivial case of custom rule generation where a shell script is required, there are existing scripts that can be used as examples. The additional property groups, firewall_config and firewall_context stores firewall policy configuration and provides static firewall definition, respectively. Below is a summary of new property groups and properties and their appropriate default values. Firewall policy configuration: firewall_config See FIREWALL POLICY CONFIGURATION section for more information. Access to is protected by a new authorization definition and a user-defined property type. The new authorization should be assigned to the property group value_authorization property such as Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_configuration" as the property type. firewall_config/policy This property's initial value should be "use_global" since services, by default, inherit the Global Default firewall policy. firewall_config/apply_to An empty property, this property has no initial value. firewall_config/exceptions An empty property, this property has no initial value. Firewall static definition: firewall_context See FIREWALL STATIC CONFIGURATION section for more information. Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_definition" as the property type. firewall_context/name Service with well-known, IANA defined port which can be obtained by getservbyname(3SOCKET), the service's IANA name is stored in this property. For RPC services, the RPC program number is stored in this property. firewall_context/isrpc For RPC services, this property should be created with its value set to "true" firewall_context/ipf_method In general, the specified firewall policy is used to generate IPfilter rules to the service's communication port, derived from firewall_context/name property. Services which don't have IANA defined ports and are not RPC services, will need to generate their own IPfilter rules. Services that generate their own rules may choose not to have firewall_context/name and firewall_context/isrpc properties. See the following services svc:/network/ftp:default svc:/network/nfs/server:default svc:/network/ntp:default and others with existing ipf_method for guidance. ATTRIBUTES See attributes(5) for descriptions of the following attributes: System Administration Commands svc.ipfd(1M) ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu SUNWipfr | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO ipfilter(5), ipf(4), rpc(4), svcs(1), svcprop(1), svcadm(1M), svccfg(1M), attributes(5), smf(5) --- /tmp/ipfilter.5.orig Fri Sep 12 14:27:32 2008 +++ /home/tn143363/vpanels/firewall/ipfilter.5 Fri Sep 12 14:03:21 2008 @@ -19,6 +19,118 @@ See ipf(1M) for a procedure to enable and activate the IP Filter feature. +HOST-BASED FIREWALL + To simplify IPfilter configuration management, a firewall framework is + created to allow users to configure IPfilter by expressing firewall policy + at system and service level. Given the user defined firewall policy, the + framework generates a set of IPfilter rules to enforce the desired system + behavior. Users specify system and service firewall policies that allow or + deny network traffic from certain hosts, subnets, and interface(s). The + policies are translated into a set of active ipf rules to enforce the + specified firewall policies. + + Note - + + Users can still specify their own ipf rule file if they choose not to + take advantage of the framework. See svc.ipf(1M) and ipf(4). + + Model + + This section describes the host-based firewall framework. See svc.ipfd(1M) + for details on how to configure firewall policies. + + A three layer approach with different precedence levels helps us achieve + the desired behaviors. + + Global Default - default system-wide firewall policy. This policy is + automatically inherited by all services unless services modify their + firewall policy. + + Network Services - higher precedence than Global Default. A service's + policy allows/disallows traffic to its specific ports, regardless of + Global Default policy. + + Global Override - another system-wide policy that takes precedence over + the needs of specific services in Network Services layer. + + Global Override + | + | + Network Services + | + | + Global Default + + A firewall policy includes a firewall mode and an optional set of network + sources. Network sources are IP addresses, subnets, and local network + interfaces, from which a system can receive incoming traffic. The basic set + of firewall modes are: + + None - no firewall, allow all incoming traffic + + Deny - allow all incoming traffic but deny from specified source(s) + + Allow - deny all incoming traffic but allow from specified source(s) + + Layers in Detail + + The first system-wide layer, Global Default, defines a firewall policy + that applies to *any* incoming traffic, e.g. allowing or blocking all + traffic from an IP address. This makes it simple to have a policy that + blocks all incoming traffic or all incoming traffic from unwanted source(s). + + The Network Services layer contains firewall policies for local programs + that provide service to remote clients, e.g. telnetd, sshd, and httpd. + Each of these programs, a network service, has its own firewall policy + that controls access to its service. Initially, a service's policy is set + to inherit Global Default policy, a "Use Global Default" mode. This makes + it simple to set a single policy, at the Global Default layer, that can be + inherited by all services. + + When a service's policy is different from Global Default policy, the + service's policy has higher precedence. If Global Default policy is set + to block all traffic from a subnet, the SSH service could be configured to + allow access from certain hosts in that subnet. The set of all policies + for all network services comprises the Network Service layer. + + The second sytem-wide layer, Global Override, has a firewall policy that + also applies to any incoming network traffic. This policy has highest + precedence and overrides policies in the other layers, specifically + overriding the needs of network services. The example is when it's + desirable block known malicious source(s) regardless of services' + policies. + + User Interaction + + This framework leverages IPfilter functionality and is active only when + svc:/network/ipfilter is enabled and inactive when network/ipfilter is + disabled. Similarly, a network service's firewall policy is only active + when that service is enabled and inactive when the service is disabled. A + system with an active firewall has IPfilter rules for each running/enabled + network service and system-wide policy(s) whose firewall mode isn't "None." + User configures firewall by setting the system-wide policies and policy + for each network service. See svc.ipfd(1M) on how to configure a firewall + policy. + + The firewall framework composes of policy configuration and a mechanism to + generate ipfilter rules from the policy and applying those rules to get + the desired IPfilter configuration. A quick summary of the design and user + interaction: + + - system-wide policy(s) are stored in network/ipfilter + + - network services' policies are stored in each SMF service + + - user activates firewall by enabling network/ipfilter, see ipf(1M) + + - user activates/deactivate a service's firewall by enabling/disabling + that network service + + - changes to system-wide or per-service firewall policy results in an + update to the system's firewall rules + --- /tmp/ipf.1m.orig Fri Sep 12 14:10:40 2008 +++ /home/tn143363/vpanels/firewall/ipf.1m Fri Sep 12 14:21:46 2008 @@ -46,7 +46,8 @@ ment rights profile (see rbac(5)) or become superuser. - 2. Create a packet filtering rule set. See ipf(4). + 2. Configure system and services' firewall policies. + See svc.ipfd(1M) and ipf(4). 3. (Optional) Create a network address translation (NAT) configuration file. See ipnat.conf(4). @@ -84,35 +85,16 @@ - To re-enable packet filtering after it has been temporarily - disabled either reboot the machine or perform the following - series of commands: + disabled either reboot the machine or run the following + command: - 1. Enable Solaris IP Filter: + # svcadm enable network/ipfilter - # ipf -E - - - - 2. Activate packet filtering: - - # ipf -f - - - - 3. (Optional) Activate NAT: - - ipnat -f - - - See ipnat(1M). - Note - - If you reboot your system, the packet filtering rules in - the /etc/ipf/ipf.conf file and the /etc/ipf/ipnat.conf - file are activated. + If you reboot your system, the IPfilter configuration is + automatically activated. --Boundary_(ID_MLtqezvVqHSXWyNZ9UbvTg) Content-type: text/plain; name=service_list Content-transfer-encoding: 7BIT Content-disposition: inline; filename=service_list The proposed project will modify the below, tentative lists of services to use the firewall framework. The client services are client programs whose proper operations requires certain IPfilter rules to allow their incoming traffic. Network services network/comsat:default network/finger:default network/ftp:defaultxml network/routing/rdisc:default network/routing/route:default network/talk:default network/login:eklogin network/login:klogin network/login:rlogin network/rexec:default network/shell:default network/shell:kshell network/telnet:default network/nfs/rquota:default network/nfs/server:default network/ipfilter:default network/smtp:sendmail network/ntp:default network/dns/multicast:default network/dhcp-server:default network/ssl/proxy network/smb/server:default network/ssh:default network/echo:dgram network/echo:stream network/discard:dgram network/discard:stream network/time:dgram network/time:stream network/daytime:dgram network/daytime:stream network/rpc/bind:default network/rpc/mdcomm:default network/rpc/meta:default network/rpc/metamed:default network/rpc/metamh:default network/rpc/rex:default network/rpc/nisplus:default network/rpc/bootparams:default network/rpc/rstat:default network/rpc/rusers:default network/rpc/spray:default network/rpc/wall:default application/print/server:default application/print/rfc1179:default application/print/ipp-listener:default system/idmap:default system/system-log:default Non-ON services application/management/seaport:default application/management/sma:default application/management/snmpdx application/management/wbem:default application/management/webmin:default network/dns/server:default network/http:squid network/http:lighttpd14 network/ssl/stunnel:default system/webconsole:console x11/xvnc-inetd:default x11/x11-server Client services network/nis/client:default network/smb/client:default network/nfs/cbd:default network/nfs/nlockmgr:default network/nfs/status:default --Boundary_(ID_MLtqezvVqHSXWyNZ9UbvTg)-- From ceri@submonkey.net Wed Sep 24 03:50:47 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8OAoksi006952 for ; Wed, 24 Sep 2008 03:50:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8OAoavg017769; Wed, 24 Sep 2008 18:50:44 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7P005054SJXE00@brm-avmta-1.central.sun.com>; Wed, 24 Sep 2008 04:50:43 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7P00B2K4SIDBF0@brm-avmta-1.central.sun.com>; Wed, 24 Sep 2008 04:50:42 -0600 (MDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8OAh567019058; Wed, 24 Sep 2008 10:50:41 +0000 (GMT) Received: from mms24es.mms.us.syntegra.com ([150.143.232.70] [150.143.232.70]) by relay22i.sun.com with ESMTP id BT-MMP-4215987; Wed, 24 Sep 2008 10:50:41 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms24es.mms.us.syntegra.com with ESMTP id BT-MMP-135588316; Wed, 24 Sep 2008 10:50:41 +0000 (Z) Received: from scuttle.submonkey.net ([208.111.43.184] [208.111.43.184]) by relay22i.sun.com with ESMTP id BT-MMP-21400501; Wed, 24 Sep 2008 10:50:41 +0000 (Z) Received: from cpc1-cdif1-0-0-cust63.cdif.cable.ntl.com ([81.104.164.64] helo=shrike.submonkey.net) by scuttle.submonkey.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KiRwF-0005Ow-9t; Wed, 24 Sep 2008 10:49:43 +0000 Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KiRx8-0007Po-1b; Wed, 24 Sep 2008 11:50:38 +0100 Date: Wed, 24 Sep 2008 11:50:37 +0100 From: Ceri Davies Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DA1309.9060408@Sun.COM> Sender: Ceri Davies To: Darren Reed Cc: psarc-ext@sun.com, Tony Nguyen Message-id: <20080924105037.GB43097@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=0.0/5.0, scanned in 0.212sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <48DA1309.9060408@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) Status: RO Content-Length: 2065 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 24, 2008 at 12:14:33PM +0200, Darren Reed wrote: > I am submitting this case on behalf of Tony Nguyen. > This case seeks to enable tieing together service availability in SMF > with IPFilter for firewalling of access to them. > This case is requesting patch/micro binding. > The timeout has been set for Wednesday next week (30/9/2008.) > policy >=20 > "none" policy mode - no access restriction. For a global policy, this > mode allows all incoming traffic. For a service policy, this mode > allows all incoming traffic to its service. >=20 > "deny" policy mode: more restrictive than "none". This mode allows > incoming traffic from all sources except those specified in the > "apply_to" property. >=20 > "allow" policy mode: most restrictive mode. This mode blocks incoming > traffic from all sources except those specified in the "apply_to" > property. >=20 > apply_to > =20 > A multi-value property listing network entities to enforce the > chosen policy mode. Entities listed in apply_to property will be denied > if policy is "deny" and allowed if policy is "allow". The syntax for > possible values are: >=20 > host: host:IP "host:192.168.84.14" > subnet: network:IP/netmask "network:129.168.1.5/24" > interface: if:interface_name "if:e1000g0" Any chance that this could be extended to allow specification of a pre-existing ippool? It's certainly the case here that a set of developers are often given access to different services together via a pool. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFI2ht9ocfcwTS3JF8RAs9OAJwLW2d/aNcfmII/yiJpq16MTV4yWgCfaY1L dhlpkeszyhuHAILd+WHSVSo= =PoOw -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From Truong.Q.Nguyen@sun.com Wed Sep 24 11:02:15 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8OI2EHI022223 for ; Wed, 24 Sep 2008 11:02:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8OI20x8024261 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 24 Sep 2008 11:02:14 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7P0096ROROGM00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 11:02:12 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7P000DYORMF1C0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 11:02:10 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8OI2ABE004133 for ; Wed, 24 Sep 2008 18:02:10 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7P00B01MZ2BA00@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 12:02:10 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7P00KV6OR8XO60@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 12:01:56 -0600 (MDT) Date: Wed, 24 Sep 2008 11:01:55 -0700 From: Tony Nguyen Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <20080924105037.GB43097@submonkey.net> Sender: Truong.Q.Nguyen@sun.com To: Ceri Davies Cc: Darren Reed , PSARC-ext@sun.com Message-id: <48DA8093.805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924105037.GB43097@submonkey.net> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 1689 Ceri Davies wrote: > On Wed, Sep 24, 2008 at 12:14:33PM +0200, Darren Reed wrote: >> I am submitting this case on behalf of Tony Nguyen. >> This case seeks to enable tieing together service availability in SMF >> with IPFilter for firewalling of access to them. >> This case is requesting patch/micro binding. >> The timeout has been set for Wednesday next week (30/9/2008.) > >> policy >> >> "none" policy mode - no access restriction. For a global policy, this >> mode allows all incoming traffic. For a service policy, this mode >> allows all incoming traffic to its service. >> >> "deny" policy mode: more restrictive than "none". This mode allows >> incoming traffic from all sources except those specified in the >> "apply_to" property. >> >> "allow" policy mode: most restrictive mode. This mode blocks incoming >> traffic from all sources except those specified in the "apply_to" >> property. >> >> apply_to >> >> A multi-value property listing network entities to enforce the >> chosen policy mode. Entities listed in apply_to property will be denied >> if policy is "deny" and allowed if policy is "allow". The syntax for >> possible values are: >> >> host: host:IP "host:192.168.84.14" >> subnet: network:IP/netmask "network:129.168.1.5/24" >> interface: if:interface_name "if:e1000g0" > > Any chance that this could be extended to allow specification of a > pre-existing ippool? It's certainly the case here that a set of > developers are often given access to different services together via a > pool. > Hi Ceries, A very good suggestion and Darren also suggested this in the past. I'll work on providing support for ippool. Thanks, tony From Nicolas.Williams@sun.com Wed Sep 24 11:52:17 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8OIqGDg023300 for ; Wed, 24 Sep 2008 11:52:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8OIq94L037581; Wed, 24 Sep 2008 12:52:14 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7P0003PR30KF00@nwk-avmta-2.sfbay.sun.com>; Wed, 24 Sep 2008 11:52:12 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.107]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7P00IQDR2ZC8D0@nwk-avmta-2.sfbay.sun.com>; Wed, 24 Sep 2008 11:52:12 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m8OIq0Yt014920; Wed, 24 Sep 2008 13:52:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8OIq0uI014919; Wed, 24 Sep 2008 13:52:00 -0500 (CDT) Date: Wed, 24 Sep 2008 13:52:00 -0500 From: Nicolas Williams Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DA1309.9060408@Sun.COM> To: Darren Reed Cc: psarc-ext@sun.com, Tony Nguyen Message-id: <20080924185200.GB9765@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2237 On Wed, Sep 24, 2008 at 12:14:33PM +0200, Darren Reed wrote: > Below are the properties, their possible values and correspoding semantics: > > policy > > "none" policy mode - no access restriction. For a global policy, this > mode allows all incoming traffic. For a service policy, this mode > allows all incoming traffic to its service. > > "deny" policy mode: more restrictive than "none". This mode allows > incoming traffic from all sources except those specified in the > "apply_to" property. > > "allow" policy mode: most restrictive mode. This mode blocks incoming > traffic from all sources except those specified in the "apply_to" > property. I find this confusing or likely to be confusing. How about: "any" -> allow all incoming "blacklist" -> allow all incoming where source not on blacklist "whitelist" -> allow incoming only from sources listed in whitelist "none" -> disallow all incoming instead of "none," "deny" and "allow"? Or, better yet, why not replace "policy"/"apply_to" with "blacklist"/ "whitelist"? > apply_to > > A multi-value property listing network entities to enforce the > chosen policy mode. Entities listed in apply_to property will be denied > if policy is "deny" and allowed if policy is "allow". The syntax for > possible values are: > > host: host:IP "host:192.168.84.14" > subnet: network:IP/netmask "network:129.168.1.5/24" > interface: if:interface_name "if:e1000g0" Why do we need 'host'/'subnet' when we have CIDR notation? And if there's no hostnames then we don't need 'if' for interface names either. Also, what do interface name values mean? "Any from this interface's subnet"? "Any arriving on this interface"? (I'm sure it's the latter, but the docs have to be clear.) What about IPv6? > exceptions > > A multi-value property listing network entities to be excluded from the > "apply_to" list. For example, when deny policy is applied to a subnet, > exceptions can be made to some hosts in that subnet by specifying them > in the "exceptions" property. This property has the same value syntax > as "apply_to" property. Why not just have '!' notation in apply_to instead of this exceptions property? Nico -- From Nicolas.Williams@sun.com Wed Sep 24 12:00:05 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8OJ059O023841 for ; Wed, 24 Sep 2008 12:00:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8OJ028O023709; Wed, 24 Sep 2008 12:00:03 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7P00G0HRG2SG00@brm-avmta-1.central.sun.com>; Wed, 24 Sep 2008 13:00:02 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.107]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7P009FORG1Z7A0@brm-avmta-1.central.sun.com>; Wed, 24 Sep 2008 13:00:02 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m8OIxo4e014948; Wed, 24 Sep 2008 13:59:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8OIxolh014947; Wed, 24 Sep 2008 13:59:50 -0500 (CDT) Date: Wed, 24 Sep 2008 13:59:50 -0500 From: Nicolas Williams Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DA1309.9060408@Sun.COM> To: Darren Reed Cc: psarc-ext@sun.com, Tony Nguyen Message-id: <20080924185950.GC9765@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 410 On Wed, Sep 24, 2008 at 12:14:33PM +0200, Darren Reed wrote: > Environment Variables and Context Listing the method context is important, but listing environment variables normally inherited from the SMF restarter strikes me as not important. If there are any environment variables that are specific to this service and they are intended to be public interfaces, then they should be documented, of course. From edward.pilatowicz@sun.com Wed Sep 24 14:50:26 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8OLoPkT029989 for ; Wed, 24 Sep 2008 14:50:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8OLoKkU024047; Wed, 24 Sep 2008 22:50:20 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7P00A05ZBVBC00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Sep 2008 14:50:19 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7P00CE8ZBVG2D0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Sep 2008 14:50:19 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8OLoJX0703362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 14:50:19 -0700 (PDT) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id m8OLoJWJ703361; Wed, 24 Sep 2008 14:50:19 -0700 (PDT) Date: Wed, 24 Sep 2008 14:50:19 -0700 From: Edward Pilatowicz Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DA1309.9060408@Sun.COM> To: Darren Reed Cc: psarc-ext@sun.com, Tony Nguyen Message-id: <20080924215019.GB957374@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 857 just one quick question. given that ipfilter service specific configuration is stored with the services themselves, how will the user know if a specific service has an invalid ipfilter configuration? will that specific service fail go into the maintainance state? or will the ipfilter:default service go into the maintainance state? ed On Wed, Sep 24, 2008 at 12:14:33PM +0200, Darren Reed wrote: > I am submitting this case on behalf of Tony Nguyen. > This case seeks to enable tieing together service availability in SMF > with IPFilter for firewalling of access to them. > This case is requesting patch/micro binding. > The timeout has been set for Wednesday next week (30/9/2008.) > > Completed versions of the man pages being altered (ipf.1m, ipfilter.5) > can be found in the case directory - only diffs are included in this email. > > Darren > From Truong.Q.Nguyen@sun.com Wed Sep 24 16:09:13 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8ON9CDh001619 for ; Wed, 24 Sep 2008 16:09:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8ON99Uw019497 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 25 Sep 2008 00:09:11 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7Q00B012ZAH800@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 16:09:10 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7Q0088B2Z9UZ70@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 16:09:09 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8ON99Ef018871 for ; Wed, 24 Sep 2008 23:09:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7Q00B012V4V400@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 17:09:09 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7Q00JFW2Z4DS40@mail-amer.sun.com>; Wed, 24 Sep 2008 17:09:04 -0600 (MDT) Date: Wed, 24 Sep 2008 16:09:04 -0700 From: Tony Nguyen Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <20080924215019.GB957374@eng.sun.com> Sender: Truong.Q.Nguyen@sun.com To: Edward Pilatowicz Cc: Darren Reed , psarc-ext@sun.com Message-id: <48DAC890.7030303@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924215019.GB957374@eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 1371 Edward Pilatowicz wrote: > just one quick question. > > given that ipfilter service specific configuration is stored with > the services themselves, how will the user know if a specific service > has an invalid ipfilter configuration? will that specific service > fail go into the maintainance state? or will the ipfilter:default > service go into the maintainance state? > Hi Ed, In the current design, firewall is an value-add and doesn't affect service's availability. Thus, invalid policies would either generate an empty set of ipf rules or generate invalid ipf rules. In the case of invalid ipf rules, we try to validate the set of rules(ipf -n) to prevent network/ipfilter from going into maintenance which I believe is the current behavior if network/ipfilter is given a ipf.conf with invalid rules. Thanks, tony > > > On Wed, Sep 24, 2008 at 12:14:33PM +0200, Darren Reed wrote: >> I am submitting this case on behalf of Tony Nguyen. >> This case seeks to enable tieing together service availability in SMF >> with IPFilter for firewalling of access to them. >> This case is requesting patch/micro binding. >> The timeout has been set for Wednesday next week (30/9/2008.) >> >> Completed versions of the man pages being altered (ipf.1m, ipfilter.5) >> can be found in the case directory - only diffs are included in this email. >> >> Darren >> From Truong.Q.Nguyen@sun.com Wed Sep 24 16:22:54 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8ONMr9q001862 for ; Wed, 24 Sep 2008 16:22:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8ONMpNI004420 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 25 Sep 2008 07:22:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7Q00C053M25C00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 16:22:50 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7Q008GM3M2UW90@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 16:22:50 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8ONMnYc008776 for ; Wed, 24 Sep 2008 23:22:49 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7Q00J0136OE500@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Sep 2008 17:22:49 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7Q00J2P3M0DS70@mail-amer.sun.com>; Wed, 24 Sep 2008 17:22:49 -0600 (MDT) Date: Wed, 24 Sep 2008 16:22:48 -0700 From: Tony Nguyen Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <20080924215019.GB957374@eng.sun.com> Sender: Truong.Q.Nguyen@sun.com To: Edward Pilatowicz Cc: Darren Reed , psarc-ext@sun.com Message-id: <48DACBC8.8030304@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924215019.GB957374@eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 616 Edward Pilatowicz wrote: > just one quick question. > > given that ipfilter service specific configuration is stored with > the services themselves, how will the user know if a specific service > has an invalid ipfilter configuration? will that specific service > fail go into the maintainance state? or will the ipfilter:default > service go into the maintainance state? > Ed, Think I missed your point in my earlier response. Putting a service into maintenance seems heavy-handed but we need the observability. How about a message in network/ipfilter log file? Do you have other suggestions? thanks, tony From Andrew.Gabriel@sun.com Thu Sep 25 04:58:46 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8PBwj2O022152 for ; Thu, 25 Sep 2008 04:58:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8PBwhIu011752 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 25 Sep 2008 12:58:44 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7R001092LUO600@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 05:58:42 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7R000TV2LUKU00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 05:58:42 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8PBwfaa014796 for ; Thu, 25 Sep 2008 11:58:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7R0000119AA800@fe-emea-09.sun.com> (original mail from Andrew.Gabriel@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 12:58:41 +0100 (BST) Received: from [172.20.100.173] ([24.6.174.100]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7R001B82LIA6C0@fe-emea-09.sun.com>; Thu, 25 Sep 2008 12:58:37 +0100 (BST) Date: Thu, 25 Sep 2008 12:58:24 +0100 From: Andrew Gabriel Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DACBC8.8030304@sun.com> Sender: Andrew.Gabriel@sun.com To: Tony Nguyen Cc: Edward Pilatowicz , Darren Reed , psarc-ext@sun.com Message-id: <48DB7CE0.8020108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924215019.GB957374@eng.sun.com> <48DACBC8.8030304@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080811) Status: RO Content-Length: 1099 Tony Nguyen wrote: > Edward Pilatowicz wrote: >> just one quick question. >> >> given that ipfilter service specific configuration is stored with >> the services themselves, how will the user know if a specific service >> has an invalid ipfilter configuration? will that specific service >> fail go into the maintainance state? or will the ipfilter:default >> service go into the maintainance state? >> > > Ed, > > Think I missed your point in my earlier response. Putting a service into > maintenance seems heavy-handed but we need the observability. How about > a message in network/ipfilter log file? Do you have other suggestions? See also: CR 6623013 /lib/svc/method/ipfilter method fails to check for or log any errors Having rest of system come up with ipfiltering not working is very nasty -- it means you are missing your security filtering and system is wide open. Currently, that's not visible or reported anywhere. Ideally, bringing up of network interfaces should depend on correct application of ipfilter rules, although this case would make that much harder. -- Andrew From Darren.Reed@Sun.COM Thu Sep 25 07:12:59 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8PECxng026357 for ; Thu, 25 Sep 2008 07:12:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8PECwG0041355 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 25 Sep 2008 08:12:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7R004038TMSE00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 07:12:58 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7R002XQ8TKT720@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 07:12:57 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8PECu2b018660 for ; Thu, 25 Sep 2008 14:12:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7R00E017FOW400@fe-emea-09.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 15:12:56 +0100 (BST) Received: from [129.157.18.218] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7R009CT8T21NB0@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 15:12:38 +0100 (BST) Date: Thu, 25 Sep 2008 16:12:33 +0200 From: Darren Reed Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <20080924185200.GB9765@Sun.COM> Sender: Darren.Reed@Sun.COM To: Nicolas Williams Cc: psarc-ext@Sun.COM, Tony Nguyen Message-id: <48DB9C51.9010407@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 3308 Nicolas Williams wrote: > On Wed, Sep 24, 2008 at 12:14:33PM +0200, Darren Reed wrote: > >> Below are the properties, their possible values and correspoding semantics: >> >> policy >> >> "none" policy mode - no access restriction. For a global policy, this >> mode allows all incoming traffic. For a service policy, this mode >> allows all incoming traffic to its service. >> >> "deny" policy mode: more restrictive than "none". This mode allows >> incoming traffic from all sources except those specified in the >> "apply_to" property. >> >> "allow" policy mode: most restrictive mode. This mode blocks incoming >> traffic from all sources except those specified in the "apply_to" >> property. >> > > I find this confusing or likely to be confusing. > > How about: > > "any" -> allow all incoming > "blacklist" -> allow all incoming where source not on blacklist > "whitelist" -> allow incoming only from sources listed in whitelist > "none" -> disallow all incoming > > instead of "none," "deny" and "allow"? > > Or, better yet, why not replace "policy"/"apply_to" with "blacklist"/ > "whitelist"? > This is bikeshed'ing...and you've forgotten grey...or it gray and not grey? IMHO, I prefer to see relevant policy words that are in common use elsewhere in the industry for control words. Nowhere else in [Open]Solaris do we have the concept of "white" and "black" (that I'm aware of), so it would seem extremely inappropriate to introduce that new concept here. >> apply_to >> >> A multi-value property listing network entities to enforce the >> chosen policy mode. Entities listed in apply_to property will be denied >> if policy is "deny" and allowed if policy is "allow". The syntax for >> possible values are: >> >> host: host:IP "host:192.168.84.14" >> subnet: network:IP/netmask "network:129.168.1.5/24" >> interface: if:interface_name "if:e1000g0" >> > > Why do we need 'host'/'subnet' when we have CIDR notation? And if > there's no hostnames then we don't need 'if' for interface names either. > I'd rather it be possible to be explicit in nature about the nature of what an object is, when it comes to security, so that you are in a better position to try and catch simple mistakes. For example, if someone put in "host:192.168.84.14/24", because they did a copy paste from somewhere else, what does that mean? Isn't it better to say "ok, they wanted a host, gave me a CIDR so I'll give them an error" than to just accept it and try to guess that the user wanted a network instead of a host, possibly creating a security exposure? >> exceptions >> >> A multi-value property listing network entities to be excluded from the >> "apply_to" list. For example, when deny policy is applied to a subnet, >> exceptions can be made to some hosts in that subnet by specifying them >> in the "exceptions" property. This property has the same value syntax >> as "apply_to" property. >> > > Why not just have '!' notation in apply_to instead of this exceptions > property? > Thinking of it in terms of usability, it would seem better (to me), to have a list of things you allow and a list of exceptions to that list, rather than a combined list that you need to sift through to work out what's what. Darren From edward.pilatowicz@sun.com Thu Sep 25 09:08:15 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8PG8FEs029265 for ; Thu, 25 Sep 2008 09:08:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8PG8383009442; Thu, 25 Sep 2008 09:08:12 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7R00G2ZE5N2100@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Sep 2008 09:08:11 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7R00CHJE5MRR60@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Sep 2008 09:08:10 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8PG7pwP862060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 09:07:57 -0700 (PDT) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id m8PG7j5V862048; Thu, 25 Sep 2008 09:07:45 -0700 (PDT) Date: Thu, 25 Sep 2008 09:07:45 -0700 From: Edward Pilatowicz Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DACBC8.8030304@sun.com> To: Tony Nguyen Cc: Darren Reed , psarc-ext@sun.com Message-id: <20080925160745.GD957374@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924215019.GB957374@eng.sun.com> <48DACBC8.8030304@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 2034 hey tony, imho, if an admin configures ipfilter settings incorrectly, haveing the system come up and not actively notify the admin of the misconfiguration seems bad and broken. ipfilters is a critical part of system security, if it's configuration is invalid, the security of the system may be compromised and it's important for the admin to know about this. having the admin "poll" log files for errors is not a valid option. i personally think it would be much more appropriate to have a smf service fail to start, and an error message should be generated and put into the smf service log file clearly indicating the reason for the failure. you could have the ipfilter service itself fail to start, but i think it would be better to have the individual service that has the invalid configuration parameters fail to start. the reason i think the latter option is better is because it means that the services aren't running exposed. for example, if i incorrectly configure ssh with an allow ipfiler configuration, then if the ipfilter smf services goes into maintainance then all my services on the machine are accessible (read exposed to the world) until i fix the ssh ipfilter configuration. if just the ssh service fails to come online, then all my other services are available with their proper ipfilter configuration. ed On Wed, Sep 24, 2008 at 04:22:48PM -0700, Tony Nguyen wrote: > Edward Pilatowicz wrote: >> just one quick question. >> >> given that ipfilter service specific configuration is stored with >> the services themselves, how will the user know if a specific service >> has an invalid ipfilter configuration? will that specific service >> fail go into the maintainance state? or will the ipfilter:default >> service go into the maintainance state? >> > > Ed, > > Think I missed your point in my earlier response. Putting a service into > maintenance seems heavy-handed but we need the observability. How about a > message in network/ipfilter log file? Do you have other suggestions? > > thanks, > tony From Truong.Q.Nguyen@sun.com Thu Sep 25 11:24:31 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8PIOUPn003219 for ; Thu, 25 Sep 2008 11:24:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8PIOQsN021440 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 26 Sep 2008 02:24:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7R00603KGRAH00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 11:24:27 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7R00KIOKGRU360@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 11:24:27 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8PIOR7b002792 for ; Thu, 25 Sep 2008 18:24:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7R00301JVMKF00@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 12:24:27 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7R00LE1KGKM640@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 25 Sep 2008 12:24:21 -0600 (MDT) Date: Thu, 25 Sep 2008 11:24:20 -0700 From: Tony Nguyen Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DB9C51.9010407@Sun.COM> Sender: Truong.Q.Nguyen@sun.com To: Darren Reed Cc: Nicolas Williams , psarc-ext@sun.com Message-id: <48DBD754.4060006@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 3885 Darren Reed wrote: > Nicolas Williams wrote: >> On Wed, Sep 24, 2008 at 12:14:33PM +0200, Darren Reed wrote: >> >>> Below are the properties, their possible values and correspoding >>> semantics: >>> >>> policy >>> >>> "none" policy mode - no access restriction. For a global policy, >>> this >>> mode allows all incoming traffic. For a service policy, this mode >>> allows all incoming traffic to its service. >>> >>> "deny" policy mode: more restrictive than "none". This mode allows >>> incoming traffic from all sources except those specified in the >>> "apply_to" property. >>> >>> "allow" policy mode: most restrictive mode. This mode blocks >>> incoming >>> traffic from all sources except those specified in the "apply_to" >>> property. >>> >> >> I find this confusing or likely to be confusing. >> >> How about: >> >> "any" -> allow all incoming >> "blacklist" -> allow all incoming where source not on blacklist >> "whitelist" -> allow incoming only from sources listed in whitelist >> "none" -> disallow all incoming >> >> instead of "none," "deny" and "allow"? >> >> Or, better yet, why not replace "policy"/"apply_to" with "blacklist"/ >> "whitelist"? >> > > This is bikeshed'ing...and you've forgotten grey...or it gray and not grey? > > IMHO, I prefer to see relevant policy words that are in common use > elsewhere > in the industry for control words. Nowhere else in [Open]Solaris do we > have > the concept of "white" and "black" (that I'm aware of), so it would seem > extremely inappropriate to introduce that new concept here. > > >>> apply_to >>> A multi-value property listing network entities to enforce the >>> chosen policy mode. Entities listed in apply_to property will be >>> denied >>> if policy is "deny" and allowed if policy is "allow". The syntax for >>> possible values are: >>> >>> host: host:IP "host:192.168.84.14" >>> subnet: network:IP/netmask "network:129.168.1.5/24" >>> interface: if:interface_name "if:e1000g0" >>> >> >> Why do we need 'host'/'subnet' when we have CIDR notation? And if >> there's no hostnames then we don't need 'if' for interface names either. >> > > I'd rather it be possible to be explicit in nature about the nature of > what an object > is, when it comes to security, so that you are in a better position to > try and catch > simple mistakes. > > For example, if someone put in "host:192.168.84.14/24", because they did a > copy paste from somewhere else, what does that mean? Isn't it better to say > "ok, they wanted a host, gave me a CIDR so I'll give them an error" than to > just accept it and try to guess that the user wanted a network instead > of a host, > possibly creating a security exposure? > We chose to use URIs here to avoid potential parsing issues and have an extensible configuration store. For example, to add support for ippool and IPv6, we probably can have ippool: ippool6: host6: network6: > >>> exceptions >>> >>> A multi-value property listing network entities to be excluded >>> from the >>> "apply_to" list. For example, when deny policy is applied to a >>> subnet, >>> exceptions can be made to some hosts in that subnet by specifying >>> them >>> in the "exceptions" property. This property has the same value >>> syntax >>> as "apply_to" property. >>> >> >> Why not just have '!' notation in apply_to instead of this exceptions >> property? >> > > Thinking of it in terms of usability, it would seem better (to me), to > have a list of > things you allow and a list of exceptions to that list, rather than a > combined list > that you need to sift through to work out what's what. > I actually think "!" notation is pretty neat but have similar usability concern. -tony From Truong.Q.Nguyen@sun.com Thu Sep 25 11:55:03 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8PIt3uH003900 for ; Thu, 25 Sep 2008 11:55:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8PIt3Xe000966; Thu, 25 Sep 2008 11:55:03 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7R0090XLVQGA00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Sep 2008 11:55:02 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7R00KY7LVPU190@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Sep 2008 11:55:01 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8PIt1S2014939; Thu, 25 Sep 2008 18:55:01 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7R00I01LIIWS00@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM); Thu, 25 Sep 2008 12:55:01 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7R00HEYLV8HB90@mail-amer.sun.com>; Thu, 25 Sep 2008 12:54:44 -0600 (MDT) Date: Thu, 25 Sep 2008 11:54:44 -0700 From: Tony Nguyen Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <20080925160745.GD957374@eng.sun.com> Sender: Truong.Q.Nguyen@sun.com To: Edward Pilatowicz Cc: Darren Reed , psarc-ext@sun.com, Andrew.Grabriel@sun.com Message-id: <48DBDE74.3040000@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924215019.GB957374@eng.sun.com> <48DACBC8.8030304@sun.com> <20080925160745.GD957374@eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 2830 Edward Pilatowicz wrote: > hey tony, > > imho, if an admin configures ipfilter settings incorrectly, haveing the > system come up and not actively notify the admin of the misconfiguration > seems bad and broken. ipfilters is a critical part of system security, > if it's configuration is invalid, the security of the system may be > compromised and it's important for the admin to know about this. > having the admin "poll" log files for errors is not a valid option. > > i personally think it would be much more appropriate to have a > smf service fail to start, and an error message should be > generated and put into the smf service log file clearly indicating > the reason for the failure. > > you could have the ipfilter service itself fail to start, but > i think it would be better to have the individual service that > has the invalid configuration parameters fail to start. the > reason i think the latter option is better is because it means > that the services aren't running exposed. for example, if i > incorrectly configure ssh with an allow ipfiler configuration, > then if the ipfilter smf services goes into maintainance then > all my services on the machine are accessible (read exposed to > the world) until i fix the ssh ipfilter configuration. if just > the ssh service fails to come online, then all my other services > are available with their proper ipfilter configuration. > Ed, I was prioritizing service availability but understand the concerns now. Essentially, the desired behaviors should be 1. If a service firewall policy is misconfigured, the service shouldn't be running exposed and appropriate information should be logged for that service. 2. If a system-wide policy is misconfigured, network/ipfilter should be placed in maintenance which is the current behavior. Additionally, we also want services to in maintenance, not running exposed. This additional behavior can be done by specifying network/ipfilter as an optional dependency for network services. What do you think? Andrew, I'll look into addressing that6623013 bug if possible. Thanks, tony > > On Wed, Sep 24, 2008 at 04:22:48PM -0700, Tony Nguyen wrote: >> Edward Pilatowicz wrote: >>> just one quick question. >>> >>> given that ipfilter service specific configuration is stored with >>> the services themselves, how will the user know if a specific service >>> has an invalid ipfilter configuration? will that specific service >>> fail go into the maintainance state? or will the ipfilter:default >>> service go into the maintainance state? >>> >> Ed, >> >> Think I missed your point in my earlier response. Putting a service into >> maintenance seems heavy-handed but we need the observability. How about a >> message in network/ipfilter log file? Do you have other suggestions? >> >> thanks, >> tony From edward.pilatowicz@sun.com Thu Sep 25 12:13:47 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8PJDlCW004360 for ; Thu, 25 Sep 2008 12:13:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8PJDhM4033266; Thu, 25 Sep 2008 13:13:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7R00B0FMQWD700@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Sep 2008 12:13:44 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7R00KKUMQTU3A0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Sep 2008 12:13:41 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8PJDeoF936164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 12:13:40 -0700 (PDT) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id m8PJDeTo936163; Thu, 25 Sep 2008 12:13:40 -0700 (PDT) Date: Thu, 25 Sep 2008 12:13:40 -0700 From: Edward Pilatowicz Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DBDE74.3040000@sun.com> To: Tony Nguyen Cc: Darren Reed , psarc-ext@sun.com, Andrew.Grabriel@sun.com Message-id: <20080925191340.GL957374@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924215019.GB957374@eng.sun.com> <48DACBC8.8030304@sun.com> <20080925160745.GD957374@eng.sun.com> <48DBDE74.3040000@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 2226 On Thu, Sep 25, 2008 at 11:54:44AM -0700, Tony Nguyen wrote: > Edward Pilatowicz wrote: >> hey tony, >> >> imho, if an admin configures ipfilter settings incorrectly, haveing the >> system come up and not actively notify the admin of the misconfiguration >> seems bad and broken. ipfilters is a critical part of system security, >> if it's configuration is invalid, the security of the system may be >> compromised and it's important for the admin to know about this. >> having the admin "poll" log files for errors is not a valid option. >> >> i personally think it would be much more appropriate to have a >> smf service fail to start, and an error message should be >> generated and put into the smf service log file clearly indicating >> the reason for the failure. >> >> you could have the ipfilter service itself fail to start, but >> i think it would be better to have the individual service that >> has the invalid configuration parameters fail to start. the >> reason i think the latter option is better is because it means >> that the services aren't running exposed. for example, if i >> incorrectly configure ssh with an allow ipfiler configuration, >> then if the ipfilter smf services goes into maintainance then >> all my services on the machine are accessible (read exposed to >> the world) until i fix the ssh ipfilter configuration. if just >> the ssh service fails to come online, then all my other services >> are available with their proper ipfilter configuration. >> > > Ed, > > I was prioritizing service availability but understand the concerns now. > Essentially, the desired behaviors should be > > 1. If a service firewall policy is misconfigured, the service shouldn't be > running exposed and appropriate information should be logged for that > service. > > 2. If a system-wide policy is misconfigured, network/ipfilter should be > placed in maintenance which is the current behavior. Additionally, we also > want services to in maintenance, not running exposed. This additional > behavior can be done by specifying network/ipfilter as an optional > dependency for network services. > > What do you think? > > Andrew, I'll look into addressing that6623013 bug if possible. > sounds great. ed From Darren.Reed@sun.com Fri Sep 26 05:54:28 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8QCsSCu003415 for ; Fri, 26 Sep 2008 05:54:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8QCsOX3040744 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 26 Sep 2008 06:54:28 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7S00J4VZURMZ00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 05:54:27 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7S006ROZUQR7D0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 05:54:27 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8QCsQLi017590 for ; Fri, 26 Sep 2008 12:54:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7S00F01ZCRKN00@fe-emea-10.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 13:54:26 +0100 (BST) Received: from [129.157.18.218] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7S00157ZU8W9E0@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 13:54:08 +0100 (BST) Date: Fri, 26 Sep 2008 14:54:02 +0200 From: Darren Reed Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DA1309.9060408@Sun.COM> Sender: Darren.Reed@sun.com To: psarc-ext@sun.com Cc: Tony Nguyen Message-id: <48DCDB6A.2010707@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 177 Due to the need for an updated spec that (at least) covers IPv6, I've marked this case as "waiting need-spec" and will update it accordingly when a new one is present. Darren From Nicolas.Williams@sun.com Fri Sep 26 09:36:14 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8QGaDcO007661 for ; Fri, 26 Sep 2008 09:36:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8QGa30n018208; Fri, 26 Sep 2008 17:36:05 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7T00B0XA455Y00@brm-avmta-1.central.sun.com>; Fri, 26 Sep 2008 10:36:05 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.107]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7T000AUA421MA0@brm-avmta-1.central.sun.com>; Fri, 26 Sep 2008 10:36:02 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m8QGZpaZ024524; Fri, 26 Sep 2008 11:35:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8QGZpEE024523; Fri, 26 Sep 2008 11:35:51 -0500 (CDT) Date: Fri, 26 Sep 2008 11:35:51 -0500 From: Nicolas Williams Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DB9C51.9010407@Sun.COM> To: Darren Reed Cc: psarc-ext@sun.com, Tony Nguyen Message-id: <20080926163550.GP9765@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2600 On Thu, Sep 25, 2008 at 04:12:33PM +0200, Darren Reed wrote: > Nicolas Williams wrote: > >Or, better yet, why not replace "policy"/"apply_to" with "blacklist"/ > >"whitelist"? > > This is bikeshed'ing...and you've forgotten grey...or it gray and not grey? Yes, it is bikeshed painting. I knew that before I posted, but then, when it comes to security UIs, they'd better not be confusing, don't you think? I do, so I thought the comment worth making, even if it contravened ARC etiquette. > IMHO, I prefer to see relevant policy words that are in common use elsewhere > in the industry for control words. Nowhere else in [Open]Solaris do we have > the concept of "white" and "black" (that I'm aware of), so it would seem > extremely inappropriate to introduce that new concept here. Perhaps, but those terms ("whitelist" and "blacklist") are widely in use in general. And as for 'allow' being "the most restrictive mode" -- that's confusing! Where else in Solaris do we have an example of such a design? > >Why do we need 'host'/'subnet' when we have CIDR notation? And if > >there's no hostnames then we don't need 'if' for interface names either. > > I'd rather it be possible to be explicit in nature about the nature of > what an object is, when it comes to security, so that you are in a > better position to try and catch simple mistakes. > > For example, if someone put in "host:192.168.84.14/24", because they > did a copy paste from somewhere else, what does that mean? Isn't it > better to say "ok, they wanted a host, gave me a CIDR so I'll give > them an error" than to just accept it and try to guess that the user > wanted a network instead of a host, possibly creating a security > exposure? Without the 'host:' part there would be no question of confusion. OTOH, dropping the type is only workable IFF you think you can keep the list elements' syntaxes unambiguously distinct. That's true for IPv4 and IPv6 addresses, and for interface names, but if you want to allow names of other things (e.g., hostnames, network names, ...) then I agree, you need a type specifier. So if you answer is "we have the type specifier for extensibility w/o ambiguity" then I think that's enough. > >Why not just have '!' notation in apply_to instead of this exceptions > >property? > > Thinking of it in terms of usability, it would seem better (to me), to > have a list of things you allow and a list of exceptions to that list, > rather than a combined list that you need to sift through to work out > what's what. Not convincing, but then, I don't care much about this. Nico -- From carlsonj@phorcys.east.sun.com Fri Sep 26 09:45:56 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8QGjt5m008625 for ; Fri, 26 Sep 2008 09:45:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8QGjjcB022860; Fri, 26 Sep 2008 17:45:51 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7T00507AKD7800@nwk-avmta-2.sfbay.sun.com>; Fri, 26 Sep 2008 09:45:49 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7T003RDAKDT710@nwk-avmta-2.sfbay.sun.com>; Fri, 26 Sep 2008 09:45:49 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8QGjnFT012367; Fri, 26 Sep 2008 12:45:49 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8QGjnZm012364; Fri, 26 Sep 2008 12:45:49 -0400 (EDT) Date: Fri, 26 Sep 2008 12:45:48 -0400 From: James Carlson Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <20080926163550.GP9765@Sun.COM> To: Nicolas Williams Cc: Darren Reed , Tony Nguyen , psarc-ext@sun.com Message-id: <18653.4540.919490.125918@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> Status: RO Content-Length: 609 Nicolas Williams writes: > Perhaps, but those terms ("whitelist" and "blacklist") are widely in use > in general. And as for 'allow' being "the most restrictive mode" -- > that's confusing! > > Where else in Solaris do we have an example of such a design? TCP Wrappers (/etc/hosts.allow and /etc/hosts.deny) and cron (/usr/lib/cron/at.allow and /usr/lib/cron/at.deny) come to mind. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Fri Sep 26 09:52:54 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8QGqrZ3008870 for ; Fri, 26 Sep 2008 09:52:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8QGqRbt025763; Fri, 26 Sep 2008 17:52:48 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7T00503AVZFS00@nwk-avmta-2.sfbay.sun.com>; Fri, 26 Sep 2008 09:52:48 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.107]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7T00364AVZTD20@nwk-avmta-2.sfbay.sun.com>; Fri, 26 Sep 2008 09:52:47 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m8QGqakm024589; Fri, 26 Sep 2008 11:52:36 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8QGqaSj024588; Fri, 26 Sep 2008 11:52:36 -0500 (CDT) Date: Fri, 26 Sep 2008 11:52:36 -0500 From: Nicolas Williams Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <18653.4540.919490.125918@gargle.gargle.HOWL> To: James Carlson Cc: Darren Reed , Tony Nguyen , psarc-ext@sun.com Message-id: <20080926165235.GS9765@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <18653.4540.919490.125918@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 802 On Fri, Sep 26, 2008 at 12:45:48PM -0400, James Carlson wrote: > Nicolas Williams writes: > > Perhaps, but those terms ("whitelist" and "blacklist") are widely in use > > in general. And as for 'allow' being "the most restrictive mode" -- > > that's confusing! > > > > Where else in Solaris do we have an example of such a design? > > TCP Wrappers (/etc/hosts.allow and /etc/hosts.deny) and cron > (/usr/lib/cron/at.allow and /usr/lib/cron/at.deny) come to mind. Yes, but those are not confusing. Why? Because in each of those cases the name of the list indicates quite clearly what it does. Here we have a list named something generic and then a separate selector that tells you whether that list is a whitelist or blacklist. That's different enough from TCP wrappers and cron, IMO. Nico -- From Truong.Q.Nguyen@sun.com Fri Sep 26 11:21:19 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8QILJOx012339 for ; Fri, 26 Sep 2008 11:21:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8QILIb9050691 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 26 Sep 2008 12:21:19 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7T0020DEZH8900@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 11:21:17 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7T00C0REZGLGE0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 11:21:16 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8QILGJE009374 for ; Fri, 26 Sep 2008 18:21:16 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7T00H01DK8VX00@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 12:21:16 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7T006RBEZ2X880@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 12:21:03 -0600 (MDT) Date: Fri, 26 Sep 2008 11:21:02 -0700 From: Tony Nguyen Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <20080926163550.GP9765@Sun.COM> Sender: Truong.Q.Nguyen@sun.com To: Nicolas Williams Cc: Darren Reed , psarc-ext@sun.com Message-id: <48DD280E.7060304@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 1355 > >>> Why do we need 'host'/'subnet' when we have CIDR notation? And if >>> there's no hostnames then we don't need 'if' for interface names either. >> I'd rather it be possible to be explicit in nature about the nature of >> what an object is, when it comes to security, so that you are in a >> better position to try and catch simple mistakes. >> >> For example, if someone put in "host:192.168.84.14/24", because they >> did a copy paste from somewhere else, what does that mean? Isn't it >> better to say "ok, they wanted a host, gave me a CIDR so I'll give >> them an error" than to just accept it and try to guess that the user >> wanted a network instead of a host, possibly creating a security >> exposure? > > Without the 'host:' part there would be no question of confusion. > > OTOH, dropping the type is only workable IFF you think you can keep the > list elements' syntaxes unambiguously distinct. That's true for IPv4 > and IPv6 addresses, and for interface names, but if you want to allow > names of other things (e.g., hostnames, network names, ...) then I > agree, you need a type specifier. > > So if you answer is "we have the type specifier for extensibility w/o > ambiguity" then I think that's enough. > Yes. Technically, the type specifier is necessary. Extensibility was the main reason we chose to use URIs. thanks tony From Darren.Reed@sun.com Fri Sep 26 11:57:15 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8QIvFMs013789 for ; Fri, 26 Sep 2008 11:57:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8QIvEXl064530 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 26 Sep 2008 12:57:14 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7T0050DGNDUO00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 11:57:13 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7T0048YGNCF020@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 11:57:13 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8QIvCl7018326 for ; Fri, 26 Sep 2008 18:57:12 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7T00I01GIAKZ00@fe-emea-09.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 19:57:12 +0100 (BST) Received: from [129.157.18.218] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7T00IECGNB2I10@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 26 Sep 2008 19:57:11 +0100 (BST) Date: Fri, 26 Sep 2008 20:57:04 +0200 From: Darren Reed Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <20080926163550.GP9765@Sun.COM> Sender: Darren.Reed@sun.com To: Nicolas Williams Cc: psarc-ext@sun.com, Tony Nguyen Message-id: <48DD3080.8070005@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 554 Nicolas Williams wrote: > On Thu, Sep 25, 2008 at 04:12:33PM +0200, Darren Reed wrote: > >> Nicolas Williams wrote: >> >>> Or, better yet, why not replace "policy"/"apply_to" with "blacklist"/ >>> "whitelist"? >>> >> This is bikeshed'ing...and you've forgotten grey...or it gray and not grey? >> > > Yes, it is bikeshed painting. I knew that before I posted, but then, > when it comes to security UIs, they'd better not be confusing, don't you > think? > I think we should concentrate on matters that are architectural. Darren From ceri@submonkey.net Fri Sep 26 12:36:00 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8QJZwsP014837 for ; Fri, 26 Sep 2008 12:36:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8QJZtq7003375; Fri, 26 Sep 2008 20:35:56 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7T00901IFVV600@nwk-avmta-1.sfbay.Sun.COM>; Fri, 26 Sep 2008 12:35:55 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7T00440IFVEYA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 26 Sep 2008 12:35:55 -0700 (PDT) Received: from relay18i.sun.com (ip128.net129179-4.block1.us.syntegra.com [129.179.4.128]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8QJWNAr026360; Fri, 26 Sep 2008 19:35:54 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay18i.sun.com with ESMTP id BT-MMP-220081; Fri, 26 Sep 2008 19:35:54 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-25675651; Fri, 26 Sep 2008 19:35:54 +0000 (Z) Received: from scuttle.submonkey.net ([208.111.43.184] [208.111.43.184]) by relay1i.sun.com with ESMTP id BT-MMP-1671983; Fri, 26 Sep 2008 19:35:54 +0000 (Z) Received: from cpc1-cdif1-0-0-cust63.cdif.cable.ntl.com ([81.104.164.64] helo=shrike.submonkey.net) by scuttle.submonkey.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KjJ5c-0004ms-1V; Fri, 26 Sep 2008 19:34:56 +0000 Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KjJ6U-0002Yw-3b; Fri, 26 Sep 2008 20:35:50 +0100 Date: Fri, 26 Sep 2008 20:35:50 +0100 From: Ceri Davies Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <20080926163550.GP9765@Sun.COM> Sender: Ceri Davies To: Nicolas Williams Cc: Darren Reed , Tony Nguyen , psarc-ext@sun.com Message-id: <20080926193549.GA41867@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=CE+1k2dSO48ffgeK Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=0.0/5.0, scanned in 0.067sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) Status: RO Content-Length: 1922 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 26, 2008 at 11:35:51AM -0500, Nicolas Williams wrote: > On Thu, Sep 25, 2008 at 04:12:33PM +0200, Darren Reed wrote: > > Nicolas Williams wrote: > > >Or, better yet, why not replace "policy"/"apply_to" with "blacklist"/ > > >"whitelist"? > >=20 > > This is bikeshed'ing...and you've forgotten grey...or it gray and not g= rey? >=20 > Yes, it is bikeshed painting. I knew that before I posted, but then, > when it comes to security UIs, they'd better not be confusing, don't you > think? >=20 > I do, so I thought the comment worth making, even if it contravened ARC > etiquette. >=20 > > IMHO, I prefer to see relevant policy words that are in common use else= where > > in the industry for control words. Nowhere else in [Open]Solaris do we= have > > the concept of "white" and "black" (that I'm aware of), so it would seem > > extremely inappropriate to introduce that new concept here. >=20 > Perhaps, but those terms ("whitelist" and "blacklist") are widely in use > in general. And as for 'allow' being "the most restrictive mode" -- > that's confusing! >=20 > Where else in Solaris do we have an example of such a design? You have to bear in mind the property names as well. If the policy is "allow" and is "applied_to" host x, then you'd expect host x to be allowed and nobody else. I found this not confusing; the converse would be. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFI3TmVocfcwTS3JF8RAgkdAJ9zYaxOULiGRvoLC3ymHlwu84x46QCfQTAj YDJvaSZuS40upY66vRLxrPM= =4ONO -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From Kais.Belgaied@sun.com Tue Sep 30 15:33:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8UMXFWf003316 for ; Tue, 30 Sep 2008 15:33:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8UMX30Q002431; Wed, 1 Oct 2008 06:33:12 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8100K195BB7E00@nwk-avmta-2.sfbay.sun.com>; Tue, 30 Sep 2008 15:33:11 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8100G4L5BA7R90@nwk-avmta-2.sfbay.sun.com>; Tue, 30 Sep 2008 15:33:11 -0700 (PDT) Received: from [129.146.11.145] (sr1-jurassic-02.SFBay.Sun.COM [129.146.11.145]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8UMWqbn818221; Tue, 30 Sep 2008 15:32:58 -0700 (PDT) Date: Tue, 30 Sep 2008 15:32:52 -0700 From: Kais Belgaied Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48DD280E.7060304@sun.com> To: psarc-ext@sun.com Cc: Tony Nguyen , Darren Reed Reply-to: Kais.Belgaied@sun.com Message-id: <48E2A914.7090003@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 228 The project team provided an updated spec. On behalf of the submitter (currently traveling) I' re-opening the case. The project team is under some time pressure, so the timer is set to the end of this week (Oct. 3rd). Kais From Andrew.Gabriel@sun.com Thu Oct 2 11:38:16 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92IcFLY020811 for ; Thu, 2 Oct 2008 11:38:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m92IcDXV005813 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 2 Oct 2008 19:38:14 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400405JRPI400@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 02 Oct 2008 11:38:13 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K840017OJRO2760@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 02 Oct 2008 11:38:13 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m92IcCIJ014230 for ; Thu, 02 Oct 2008 18:38:12 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400M01JNM3E00@fe-emea-10.sun.com> (original mail from Andrew.Gabriel@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 02 Oct 2008 19:38:12 +0100 (BST) Received: from [81.187.162.109] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8400C9AJRK23D0@fe-emea-10.sun.com>; Thu, 02 Oct 2008 19:38:09 +0100 (BST) Date: Thu, 02 Oct 2008 19:38:27 +0100 From: Andrew Gabriel Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48E2A914.7090003@Sun.COM> Sender: Andrew.Gabriel@sun.com To: Kais.Belgaied@sun.com Cc: PSARC-ext@sun.com, Tony Nguyen , Darren Reed Message-id: <48E51523.7080609@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 1571 I've looked through the new spec. I have some questions about how the current method of configuring IPfilter will continue to work in the new framework. (I have programs which build ipf.conf and reapply it dynamically as needed, and I don't have any interest in automatically allowing/denying access based on SMF service states. I guess that makes me an "advanced user" in your terminology.) So, if I understand correctly, to enable current mode of operation, I would issue the commands: svccfg -s svc:/network/ipfilter: setprop firewall_config_default/policy = custom svcadm enable svc:/network/ipfilter This needs clearly stating as an example on a manpage (ipf(1M) and/or ipf(4)). What happens on upgrade of a system with an existing ipf.conf file and IPfilter enabled? Will you automatically do this? If not, how do you handle upgrade? In the ipf(1M) manpage, you have removed the ipf and ipnat command examples. This is incorrect -- these are still used and required for current method of operation. You perhaps just need to add a comment that these wouldn't be used if using the SMF framework to automatically build firewall rules. You have also effectively removed the instructions for changing filter rules without either rebooting or disabling IPfilter. It is an important feature of IPfilter that it allows rules to be changed dynamically without disabling it or rebooting the system, and this needs to remain on the manpage. ipf(1M) is a committed interface and a key part of the access to important features of IPfilter. -- Andrew From ceri@submonkey.net Thu Oct 2 12:10:34 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92JAYxj021757 for ; Thu, 2 Oct 2008 12:10:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m92JAS04053083; Thu, 2 Oct 2008 13:10:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400L0BL9GKZ00@nwk-avmta-2.sfbay.sun.com>; Thu, 02 Oct 2008 12:10:28 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8400JU2L9F3F80@nwk-avmta-2.sfbay.sun.com>; Thu, 02 Oct 2008 12:10:27 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m92J91x9006597; Thu, 02 Oct 2008 19:10:27 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-1479207; Thu, 02 Oct 2008 19:10:27 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-75251571; Thu, 02 Oct 2008 19:10:27 +0000 (Z) Received: from scuttle.submonkey.net ([208.111.43.184] [208.111.43.184]) by relay4i.sun.com with ESMTP id BT-MMP-113794; Thu, 02 Oct 2008 19:10:26 +0000 (Z) Received: from cpc1-cdif1-0-0-cust63.cdif.cable.ntl.com ([81.104.164.64] helo=shrike.submonkey.net) by scuttle.submonkey.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KlTYC-0001CZ-QZ; Thu, 02 Oct 2008 19:09:25 +0000 Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlTZ9-000DeX-8B; Thu, 02 Oct 2008 20:10:23 +0100 Date: Thu, 02 Oct 2008 20:10:23 +0100 From: Ceri Davies Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48E2A914.7090003@Sun.COM> Sender: Ceri Davies To: Kais Belgaied Cc: PSARC-ext@sun.com, Tony Nguyen , Darren Reed Message-id: <20081002191023.GE28158@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=d8Lz2Tf5e5STOWUP Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=0.0/5.0, scanned in 0.093sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) Status: RO Content-Length: 942 --d8Lz2Tf5e5STOWUP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2008 at 03:32:52PM -0700, Kais Belgaied wrote: > The project team provided an updated spec. > On behalf of the submitter (currently traveling) I' re-opening the case. > The project team is under some time pressure, so the timer is set to > the end of this week (Oct. 3rd). I can't see the new spec on the website; would you be able to post it to the list please? Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --d8Lz2Tf5e5STOWUP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFI5RyfocfcwTS3JF8RAjvHAJsHsD/6NzvJTHK6GEae3XBmBAJv2wCgxE6a pIRzOwlOUoCbMsh1fS7IWlk= =Xxx/ -----END PGP SIGNATURE----- --d8Lz2Tf5e5STOWUP-- From Truong.Q.Nguyen@Sun.COM Thu Oct 2 12:29:13 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92JTCM0022719 for ; Thu, 2 Oct 2008 12:29:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m92JT9g4026121 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 20:29:11 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400903M4MSM00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 12:29:10 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K84001I5M4L28B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 12:29:10 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m92JT9Qs017330 for ; Thu, 02 Oct 2008 19:29:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400701L04AI00@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 13:29:09 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K84009E0M4GJXA0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 13:29:04 -0600 (MDT) Date: Thu, 02 Oct 2008 12:29:04 -0700 From: Tony Nguyen Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <20081002191023.GE28158@submonkey.net> Sender: Truong.Q.Nguyen@Sun.COM To: Ceri Davies Cc: PSARC-ext@Sun.COM Message-id: <48E52100.80408@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_h/1Go2Qvel0eEeIOX8aTqw)" X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> <20081002191023.GE28158@submonkey.net> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 41698 This is a multi-part message in MIME format. --Boundary_(ID_h/1Go2Qvel0eEeIOX8aTqw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Ceri Davies wrote: > On Tue, Sep 30, 2008 at 03:32:52PM -0700, Kais Belgaied wrote: >> The project team provided an updated spec. >> On behalf of the submitter (currently traveling) I' re-opening the case. >> The project team is under some time pressure, so the timer is set to >> the end of this week (Oct. 3rd). > > I can't see the new spec on the website; would you be able to post it to > the list please? > > Ceri Ceri, Here you go. -tony --Boundary_(ID_h/1Go2Qvel0eEeIOX8aTqw) Content-type: text/plain; name=arc_proposal Content-transfer-encoding: 7BIT Content-disposition: inline; filename=arc_proposal Solaris host-based firewall Truong Q. Nguyen (Tony Nguyen) 09/08/2008 1. Introduction Currently, Solaris has IPfilter which allows user to set up system and service firewall policies. The project delivers a framework to simplify system and services IPfilter configuration. IPfilter uses a set of ipf rules from which it determines whether an IP packet should be allowed in or out of the system. Although ipf rule syntax is fairly simple and straightforward, it still demands good understanding of networking and security concepts, a non-trivial learning curve for 'casual' Solaris users. Moreover, the task of creating and testing ipf rules are mostly manual and can become a management burden in systems where large number of rules are used. Instead of manually construct and specify ipf rules, the proposed framework allows users to express system and services' firewall policies which it uses to generates a set of IPfilter rules to enforce the desired behavior. Essentially, users specify system and service firewall policies that allow or disallow network traffic from certain hosts, subnets, and interface(s). The policies can be translated into a set of active ipf rules to enforce the specified firewall policies. Existing firewall tools, fwbuilder being a good example, may provide highly customized configuration but have other drawbacks. Our proposed solution which targets casual OpenSolaris users, has clear advantages. - Very simple user model. While FirewallBuilder is able to produce highly customized configurations, it requires good understanding of firewall concept and knowledge of the system networking configuration. Setting up FirewallBuilder requires specifying a path, a file, local address, create objects for each service, *configure* firewall for the objects, compile, and run. Our firewall only requires setting policy by changing properties and enable service(s). - Well-integrated with Solaris - Supports IPfilter configuration generated by other tools. Our framework should satisfy the needs of most casual users. However, advanced users can always use tools such as FirewallBuilder to generate IPfilter rules that can be consumed by the proposed framework. 2. Scope Our goal is to provide casual OpenSolaris users and developers a simple way to harden their systems. System administrators can certainly use the firewall framework but may find some deficiencies such as inability to synchronize policies across a group of Solaris systems. The propose project is NOT a firewall configuration tool but an IPfilter-based firewall framework that allows high-level firewall policies and translates those policies to IPfilter rules. Generic firewall construction tools, if possible, should use the proposed framework to configure IPfilter for Solaris machines. The proposed framework isn't a full IPfilter configuration tool, thus it won't generate every possible IPfilter configuration. However, users can specified a custom ipf rule set to be used if the framework can't provide the desired IPfilter configuration. 3. Design Model: The proposed firewall framework provides a simple mechanism to restrict incoming network traffic to a Solaris machine. Network traffic is normally from remote servers and clients to local clients and servers(local network services), respectively. Other types of network traffic include broadcasts and ICMP messages. The goal of any firewall is to block unwanted incoming network traffic and/or restrict access to certain source(s) while allow local client programs to work seamlessly. A three layer approach with different precedence levels helps us achieve the desired behaviors. Global Default - default system-wide policy. This policy is automatically inherited by all services unless services modify their firewall policy. Network Services - higher precedence than Global Default. A service's policy allows/disallows traffic to its specific ports, regardless of Global Default policy. Global Override - another system-wide policy that takes precedence over the needs of specific services in Network Services layer. Global Override | | Network Services | | Global Default A firewall policy includes a firewall mode and an optional set of network sources. Network sources are IP addresses, subnets, and local network interfaces, from which a system can receive incoming traffic. The basic set of firewall modes are: None - no firewall, allow all incoming traffic Deny - allow all incoming traffic but deny from specified source(s) Allow - deny all incoming traffic but allow from specified source(s) Layers in Detail: The first system-wide layer, Global Default, defines a firewall policy that applies to *any* incoming traffic, e.g. allowing or blocking all traffic from an IP address. This makes it simple to have a policy that blocks all incoming traffic or all incoming traffic from unwanted source(s). The Network Services layer contains firewall policies for local programs that provide service to remote clients, e.g. telnetd, sshd, and httpd. Each of these programs, a network service, has its own firewall policy that controls access to its service. Initially, a service's policy is set to inherit Global Default policy, a "Use Global Default" mode. This makes it simple to set a single policy, at the Global Default layer, that can be inherited by all services. When a service's policy is different from Global Default policy, the service's policy has higher precedence. If Global Default policy is set to block all traffic from a subnet, the SSH service could be configured to allow access from certain hosts in that subnet. The set of all policies for all network services comprises the Network Service layer. The second sytem-wide layer, Global Override, has a firewall policy that also applies to any incoming network traffic. This policy has highest precedence and overrides policies in other layers, specifically overriding the needs of network services. The example is when it's desirable block known malicious source(s) regardless of services' policies. User Interaction: This framework leverages IPfilter functionality and is only active when svc:/network/ipfilter is enabled. Similarly, a network service's firewall policy is only active when that service is enabled. A system with an active firewall has IPfilter rules for each running/enabled network service and for system-wide policy(s) with firewall mode other than "None". User's enabling and disabling action for a service corresponds to firewall policy activation and deactivation for that service. A user changes firewall settings by modifying a service and/or system-wide firewall policy. The firewall framework composes of policy configuration and a mechanism to generate ipfilter rules from the policy and applying those rules to get the desired IPfilter configuration. A quick breakdown of the design: - system-wide policy(s) are stored in network/ipfilter - network services' policies are stored in each SMF service - activate firewall by enabling network/ipfilter - activate/deactivate per-service firewall policy by enabling/disabling that network service - changing a system-wide or per-service firewall policy results in an update to the system's firewall rules Availability and observability: Misconfigured firewall policies will result in service unavailability, service in maintenance state. The rationale here is that once the firewall is activated, services should not be allowed to run exposed. Essentially, the desired behaviors are 1. If a service firewall policy is misconfigured, the service is placed in maintenance and appropriate information should be logged in service's log to explain the failure. 2. If a system-wide policy is misconfigured, network/ipfilter is placed in in maintenance which is the current behavior. Additionally, network services also get placed in maintenance mode such that they are not running exposed. 4. Configuration See the new svc.ipfd.1m 5. IPv6 support The proposed architecture fully supports IPv6 which comprises of allowing policy configuration to store IPv6 addresses and pools and separately generating and loading IPv6 rules. Providing IPv6 addresses and pools suport in policy configuration can be done by additional type specifiers such as: IPv6 host: host6:IP "host6:2001:db8:3c4d::1a2b" IPv6 subnet: network6:IP/netmask "network6:2001:db8:3c4d::/48" IPv6 ippool: pool6:pool number "pool6:66" A service whose policy specifies IPv6 addresses would generate an addtional IPv6 rules file which will be loaded using "ipf -6". However, IPv6 support is not provided at the initial integration. The rationale for this lack of support is twofold. This proposed framework is the enabling technology for the Services Firewall Panel, to be delivered in Visual Panel Project for OpenSolaris 2008.11. The Visual Panels project aims to simply Solaris management for casual Solaris users and a host-based firewall functionality, though lacking IPv6 support, is still a positive step toward that goal. The second reason for not having IPv6 at initial integration is the testing effort required for IPv6 functionality. While the work to support IPv6 is not too challenging, the additional testing places a heavy burden on our schedule thus the proposed incremental integrations. We are committed to support IPv6 and plan to have a follow-on putback in a couple of months to add IPv6 support. 6. Exported Interfaces Service static configuration property group and properties: firewall_context/name Committed firewall_context/isrpc Committed firewall_context/ipf_method Committed Service firewall configuration property groups and properties: firewall_config/policy Committed firewall_config/apply_to Committed firewall_config/exceptions Committed Global Default policy property groups and properties: firewall_config_default/policy Committed firewall_config_default/apply_to Committed firewall_config_default/exceptions Committed firewall_config_default/custom_policy_file Committed firewall_config_default/open_ports Committed Global Override policy property groups and properties: firewall_config_override/policy Committed firewall_config_override/apply_to Committed firewall_config_override/exceptions Committed FMRIs for system-wide policies: svc:/network/ipfilter:default Committed 7. Imported Interfaces libnsl(3LIB) libsocket(3LIB) 8. Documentation changes The SMF FAQ on opensolaris.org will be updated to contain a how-to for both users and service developers. svc.ipfd.1m(new) System Administration Commands svc.ipfd(1M) NAME svc.ipfd - IPfilter firewall monitoring daemon SYNOPSIS /lib/svc/bin/svc.ipfd svc:/network/ipfilter:default DESCRIPTION svc.ipfd monitors actions to services with firewall configuration and initiates update services' IPfilter configuration. The daemon allows us to react to changes in system's firewall configuration in an incremental fashion, at per service level. A service's firewall policy is activated when it's enabled, deactivated when it's disabled, and updated when its configuration property group is modified. svc.ipfd monitors SMF repository for these actions and invokes IPfilter rule generation process to carry out the service's firewall policy. Environment Variables and Context This daemon is started by the network/ipfilter service either through the start or refresh method. Thus, the daemon inherits the environment variables and credentials from the method and runs as root with all zone privileges. FIREWALL STATIC CONFIGURATION Static definition describing service's network resource configuration that is used to generate service specific ipf rules. A new per service "firewall_context" property group contains a service's static definition, similar to "inetd" property group in inetd managed services. - firewall_context/name, IANA name or RPC name for non-inetd service, equivalent to inetd/name property - firewall_context/isrpc, a boolean property where a "true" value indicates an RPC service, equivalent to inetd/isrpc property. For RPC services, the value of firewall_context/name is not an IANA name but is either an RPC program number or name, see rpc(4). Additionally, some services may require a mechanism to generate and supply their own ipf rules. An optional property ipf_method, provides a mechanism to allow custom rule generation. - firewall_context/ipf_method, a command, normally a script that generates ipf rules for a service. The framework does not generate rules for services with this property definition but expect these services to provide their own rules. A service's ipf_method specifies a command that takes an additional argument, its own fmri and generates the service's firewall rules and output the rules to stdout. To generate rules for a service with ipf_method property, the framework execs the command specified in ipf_method, passing the service fmri as the additional argument and stores the rules for that service by redirecting the command output, the rules, to the service's rule file. Because an ipf_method is exec'ed from the context of either network/ipfilter start or refresh method process, it inherits the execution context and runs as root. Administrative Privilege The service static configuration, is delivered by service developer and and not intended to be modified by users. These properties are only modified upon installation of an updated service definition. FIREWALL POLICY CONFIGURATION A per service property group, firewall_config, stores the services' firewall policy configuration. Since network/ipfilter:default is responsible for two firewall policies, Global Default and Global Override system-wide policies as explained in ipfilter(5), it has two property groups, firewall_config_default and firewall_config_override, to store the respective sytem-wide policies. Below are the properties, their possible values and correspoding semantics: policy "none" policy mode - no access restriction. For a global policy, this mode allows all incoming traffic. For a service policy, this mode allows all incoming traffic to its service. "deny" policy mode: more restrictive than "none". This mode allows incoming traffic from all sources except those specified in the "apply_to" property. "allow" policy mode: most restrictive mode. This mode blocks incoming traffic from all sources except those specified in the "apply_to" property. apply_to A multi-value property listing network entities to enforce the chosen policy mode. Entities listed in apply_to property will be denied if policy is "deny" and allowed if policy is "allow". The syntax for possible values are: host: host:IP "host:192.168.84.14" subnet: network:IP/netmask "network:129.168.1.5/24" ippool: pool:pool number "pool:77" interface: if:interface_name "if:e1000g0" exceptions A multi-value property listing network entities to be excluded from the "apply_to" list. For example, when deny policy is applied to a subnet, exceptions can be made to some hosts in that subnet by specifying them in the "exceptions" property. This property has the same value syntax as "apply_to" property. For individual network services only: firewall_config/policy A service's policy can also be set to "use_global". Services with "use_global" policy mode inherits the Global Default firewall policy. For the Global Default only: firewall_config_default/policy - can also be set to "custom" Global Default policy, firewall_config property group in svc:/network/ipfilter:default, can also be set to "custom". Users can set policy to "custom" to use prepopulated IPfilter configuration, e.g. existing IPfilter configuration or custom configurations that can't be provided by the framework. This Global Default only policy mode allows users to supply a text file containing the complete set of ipf rules. When "custom" mode is selected, the specified set of ipf rules is *complete* and the framework will not generate ipf rules from configured firewall policies. firewall_config_default/custom_policy_file A file path to be used when Global Default policy is set to "custom". The file contains a set of ipf rules which provide the desired IPfiler configuration. firewall_config_default/open_ports Non-service program requiring allowance of its incoming traffic can request the firewall to allow traffic to its communication ports. This multi-value property property contains protocol and port(s) tuple in the form "{tcp | udp}:{PORT | PORT-PORT}" Initially, the system-wide policies are set to "none" and network services' policies are set to "use_global". Enabling network/ipfilter activates the firewall with an empty set of ipfilter rules, since system-wide policy is "none" and all services inherit that policy. To configure a more restrictive policy, use svccfg(1M) to modify network services and system-wide policies. Administrative Privilege User configures firewall policy by modifying the service's firewall_config property group. A new authorization "solaris.smf.value.firewall.config" is created to allow delgation of firewall administration privilege to users. The Service Operator users will need this new authorization to be able to configuration firewall policy. DEVELOPER DOCUMENTATION Services providing remote capabilities are encouraged to participate in the firewall framework to control network access to the service. While framework integration isn't mandatory, remote access to services that are not integrated in the framework may not function correctly when a system-wide policy is configured. Integrating a service into the framework is as straightforward as defining two additional property groups and their corresponding properties in the service manifest. IPfilter rules are generated when user enables the service. In the non-trivial case of custom rule generation where a shell script is required, there are existing scripts that can be used as examples. The additional property groups, firewall_config and firewall_context stores firewall policy configuration and provides static firewall definition, respectively. Below is a summary of new property groups and properties and their appropriate default values. Firewall policy configuration: firewall_config See FIREWALL POLICY CONFIGURATION section for more information. Access to is protected by a new authorization definition and a user-defined property type. The new authorization should be assigned to the property group value_authorization property such as Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_configuration" as the property type. firewall_config/policy This property's initial value should be "use_global" since services, by default, inherit the Global Default firewall policy. firewall_config/apply_to An empty property, this property has no initial value. firewall_config/exceptions An empty property, this property has no initial value. Firewall static definition: firewall_context See FIREWALL STATIC CONFIGURATION section for more information. Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_definition" as the property type. firewall_context/name Service with well-known, IANA defined port which can be obtained by getservbyname(3SOCKET), the service's IANA name is stored in this property. For RPC services, the RPC program number is stored in this property. firewall_context/isrpc For RPC services, this property should be created with its value set to "true" firewall_context/ipf_method In general, the specified firewall policy is used to generate IPfilter rules to the service's communication port, derived from firewall_context/name property. Services which don't have IANA defined ports and are not RPC services, will need to generate their own IPfilter rules. Services that generate their own rules may choose not to have firewall_context/name and firewall_context/isrpc properties. See the following services svc:/network/ftp:default svc:/network/nfs/server:default svc:/network/ntp:default and others with existing ipf_method for guidance. ATTRIBUTES See attributes(5) for descriptions of the following attributes: System Administration Commands svc.ipfd(1M) ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu SUNWipfr | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO ipfilter(5), ipf(4), rpc(4), svcs(1), svcprop(1), svcadm(1M), svccfg(1M), attributes(5), smf(5) --- /tmp/ipfilter.5.orig Fri Sep 12 14:27:32 2008 +++ /home/tn143363/vpanels/firewall/ipfilter.5 Fri Sep 12 14:03:21 2008 @@ -19,6 +19,118 @@ See ipf(1M) for a procedure to enable and activate the IP Filter feature. +HOST-BASED FIREWALL + To simplify IPfilter configuration management, a firewall framework is + created to allow users to configure IPfilter by expressing firewall policy + at system and service level. Given the user defined firewall policy, the + framework generates a set of IPfilter rules to enforce the desired system + behavior. Users specify system and service firewall policies that allow or + deny network traffic from certain hosts, subnets, and interface(s). The + policies are translated into a set of active ipf rules to enforce the + specified firewall policies. + + Note - + + Users can still specify their own ipf rule file if they choose not to + take advantage of the framework. See svc.ipf(1M) and ipf(4). + + Model + + This section describes the host-based firewall framework. See svc.ipfd(1M) + for details on how to configure firewall policies. + + A three layer approach with different precedence levels helps us achieve + the desired behaviors. + + Global Default - default system-wide firewall policy. This policy is + automatically inherited by all services unless services modify their + firewall policy. + + Network Services - higher precedence than Global Default. A service's + policy allows/disallows traffic to its specific ports, regardless of + Global Default policy. + + Global Override - another system-wide policy that takes precedence over + the needs of specific services in Network Services layer. + + Global Override + | + | + Network Services + | + | + Global Default + + A firewall policy includes a firewall mode and an optional set of network + sources. Network sources are IP addresses, subnets, and local network + interfaces, from which a system can receive incoming traffic. The basic set + of firewall modes are: + + None - no firewall, allow all incoming traffic + + Deny - allow all incoming traffic but deny from specified source(s) + + Allow - deny all incoming traffic but allow from specified source(s) + + Layers in Detail + + The first system-wide layer, Global Default, defines a firewall policy + that applies to *any* incoming traffic, e.g. allowing or blocking all + traffic from an IP address. This makes it simple to have a policy that + blocks all incoming traffic or all incoming traffic from unwanted source(s). + + The Network Services layer contains firewall policies for local programs + that provide service to remote clients, e.g. telnetd, sshd, and httpd. + Each of these programs, a network service, has its own firewall policy + that controls access to its service. Initially, a service's policy is set + to inherit Global Default policy, a "Use Global Default" mode. This makes + it simple to set a single policy, at the Global Default layer, that can be + inherited by all services. + + When a service's policy is different from Global Default policy, the + service's policy has higher precedence. If Global Default policy is set + to block all traffic from a subnet, the SSH service could be configured to + allow access from certain hosts in that subnet. The set of all policies + for all network services comprises the Network Service layer. + + The second sytem-wide layer, Global Override, has a firewall policy that + also applies to any incoming network traffic. This policy has highest + precedence and overrides policies in the other layers, specifically + overriding the needs of network services. The example is when it's + desirable block known malicious source(s) regardless of services' + policies. + + User Interaction + + This framework leverages IPfilter functionality and is active only when + svc:/network/ipfilter is enabled and inactive when network/ipfilter is + disabled. Similarly, a network service's firewall policy is only active + when that service is enabled and inactive when the service is disabled. A + system with an active firewall has IPfilter rules for each running/enabled + network service and system-wide policy(s) whose firewall mode isn't "None." + User configures firewall by setting the system-wide policies and policy + for each network service. See svc.ipfd(1M) on how to configure a firewall + policy. + + The firewall framework composes of policy configuration and a mechanism to + generate ipfilter rules from the policy and applying those rules to get + the desired IPfilter configuration. A quick summary of the design and user + interaction: + + - system-wide policy(s) are stored in network/ipfilter + + - network services' policies are stored in each SMF service + + - user activates firewall by enabling network/ipfilter, see ipf(1M) + + - user activates/deactivate a service's firewall by enabling/disabling + that network service + + - changes to system-wide or per-service firewall policy results in an + update to the system's firewall rules + --- /tmp/ipf.1m.orig Fri Sep 12 14:10:40 2008 +++ /home/tn143363/vpanels/firewall/ipf.1m Fri Sep 12 14:21:46 2008 @@ -46,7 +46,8 @@ ment rights profile (see rbac(5)) or become superuser. - 2. Create a packet filtering rule set. See ipf(4). + 2. Configure system and services' firewall policies. + See svc.ipfd(1M) and ipf(4). 3. (Optional) Create a network address translation (NAT) configuration file. See ipnat.conf(4). @@ -84,35 +85,16 @@ - To re-enable packet filtering after it has been temporarily - disabled either reboot the machine or perform the following - series of commands: + disabled either reboot the machine or run the following + command: - 1. Enable Solaris IP Filter: + # svcadm enable network/ipfilter - # ipf -E - - - - 2. Activate packet filtering: - - # ipf -f - - - - 3. (Optional) Activate NAT: - - ipnat -f - - - See ipnat(1M). - Note - - If you reboot your system, the packet filtering rules in - the /etc/ipf/ipf.conf file and the /etc/ipf/ipnat.conf - file are activated. + If you reboot your system, the IPfilter configuration is + automatically activated. --Boundary_(ID_h/1Go2Qvel0eEeIOX8aTqw) Content-type: text/plain; name=svc.ipfd.1m Content-transfer-encoding: 7BIT Content-disposition: inline; filename=svc.ipfd.1m System Administration Commands svc.ipfd(1M) NAME svc.ipfd - IPfilter firewall monitoring daemon SYNOPSIS /lib/svc/bin/svc.ipfd svc:/network/ipfilter:default DESCRIPTION svc.ipfd monitors actions to services with firewall configuration and initiates update services' IPfilter configuration. The daemon allows us to react to changes in system's firewall configuration in an incremental fashion, at per service level. A service's firewall policy is activated when it's enabled, deactivated when it's disabled, and updated when its configuration property group is modified. svc.ipfd monitors SMF repository for these actions and invokes IPfilter rule generation process to carry out the service's firewall policy. Environment Variables and Context This daemon is started by the network/ipfilter service either through the start or refresh method. Thus, the daemon inherits the environment variables and credentials from the method and runs as root with all zone privileges. FIREWALL STATIC CONFIGURATION Static definition describing service's network resource configuration that is used to generate service specific ipf rules. A new per service "firewall_context" property group contains a service's static definition, similar to "inetd" property group in inetd managed services. - firewall_context/name, IANA name or RPC name for non-inetd service, equivalent to inetd/name property - firewall_context/isrpc, a boolean property where a "true" value indicates an RPC service, equivalent to inetd/isrpc property. For RPC services, the value of firewall_context/name is not an IANA name but is either an RPC program number or name, see rpc(4). Additionally, some services may require a mechanism to generate and supply their own ipf rules. An optional property ipf_method, provides a mechanism to allow custom rule generation. - firewall_context/ipf_method, a command, normally a script that generates ipf rules for a service. The framework does not generate rules for services with this property definition but expect these services to provide their own rules. A service's ipf_method specifies a command that takes an additional argument, its own fmri and generates the service's firewall rules and output the rules to stdout. To generate rules for a service with ipf_method property, the framework execs the command specified in ipf_method, passing the service fmri as the additional argument and stores the rules for that service by redirecting the command output, the rules, to the service's rule file. Because an ipf_method is exec'ed from the context of either network/ipfilter start or refresh method process, it inherits the execution context and runs as root. Administrative Privilege The service static configuration, is delivered by service developer and and not intended to be modified by users. These properties are only modified upon installation of an updated service definition. FIREWALL POLICY CONFIGURATION A per service property group, firewall_config, stores the services' firewall policy configuration. Since network/ipfilter:default is responsible for two firewall policies, Global Default and Global Override system-wide policies as explained in ipfilter(5), it has two property groups, firewall_config_default and firewall_config_override, to store the respective sytem-wide policies. Below are the properties, their possible values and correspoding semantics: policy "none" policy mode - no access restriction. For a global policy, this mode allows all incoming traffic. For a service policy, this mode allows all incoming traffic to its service. "deny" policy mode: more restrictive than "none". This mode allows incoming traffic from all sources except those specified in the "apply_to" property. "allow" policy mode: most restrictive mode. This mode blocks incoming traffic from all sources except those specified in the "apply_to" property. apply_to A multi-value property listing network entities to enforce the chosen policy mode. Entities listed in apply_to property will be denied if policy is "deny" and allowed if policy is "allow". The syntax for possible values are: host: host:IP "host:192.168.84.14" subnet: network:IP/netmask "network:129.168.1.5/24" ippool: pool:pool number "pool:77" interface: if:interface_name "if:e1000g0" exceptions A multi-value property listing network entities to be excluded from the "apply_to" list. For example, when deny policy is applied to a subnet, exceptions can be made to some hosts in that subnet by specifying them in the "exceptions" property. This property has the same value syntax as "apply_to" property. For individual network services only: firewall_config/policy A service's policy can also be set to "use_global". Services with "use_global" policy mode inherits the Global Default firewall policy. For the Global Default only: firewall_config_default/policy - can also be set to "custom" Global Default policy, firewall_config property group in svc:/network/ipfilter:default, can also be set to "custom". Users can set policy to "custom" to use prepopulated IPfilter configuration, e.g. existing IPfilter configuration or custom configurations that can't be provided by the framework. This Global Default only policy mode allows users to supply a text file containing the complete set of ipf rules. When "custom" mode is selected, the specified set of ipf rules is *complete* and the framework will not generate ipf rules from configured firewall policies. firewall_config_default/custom_policy_file A file path to be used when Global Default policy is set to "custom". The file contains a set of ipf rules which provide the desired IPfiler configuration. firewall_config_default/open_ports Non-service program requiring allowance of its incoming traffic can request the firewall to allow traffic to its communication ports. This multi-value property property contains protocol and port(s) tuple in the form "{tcp | udp}:{PORT | PORT-PORT}" Initially, the system-wide policies are set to "none" and network services' policies are set to "use_global". Enabling network/ipfilter activates the firewall with an empty set of ipfilter rules, since system-wide policy is "none" and all services inherit that policy. To configure a more restrictive policy, use svccfg(1M) to modify network services and system-wide policies. Administrative Privilege User configures firewall policy by modifying the service's firewall_config property group. A new authorization "solaris.smf.value.firewall.config" is created to allow delgation of firewall administration privilege to users. The Service Operator users will need this new authorization to be able to configuration firewall policy. DEVELOPER DOCUMENTATION Services providing remote capabilities are encouraged to participate in the firewall framework to control network access to the service. While framework integration isn't mandatory, remote access to services that are not integrated in the framework may not function correctly when a system-wide policy is configured. Integrating a service into the framework is as straightforward as defining two additional property groups and their corresponding properties in the service manifest. IPfilter rules are generated when user enables the service. In the non-trivial case of custom rule generation where a shell script is required, there are existing scripts that can be used as examples. The additional property groups, firewall_config and firewall_context store firewall policy configuration and provides static firewall definition, respectively. Below is a summary of new property groups and properties and their appropriate default values. Firewall policy configuration: firewall_config See FIREWALL POLICY CONFIGURATION section for more information. Access to is protected by a new authorization definition and a user-defined property type. The new authorization should be assigned to the property group value_authorization property such as Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_configuration" as the property type. firewall_config/policy This property's initial value should be "use_global" since services, by default, inherit the Global Default firewall policy. firewall_config/apply_to An empty property, this property has no initial value. firewall_config/exceptions An empty property, this property has no initial value. Firewall static definition: firewall_context See FIREWALL STATIC CONFIGURATION section for more information. Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_definition" as the property type. firewall_context/name Service with well-known, IANA defined port which can be obtained by getservbyname(3SOCKET), the service's IANA name is stored in this property. For RPC services, the RPC program number is stored in this property. firewall_context/isrpc For RPC services, this property should be created with its value set to "true" firewall_context/ipf_method In general, the specified firewall policy is used to generate IPfilter rules to the service's communication port, derived from firewall_context/name property. Services which don't have IANA defined ports and are not RPC services, will need to generate their own IPfilter rules. Services that generate their own rules may choose not to have firewall_context/name and firewall_context/isrpc properties. See the following services svc:/network/ftp:default svc:/network/nfs/server:default svc:/network/ntp:default and others with existing ipf_method for guidance. ATTRIBUTES See attributes(5) for descriptions of the following attributes: System Administration Commands svc.ipfd(1M) ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu SUNWipfr | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO ipfilter(5), ipf(4), rpc(4), svcs(1), svcprop(1), svcadm(1M), svccfg(1M), attributes(5), smf(5) --Boundary_(ID_h/1Go2Qvel0eEeIOX8aTqw)-- From Truong.Q.Nguyen@sun.com Thu Oct 2 12:54:18 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92JsIpu023619 for ; Thu, 2 Oct 2008 12:54:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m92JsAeW004312 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 12:54:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400K0HNAHD300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 13:54:17 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8400GE3NAGPE40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 13:54:17 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m92JsGDw021178 for ; Thu, 02 Oct 2008 19:54:16 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400601M30MS00@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 13:54:16 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8400BCENABBL80@mail-amer.sun.com>; Thu, 02 Oct 2008 13:54:11 -0600 (MDT) Date: Thu, 02 Oct 2008 12:54:11 -0700 From: Tony Nguyen Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48E51523.7080609@sun.com> Sender: Truong.Q.Nguyen@sun.com To: Andrew Gabriel Cc: Kais.Belgaied@sun.com, PSARC-ext@sun.com, Darren Reed Message-id: <48E526E3.8060007@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> <48E51523.7080609@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 2488 Andrew Gabriel wrote: > I've looked through the new spec. > > I have some questions about how the current method of configuring > IPfilter will continue to work in the new framework. (I have programs > which build ipf.conf and reapply it dynamically as needed, and I don't > have any interest in automatically allowing/denying access based on SMF > service states. I guess that makes me an "advanced user" in your > terminology.) > > So, if I understand correctly, to enable current mode of operation, I > would issue the commands: > > svccfg -s svc:/network/ipfilter: setprop firewall_config_default/policy > = custom > svcadm enable svc:/network/ipfilter Andrew, We also need to specify the rules file: svccfg -s svc:/network/ipfilter: setprop firewall_config_default/policy = astring: "/foo/bar.conf" > This needs clearly stating as an example on a manpage (ipf(1M) and/or > ipf(4)). will do. > > What happens on upgrade of a system with an existing ipf.conf file and > IPfilter enabled? Will you automatically do this? If not, how do you > handle upgrade? Good catch, I almost missed this. Yes, we need to set the above values appropriate on upgrade, most likely via a profile/upgrade script. > In the ipf(1M) manpage, you have removed the ipf and ipnat command > examples. This is incorrect -- these are still used and required for > current method of operation. You perhaps just need to add a comment that > these wouldn't be used if using the SMF framework to automatically build > firewall rules. You have also effectively removed the instructions for > changing filter rules without either rebooting or disabling IPfilter. It > is an important feature of IPfilter that it allows rules to be changed > dynamically without disabling it or rebooting the system, and this needs > to remain on the manpage. ipf(1M) is a committed interface and a key > part of the access to important features of IPfilter. > Actually, I removed that section for correctness and consistency, independently of firewall. IPfilter is an SMF service and should really be managed via SMF commands, in this case: "svcadm restart ipfilter" for "ipf -E" "svcadm refresh ipfilter" for "ipf -f ipf.conf; ipf -f nat.conf" The argument here is choices for the customer but it can also be a little confusing to have the man page shows starting network/ipfilter with SMF command and restart/refresh actions are done with non-SMF commands. Does it make sense? Thanks, tony From ceri@submonkey.net Thu Oct 2 13:01:54 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92K1shH023851 for ; Thu, 2 Oct 2008 13:01:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m92K1rwm004126; Thu, 2 Oct 2008 14:01:53 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400K3LNN4QV00@brm-avmta-1.central.sun.com>; Thu, 02 Oct 2008 14:01:52 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8400GFJNKWPG50@brm-avmta-1.central.sun.com>; Thu, 02 Oct 2008 14:00:32 -0600 (MDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m92Ju55o001646; Thu, 02 Oct 2008 20:00:31 +0000 (GMT) Received: from mms22es.mms.us.syntegra.com ([150.143.232.30] [150.143.232.30]) by relay23i.sun.com with ESMTP id BT-MMP-4837695; Thu, 02 Oct 2008 20:00:31 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms22es.mms.us.syntegra.com with ESMTP id BT-MMP-40932300; Thu, 02 Oct 2008 20:00:31 +0000 (Z) Received: from scuttle.submonkey.net ([208.111.43.184] [208.111.43.184]) by relay21i.sun.com with ESMTP id BT-MMP-59048189; Thu, 02 Oct 2008 20:00:31 +0000 (Z) Received: from cpc1-cdif1-0-0-cust63.cdif.cable.ntl.com ([81.104.164.64] helo=shrike.submonkey.net) by scuttle.submonkey.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KlUKf-0002xI-Bg; Thu, 02 Oct 2008 19:59:29 +0000 Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlULc-000IRL-FY; Thu, 02 Oct 2008 21:00:28 +0100 Date: Thu, 02 Oct 2008 21:00:28 +0100 From: Ceri Davies Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48E52100.80408@sun.com> Sender: Ceri Davies To: Tony Nguyen Cc: PSARC-ext@sun.com Message-id: <20081002200028.GF28158@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=B0nZA57HJSoPbsHY Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=0.0/5.0, scanned in 0.105sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> <20081002191023.GE28158@submonkey.net> <48E52100.80408@sun.com> User-Agent: Mutt/1.5.18 (2008-05-17) Status: RO Content-Length: 1139 --B0nZA57HJSoPbsHY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 02, 2008 at 12:29:04PM -0700, Tony Nguyen wrote: > Ceri Davies wrote: > > On Tue, Sep 30, 2008 at 03:32:52PM -0700, Kais Belgaied wrote: > >> The project team provided an updated spec. > >> On behalf of the submitter (currently traveling) I' re-opening the cas= e. > >> The project team is under some time pressure, so the timer is set to > >> the end of this week (Oct. 3rd). > >=20 > > I can't see the new spec on the website; would you be able to post it to > > the list please? > >=20 > > Ceri >=20 > Ceri, >=20 > Here you go. Thanks Tony. Looks good to me. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --B0nZA57HJSoPbsHY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFI5ShcocfcwTS3JF8RAmUlAKCUu2zIF99MfkmscBU2D1Hu90tXIACfUR7v P7QgECM1AoqMoSZ7onbGTYg= =dGBB -----END PGP SIGNATURE----- --B0nZA57HJSoPbsHY-- From Andrew.Gabriel@sun.com Thu Oct 2 14:00:49 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92L0m8I027788 for ; Thu, 2 Oct 2008 14:00:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m92L0jDS001618 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 22:00:47 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400305QDA6000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 14:00:46 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K84001G6QD8OJ70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 14:00:45 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m92L0iHQ026088 for ; Thu, 02 Oct 2008 21:00:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400I01QACNN00@fe-emea-10.sun.com> (original mail from Andrew.Gabriel@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 22:00:44 +0100 (BST) Received: from [81.187.162.109] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K84000T6QD79B80@fe-emea-10.sun.com>; Thu, 02 Oct 2008 22:00:44 +0100 (BST) Date: Thu, 02 Oct 2008 22:01:02 +0100 From: Andrew Gabriel Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48E526E3.8060007@sun.com> Sender: Andrew.Gabriel@sun.com To: Tony Nguyen Cc: Kais.Belgaied@sun.com, PSARC-ext@sun.com, Darren Reed Message-id: <48E5368E.9050705@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> <48E51523.7080609@sun.com> <48E526E3.8060007@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 2672 Tony Nguyen wrote: > Andrew Gabriel wrote: >> In the ipf(1M) manpage, you have removed the ipf and ipnat command >> examples. This is incorrect -- these are still used and required for >> current method of operation. You perhaps just need to add a comment >> that these wouldn't be used if using the SMF framework to >> automatically build firewall rules. You have also effectively removed >> the instructions for changing filter rules without either rebooting or >> disabling IPfilter. It is an important feature of IPfilter that it >> allows rules to be changed dynamically without disabling it or >> rebooting the system, and this needs to remain on the manpage. ipf(1M) >> is a committed interface and a key part of the access to important >> features of IPfilter. > > Actually, I removed that section for correctness and consistency, > independently of firewall. IPfilter is an SMF service and should really > be managed via SMF commands, in this case: > > "svcadm restart ipfilter" for "ipf -E" > "svcadm refresh ipfilter" for "ipf -f ipf.conf; ipf -f nat.conf" > > The argument here is choices for the customer but it can also be a > little confusing to have the man page shows starting network/ipfilter > with SMF command and restart/refresh actions are done with non-SMF > commands. Does it make sense? No. The manpage is for the ipf(1M) command, and it makes no sense to remove the example usage of the very command the manpage is describing. I think that an "advanced user" is likely to start ipfilter with SMF, and manipulate it dynamically with the ipf(1M) and/or ipnat(1M) commands thereafter (at least, I do). It would make sense to add the SMF command example too, and a description of when you should use one or the other. The ipf(1M) and ipnat(1M) commands are much more fully featured than you can access via SMF, so SMF isn't a replacement for them, except in the most simple of cases. (Strangely, the ipfilter SMF method script contains other useful functions such as reipf and reipnat, but SMF has no mechanism for calling them.) Alternatively, you could take the view that the ipf(1M) and ipnat(1M) (and ippool(1M)?) manpages are only appropriate for "advanced users" anyway. You could move all the detailed ipfilter SMF instructions to the ipfilter(5) manpage, and then include only an appropriate cross reference from each of the "advanced user" command manpages. I think that makes most sense. However, my main concern was that you aren't proposing to change or disable or decommit/obsolete the direct use of ipf(1M) and ipnat(1M) commands, which it looks like you aren't, so that's OK. -- Cheers Andrew From Truong.Q.Nguyen@sun.com Thu Oct 2 14:45:08 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92Lj7Ic029217 for ; Thu, 2 Oct 2008 14:45:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m92LixkZ017795 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 22:45:06 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K840010JSF5DX00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 14:45:05 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8400JBASF5N020@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 14:45:05 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m92Lj4tT004580 for ; Thu, 02 Oct 2008 21:45:04 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400E01RVHOZ00@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 15:45:04 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K84006KUSEYC910@mail-amer.sun.com>; Thu, 02 Oct 2008 15:44:58 -0600 (MDT) Date: Thu, 02 Oct 2008 14:44:58 -0700 From: Tony Nguyen Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48E5368E.9050705@sun.com> Sender: Truong.Q.Nguyen@sun.com To: Andrew Gabriel Cc: Kais.Belgaied@sun.com, PSARC-ext@sun.com, Darren Reed Message-id: <48E540DA.6080107@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> <48E51523.7080609@sun.com> <48E526E3.8060007@sun.com> <48E5368E.9050705@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 3239 Andrew Gabriel wrote: > Tony Nguyen wrote: >> Andrew Gabriel wrote: >>> In the ipf(1M) manpage, you have removed the ipf and ipnat command >>> examples. This is incorrect -- these are still used and required for >>> current method of operation. You perhaps just need to add a comment >>> that these wouldn't be used if using the SMF framework to >>> automatically build firewall rules. You have also effectively removed >>> the instructions for changing filter rules without either rebooting >>> or disabling IPfilter. It is an important feature of IPfilter that it >>> allows rules to be changed dynamically without disabling it or >>> rebooting the system, and this needs to remain on the manpage. >>> ipf(1M) is a committed interface and a key part of the access to >>> important features of IPfilter. >> >> Actually, I removed that section for correctness and consistency, >> independently of firewall. IPfilter is an SMF service and should >> really be managed via SMF commands, in this case: >> >> "svcadm restart ipfilter" for "ipf -E" >> "svcadm refresh ipfilter" for "ipf -f ipf.conf; ipf -f nat.conf" >> >> The argument here is choices for the customer but it can also be a >> little confusing to have the man page shows starting network/ipfilter >> with SMF command and restart/refresh actions are done with non-SMF >> commands. Does it make sense? > > No. The manpage is for the ipf(1M) command, and it makes no sense to > remove the example usage of the very command the manpage is describing. > I think that an "advanced user" is likely to start ipfilter with SMF, > and manipulate it dynamically with the ipf(1M) and/or ipnat(1M) commands > thereafter (at least, I do). I see. > > It would make sense to add the SMF command example too, and a > description of when you should use one or the other. The ipf(1M) and > ipnat(1M) commands are much more fully featured than you can access via > SMF, so SMF isn't a replacement for them, except in the most simple of > cases. (Strangely, the ipfilter SMF method script contains other useful > functions such as reipf and reipnat, but SMF has no mechanism for > calling them.) I agree that ipf command features can't be replaced by the current SMF. In this specific example, the three ipf commands can be replaced by a single svcadm restart command so it was really tempting :) > Alternatively, you could take the view that the ipf(1M) and ipnat(1M) > (and ippool(1M)?) manpages are only appropriate for "advanced users" > anyway. You could move all the detailed ipfilter SMF instructions to the > ipfilter(5) manpage, and then include only an appropriate cross > reference from each of the "advanced user" command manpages. I think > that makes most sense. How about leaving the example intact and add the boilerplate phrase to ipfilter(5) which says ipfilter is managed by SMF under network/ipfilter and administrative actions should be done via svcadm? > > However, my main concern was that you aren't proposing to change or > disable or decommit/obsolete the direct use of ipf(1M) and ipnat(1M) > commands, which it looks like you aren't, so that's OK. > Correct, we are not obsoleting direct use of ipf. Much appreciated, tony From John.Plocher@sun.com Thu Oct 2 14:57:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92LvNcv029791 for ; Thu, 2 Oct 2008 14:57:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m92LvM3u022299 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 22:57:23 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400605SZLBJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 15:57:21 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8400GSQSZLPEE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 15:57:21 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m92LvLUV016496 for ; Thu, 02 Oct 2008 14:57:21 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400M01SX5KE00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 14:57:21 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8400L8CSZAI570@fe-sfbay-09.sun.com>; Thu, 02 Oct 2008 14:57:10 -0700 (PDT) Date: Thu, 02 Oct 2008 14:57:08 -0700 From: John Plocher Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48E540DA.6080107@sun.com> Sender: John.Plocher@sun.com To: Tony Nguyen Cc: Andrew Gabriel , Kais.Belgaied@sun.com, Darren Reed , PSARC-ext@sun.com Message-id: <48E543B4.60802@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> <48E51523.7080609@sun.com> <48E526E3.8060007@sun.com> <48E5368E.9050705@sun.com> <48E540DA.6080107@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 389 Tony Nguyen wrote: > I agree that ipf command features can't be replaced by the current SMF. > In this specific example, the three ipf commands can be replaced by a > single svcadm restart command so it was really tempting :) It may be useful to use this as an example: ... BTW, the svcadm interface invokes the following commands, which illustrate the use of ipf... -John From Truong.Q.Nguyen@sun.com Thu Oct 2 16:38:59 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92NcvKj003182 for ; Thu, 2 Oct 2008 16:38:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m92NcqVT029185 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 3 Oct 2008 07:38:57 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400E05XOV0Y00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 16:38:55 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8400JMKXOTMT80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 16:38:53 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m92NcrHu019276 for ; Thu, 02 Oct 2008 23:38:53 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400901XO9RA00@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 17:38:53 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K840013DXOF32F0@mail-amer.sun.com>; Thu, 02 Oct 2008 17:38:39 -0600 (MDT) Date: Thu, 02 Oct 2008 16:38:38 -0700 From: Tony Nguyen Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] In-reply-to: <48E543B4.60802@Sun.Com> Sender: Truong.Q.Nguyen@sun.com To: John Plocher Cc: Andrew Gabriel , Kais.Belgaied@sun.com, Darren Reed , PSARC-ext@sun.com Message-id: <48E55B7E.1050703@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> <48E51523.7080609@sun.com> <48E526E3.8060007@sun.com> <48E5368E.9050705@sun.com> <48E540DA.6080107@sun.com> <48E543B4.60802@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 1249 John Plocher wrote: > Tony Nguyen wrote: >> I agree that ipf command features can't be replaced by the current >> SMF. In this specific example, the three ipf commands can be replaced >> by a single svcadm restart command so it was really tempting :) > > > It may be useful to use this as an example: > > ... BTW, the svcadm interface invokes the following commands, > which illustrate the use of ipf... > > > -John That sounds like a good idea. Would the below text be reasonable? thanks, tony ================================================ To re-enable packet filtering after it has been temporarily disabled either reboot the machine or run the following command: # svcadm restart network/ipfilter which essentially executes the following ipf commands: 1. Enable Solaris IP Filter: # ipf -E 2. Load ippools: # ippool -f See ippool(1M) 3. Activate packet filtering: # ipf -f 4. (Optional) Activate NAT: # ipnat -f See ipnat(1M). Note - If you reboot your system, the IPfilter configuration is automatically activated. =========================================== From Truong.Q.Nguyen@sun.com Thu Oct 2 17:52:14 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m930qEsO006117 for ; Thu, 2 Oct 2008 17:52:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m930q5nv027741 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 18:52:13 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8500M01131DP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 17:52:13 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8500JX3130MTB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 17:52:12 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m930qCkY028797 for ; Fri, 03 Oct 2008 00:52:12 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8500G010ZFFE00@mail-amer.sun.com> (original mail from Truong.Q.Nguyen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 18:52:12 -0600 (MDT) Received: from [129.146.226.122] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K85005V612Y3540@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 18:52:11 -0600 (MDT) Date: Thu, 02 Oct 2008 17:52:10 -0700 From: Tony Nguyen Subject: Solaris host-based firewall [PSARC/2008/580 FastTrack] - updated manpages In-reply-to: <48E543B4.60802@Sun.Com> Sender: Truong.Q.Nguyen@sun.com To: John Plocher Cc: Darren Reed , PSARC-ext@sun.com Message-id: <48E56CBA.8090503@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_x6gCGbiIa+tpTOSxwJeHtg)" X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> <48E51523.7080609@sun.com> <48E526E3.8060007@sun.com> <48E5368E.9050705@sun.com> <48E540DA.6080107@sun.com> <48E543B4.60802@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 59360 This is a multi-part message in MIME format. --Boundary_(ID_x6gCGbiIa+tpTOSxwJeHtg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Per our discussions today, I'm attached the updated manpages. Thanks, tony John Plocher wrote: > Tony Nguyen wrote: >> I agree that ipf command features can't be replaced by the current >> SMF. In this specific example, the three ipf commands can be replaced >> by a single svcadm restart command so it was really tempting :) > > > It may be useful to use this as an example: > > ... BTW, the svcadm interface invokes the following commands, > which illustrate the use of ipf... > > > -John > --Boundary_(ID_x6gCGbiIa+tpTOSxwJeHtg) Content-type: text/plain; name=arc_proposal Content-transfer-encoding: 7BIT Content-disposition: inline; filename=arc_proposal Solaris host-based firewall Truong Q. Nguyen (Tony Nguyen) 09/08/2008 1. Introduction Currently, Solaris has IPfilter which allows user to set up system and service firewall policies. The project delivers a framework to simplify system and services IPfilter configuration. IPfilter uses a set of ipf rules from which it determines whether an IP packet should be allowed in or out of the system. Although ipf rule syntax is fairly simple and straightforward, it still demands good understanding of networking and security concepts, a non-trivial learning curve for 'casual' Solaris users. Moreover, the task of creating and testing ipf rules are mostly manual and can become a management burden in systems where large number of rules are used. Instead of manually construct and specify ipf rules, the proposed framework allows users to express system and services' firewall policies which it uses to generates a set of IPfilter rules to enforce the desired behavior. Essentially, users specify system and service firewall policies that allow or disallow network traffic from certain hosts, subnets, and interface(s). The policies can be translated into a set of active ipf rules to enforce the specified firewall policies. Existing firewall tools, fwbuilder being a good example, may provide highly customized configuration but have other drawbacks. Our proposed solution which targets casual OpenSolaris users, has clear advantages. - Very simple user model. While FirewallBuilder is able to produce highly customized configurations, it requires good understanding of firewall concept and knowledge of the system networking configuration. Setting up FirewallBuilder requires specifying a path, a file, local address, create objects for each service, *configure* firewall for the objects, compile, and run. Our firewall only requires setting policy by changing properties and enable service(s). - Well-integrated with Solaris - Supports IPfilter configuration generated by other tools. Our framework should satisfy the needs of most casual users. However, advanced users can always use tools such as FirewallBuilder to generate IPfilter rules that can be consumed by the proposed framework. 2. Scope Our goal is to provide casual OpenSolaris users and developers a simple way to harden their systems. System administrators can certainly use the firewall framework but may find some deficiencies such as inability to synchronize policies across a group of Solaris systems. The propose project is NOT a firewall configuration tool but an IPfilter-based firewall framework that allows high-level firewall policies and translates those policies to IPfilter rules. Generic firewall construction tools, if possible, should use the proposed framework to configure IPfilter for Solaris machines. The proposed framework isn't a full IPfilter configuration tool, thus it won't generate every possible IPfilter configuration. However, users can specified a custom ipf rule set to be used if the framework can't provide the desired IPfilter configuration. 3. Design Model: The proposed firewall framework provides a simple mechanism to restrict incoming network traffic to a Solaris machine. Network traffic is normally from remote servers and clients to local clients and servers(local network services), respectively. Other types of network traffic include broadcasts and ICMP messages. The goal of any firewall is to block unwanted incoming network traffic and/or restrict access to certain source(s) while allow local client programs to work seamlessly. A three layer approach with different precedence levels helps us achieve the desired behaviors. Global Default - default system-wide policy. This policy is automatically inherited by all services unless services modify their firewall policy. Network Services - higher precedence than Global Default. A service's policy allows/disallows traffic to its specific ports, regardless of Global Default policy. Global Override - another system-wide policy that takes precedence over the needs of specific services in Network Services layer. Global Override | | Network Services | | Global Default A firewall policy includes a firewall mode and an optional set of network sources. Network sources are IP addresses, subnets, and local network interfaces, from which a system can receive incoming traffic. The basic set of firewall modes are: None - no firewall, allow all incoming traffic Deny - allow all incoming traffic but deny from specified source(s) Allow - deny all incoming traffic but allow from specified source(s) Layers in Detail: The first system-wide layer, Global Default, defines a firewall policy that applies to *any* incoming traffic, e.g. allowing or blocking all traffic from an IP address. This makes it simple to have a policy that blocks all incoming traffic or all incoming traffic from unwanted source(s). The Network Services layer contains firewall policies for local programs that provide service to remote clients, e.g. telnetd, sshd, and httpd. Each of these programs, a network service, has its own firewall policy that controls access to its service. Initially, a service's policy is set to inherit Global Default policy, a "Use Global Default" mode. This makes it simple to set a single policy, at the Global Default layer, that can be inherited by all services. When a service's policy is different from Global Default policy, the service's policy has higher precedence. If Global Default policy is set to block all traffic from a subnet, the SSH service could be configured to allow access from certain hosts in that subnet. The set of all policies for all network services comprises the Network Service layer. The second sytem-wide layer, Global Override, has a firewall policy that also applies to any incoming network traffic. This policy has highest precedence and overrides policies in other layers, specifically overriding the needs of network services. The example is when it's desirable block known malicious source(s) regardless of services' policies. User Interaction: This framework leverages IPfilter functionality and is only active when svc:/network/ipfilter is enabled. Similarly, a network service's firewall policy is only active when that service is enabled. A system with an active firewall has IPfilter rules for each running/enabled network service and for system-wide policy(s) with firewall mode other than "None". User's enabling and disabling action for a service corresponds to firewall policy activation and deactivation for that service. A user changes firewall settings by modifying a service and/or system-wide firewall policy. The firewall framework composes of policy configuration and a mechanism to generate ipfilter rules from the policy and applying those rules to get the desired IPfilter configuration. A quick breakdown of the design: - system-wide policy(s) are stored in network/ipfilter - network services' policies are stored in each SMF service - activate firewall by enabling network/ipfilter - activate/deactivate per-service firewall policy by enabling/disabling that network service - changing a system-wide or per-service firewall policy results in an update to the system's firewall rules Availability and observability: Misconfigured firewall policies will result in service unavailability, service in maintenance state. The rationale here is that once the firewall is activated, services should not be allowed to run exposed. Essentially, the desired behaviors are 1. If a service firewall policy is misconfigured, the service is placed in maintenance and appropriate information should be logged in service's log to explain the failure. 2. If a system-wide policy is misconfigured, network/ipfilter is placed in in maintenance which is the current behavior. Additionally, network services also get placed in maintenance mode such that they are not running exposed. 4. Configuration See the new svc.ipfd.1m 5. IPv6 support The proposed architecture fully supports IPv6 which comprises of allowing policy configuration to store IPv6 addresses and pools and separately generating and loading IPv6 rules. Providing IPv6 addresses and pools suport in policy configuration can be done by additional type specifiers such as: IPv6 host: host6:IP "host6:2001:db8:3c4d::1a2b" IPv6 subnet: network6:IP/netmask "network6:2001:db8:3c4d::/48" IPv6 ippool: pool6:pool number "pool6:66" A service whose policy specifies IPv6 addresses would generate an addtional IPv6 rules file which will be loaded using "ipf -6". However, IPv6 support is not provided at the initial integration. The rationale for this lack of support is twofold. This proposed framework is the enabling technology for the Services Firewall Panel, to be delivered in Visual Panel Project for OpenSolaris 2008.11. The Visual Panels project aims to simply Solaris management for casual Solaris users and a host-based firewall functionality, though lacking IPv6 support, is still a positive step toward that goal. The second reason for not having IPv6 at initial integration is the testing effort required for IPv6 functionality. While the work to support IPv6 is not too challenging, the additional testing places a heavy burden on our schedule thus the proposed incremental integrations. We are committed to support IPv6 and plan to have a follow-on putback in a couple of months to add IPv6 support. 6. Upgrade handling For machines with existing ipf.conf, it's necessary to preserve that setting upon upgrade. This can be done via SMF commands in /var/svc/profile/upgrade to configure the system-wide default policy to "custom" and specify ipf.conf in the custom_policy_file property. 7. Exported Interfaces Service static configuration property group and properties: firewall_context/name Committed firewall_context/isrpc Committed firewall_context/ipf_method Committed Service firewall configuration property groups and properties: firewall_config/policy Committed firewall_config/apply_to Committed firewall_config/exceptions Committed Global Default policy property groups and properties: firewall_config_default/policy Committed firewall_config_default/apply_to Committed firewall_config_default/exceptions Committed firewall_config_default/custom_policy_file Committed firewall_config_default/open_ports Committed Global Override policy property groups and properties: firewall_config_override/policy Committed firewall_config_override/apply_to Committed firewall_config_override/exceptions Committed FMRIs for system-wide policies: svc:/network/ipfilter:default Committed 8. Imported Interfaces libnsl(3LIB) libsocket(3LIB) 9. Documentation changes The SMF FAQ on opensolaris.org will be updated to contain a how-to for both users and service developers. svc.ipfd.1m(new) System Administration Commands svc.ipfd(1M) NAME svc.ipfd - IPfilter firewall monitoring daemon SYNOPSIS /lib/svc/bin/svc.ipfd svc:/network/ipfilter:default DESCRIPTION svc.ipfd monitors actions to services with firewall configuration and initiates update services' IPfilter configuration. The daemon allows us to react to changes in system's firewall configuration in an incremental fashion, at per service level. A service's firewall policy is activated when it's enabled, deactivated when it's disabled, and updated when its configuration property group is modified. svc.ipfd monitors SMF repository for these actions and invokes IPfilter rule generation process to carry out the service's firewall policy. Environment Variables and Context This daemon is started by the network/ipfilter service either through the start or refresh method. Thus, the daemon inherits the environment variables and credentials from the method and runs as root with all zone privileges. FIREWALL STATIC CONFIGURATION Static definition describing service's network resource configuration that is used to generate service specific ipf rules. A new per service "firewall_context" property group contains a service's static definition, similar to "inetd" property group in inetd managed services. - firewall_context/name, IANA name or RPC name for non-inetd service, equivalent to inetd/name property - firewall_context/isrpc, a boolean property where a "true" value indicates an RPC service, equivalent to inetd/isrpc property. For RPC services, the value of firewall_context/name is not an IANA name but is either an RPC program number or name, see rpc(4). Additionally, some services may require a mechanism to generate and supply their own ipf rules. An optional property ipf_method, provides a mechanism to allow custom rule generation. - firewall_context/ipf_method, a command, normally a script that generates ipf rules for a service. The framework does not generate rules for services with this property definition but expect these services to provide their own rules. A service's ipf_method specifies a command that takes an additional argument, its own fmri and generates the service's firewall rules and output the rules to stdout. To generate rules for a service with ipf_method property, the framework execs the command specified in ipf_method, passing the service fmri as the additional argument and stores the rules for that service by redirecting the command output, the rules, to the service's rule file. Because an ipf_method is exec'ed from the context of either network/ipfilter start or refresh method process, it inherits the execution context and runs as root. Administrative Privilege The service static configuration, is delivered by service developer and and not intended to be modified by users. These properties are only modified upon installation of an updated service definition. FIREWALL POLICY CONFIGURATION A per service property group, firewall_config, stores the services' firewall policy configuration. Since network/ipfilter:default is responsible for two firewall policies, Global Default and Global Override system-wide policies as explained in ipfilter(5), it has two property groups, firewall_config_default and firewall_config_override, to store the respective sytem-wide policies. Below are the properties, their possible values and correspoding semantics: policy "none" policy mode - no access restriction. For a global policy, this mode allows all incoming traffic. For a service policy, this mode allows all incoming traffic to its service. "deny" policy mode: more restrictive than "none". This mode allows incoming traffic from all sources except those specified in the "apply_to" property. "allow" policy mode: most restrictive mode. This mode blocks incoming traffic from all sources except those specified in the "apply_to" property. apply_to A multi-value property listing network entities to enforce the chosen policy mode. Entities listed in apply_to property will be denied if policy is "deny" and allowed if policy is "allow". The syntax for possible values are: host: host:IP "host:192.168.84.14" subnet: network:IP/netmask "network:129.168.1.5/24" ippool: pool:pool number "pool:77" interface: if:interface_name "if:e1000g0" exceptions A multi-value property listing network entities to be excluded from the "apply_to" list. For example, when deny policy is applied to a subnet, exceptions can be made to some hosts in that subnet by specifying them in the "exceptions" property. This property has the same value syntax as "apply_to" property. For individual network services only: firewall_config/policy A service's policy can also be set to "use_global". Services with "use_global" policy mode inherits the Global Default firewall policy. For the Global Default only: firewall_config_default/policy - can also be set to "custom" Global Default policy, firewall_config property group in svc:/network/ipfilter:default, can also be set to "custom". Users can set policy to "custom" to use prepopulated IPfilter configuration, e.g. existing IPfilter configuration or custom configurations that can't be provided by the framework. This Global Default only policy mode allows users to supply a text file containing the complete set of ipf rules. When "custom" mode is selected, the specified set of ipf rules is *complete* and the framework will not generate ipf rules from configured firewall policies. firewall_config_default/custom_policy_file A file path to be used when Global Default policy is set to "custom". The file contains a set of ipf rules which provide the desired IPfiler configuration. For example, users with existing ipf rules in /etc/ipf/ipf.conf can excute the following commands to use the existing rules: 1. Set custom policy #svccfg -s ipfilter:default setprop \ firewall_config_default/policy = astring: "custom" 2. Specify custom file #svccfg -s ipfilter:default setprop \ firewall_config_default/custom_policy_file = astring: \ "/etc/ipf/ipf.conf" 3. Refresh configuration #svcadm refresh ipfilter:default firewall_config_default/open_ports Non-service program requiring allowance of its incoming traffic can request the firewall to allow traffic to its communication ports. This multi-value property property contains protocol and port(s) tuple in the form "{tcp | udp}:{PORT | PORT-PORT}" Initially, the system-wide policies are set to "none" and network services' policies are set to "use_global". Enabling network/ipfilter activates the firewall with an empty set of ipfilter rules, since system-wide policy is "none" and all services inherit that policy. To configure a more restrictive policy, use svccfg(1M) to modify network services and system-wide policies. Administrative Privilege User configures firewall policy by modifying the service's firewall_config property group. A new authorization "solaris.smf.value.firewall.config" is created to allow delgation of firewall administration privilege to users. The Service Operator users will need this new authorization to be able to configuration firewall policy. DEVELOPER DOCUMENTATION Services providing remote capabilities are encouraged to participate in the firewall framework to control network access to the service. While framework integration isn't mandatory, remote access to services that are not integrated in the framework may not function correctly when a system-wide policy is configured. Integrating a service into the framework is as straightforward as defining two additional property groups and their corresponding properties in the service manifest. IPfilter rules are generated when user enables the service. In the non-trivial case of custom rule generation where a shell script is required, there are existing scripts that can be used as examples. The additional property groups, firewall_config and firewall_context stores firewall policy configuration and provides static firewall definition, respectively. Below is a summary of new property groups and properties and their appropriate default values. Firewall policy configuration: firewall_config See FIREWALL POLICY CONFIGURATION section for more information. Access to is protected by a new authorization definition and a user-defined property type. The new authorization should be assigned to the property group value_authorization property such as Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_configuration" as the property type. firewall_config/policy This property's initial value should be "use_global" since services, by default, inherit the Global Default firewall policy. firewall_config/apply_to An empty property, this property has no initial value. firewall_config/exceptions An empty property, this property has no initial value. Firewall static definition: firewall_context See FIREWALL STATIC CONFIGURATION section for more information. Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_definition" as the property type. firewall_context/name Service with well-known, IANA defined port which can be obtained by getservbyname(3SOCKET), the service's IANA name is stored in this property. For RPC services, the RPC program number is stored in this property. firewall_context/isrpc For RPC services, this property should be created with its value set to "true" firewall_context/ipf_method In general, the specified firewall policy is used to generate IPfilter rules to the service's communication port, derived from firewall_context/name property. Services which don't have IANA defined ports and are not RPC services, will need to generate their own IPfilter rules. Services that generate their own rules may choose not to have firewall_context/name and firewall_context/isrpc properties. See the following services svc:/network/ftp:default svc:/network/nfs/server:default svc:/network/ntp:default and others with existing ipf_method for guidance. ATTRIBUTES See attributes(5) for descriptions of the following attributes: System Administration Commands svc.ipfd(1M) ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu SUNWipfr | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO ipfilter(5), ipf(4), rpc(4), svcs(1), svcprop(1), svcadm(1M), svccfg(1M), attributes(5), smf(5) --- /tmp/ipfilter.5.orig Fri Sep 12 14:27:32 2008 +++ /home/tn143363/vpanels/firewall/ipfilter.5 Fri Sep 12 14:03:21 2008 @@ -19,6 +19,118 @@ See ipf(1M) for a procedure to enable and activate the IP Filter feature. +HOST-BASED FIREWALL + To simplify IPfilter configuration management, a firewall framework is + created to allow users to configure IPfilter by expressing firewall policy + at system and service level. Given the user defined firewall policy, the + framework generates a set of IPfilter rules to enforce the desired system + behavior. Users specify system and service firewall policies that allow or + deny network traffic from certain hosts, subnets, and interface(s). The + policies are translated into a set of active ipf rules to enforce the + specified firewall policies. + + Note - + + Users can still specify their own ipf rule file if they choose not to + take advantage of the framework. See svc.ipf(1M) and ipf(4). + + Model + + This section describes the host-based firewall framework. See svc.ipfd(1M) + for details on how to configure firewall policies. + + A three layer approach with different precedence levels helps us achieve + the desired behaviors. + + Global Default - default system-wide firewall policy. This policy is + automatically inherited by all services unless services modify their + firewall policy. + + Network Services - higher precedence than Global Default. A service's + policy allows/disallows traffic to its specific ports, regardless of + Global Default policy. + + Global Override - another system-wide policy that takes precedence over + the needs of specific services in Network Services layer. + + Global Override + | + | + Network Services + | + | + Global Default + + A firewall policy includes a firewall mode and an optional set of network + sources. Network sources are IP addresses, subnets, and local network + interfaces, from which a system can receive incoming traffic. The basic set + of firewall modes are: + + None - no firewall, allow all incoming traffic + + Deny - allow all incoming traffic but deny from specified source(s) + + Allow - deny all incoming traffic but allow from specified source(s) + + Layers in Detail + + The first system-wide layer, Global Default, defines a firewall policy + that applies to *any* incoming traffic, e.g. allowing or blocking all + traffic from an IP address. This makes it simple to have a policy that + blocks all incoming traffic or all incoming traffic from unwanted source(s). + + The Network Services layer contains firewall policies for local programs + that provide service to remote clients, e.g. telnetd, sshd, and httpd. + Each of these programs, a network service, has its own firewall policy + that controls access to its service. Initially, a service's policy is set + to inherit Global Default policy, a "Use Global Default" mode. This makes + it simple to set a single policy, at the Global Default layer, that can be + inherited by all services. + + When a service's policy is different from Global Default policy, the + service's policy has higher precedence. If Global Default policy is set + to block all traffic from a subnet, the SSH service could be configured to + allow access from certain hosts in that subnet. The set of all policies + for all network services comprises the Network Service layer. + + The second sytem-wide layer, Global Override, has a firewall policy that + also applies to any incoming network traffic. This policy has highest + precedence and overrides policies in the other layers, specifically + overriding the needs of network services. The example is when it's + desirable block known malicious source(s) regardless of services' + policies. + + User Interaction + + This framework leverages IPfilter functionality and is active only when + svc:/network/ipfilter is enabled and inactive when network/ipfilter is + disabled. Similarly, a network service's firewall policy is only active + when that service is enabled and inactive when the service is disabled. A + system with an active firewall has IPfilter rules for each running/enabled + network service and system-wide policy(s) whose firewall mode isn't "None." + User configures firewall by setting the system-wide policies and policy + for each network service. See svc.ipfd(1M) on how to configure a firewall + policy. + + The firewall framework composes of policy configuration and a mechanism to + generate ipfilter rules from the policy and applying those rules to get + the desired IPfilter configuration. A quick summary of the design and user + interaction: + + - system-wide policy(s) are stored in network/ipfilter + + - network services' policies are stored in each SMF service + + - user activates firewall by enabling network/ipfilter, see ipf(1M) + + - user activates/deactivate a service's firewall by enabling/disabling + that network service + + - changes to system-wide or per-service firewall policy results in an + update to the system's firewall rules + @@ -30,6 +137,15 @@ NOTES - In the current release of the Solaris operating system, IP - Filter startup configuration files are stored in /etc/ipf. + The nfsd service is managed by the service management facil- + ity, smf(5), under the service identifier: + svc:/network/ipfilter:default. + + Administrative actions on this service, such as enabling, + disabling, or requesting restart, can be performed using + svcadm(1M). The service's status can be queried using the + svcs(1) command. + + In the current release of the Solaris operating system, IP + Filter startup configuration files are stored in /etc/ipf. --- /tmp/ipf1m.orig Thu Oct 2 17:27:25 2008 +++ ipf.1m Thu Oct 2 17:30:37 2008 @@ -46,7 +46,8 @@ ment rights profile (see rbac(5)) or become superuser. - 2. Create a packet filtering rule set. See ipf(4). + 2. Configure system and services' firewall policies. + See svc.ipfd(1M) and ipf(4). 3. (Optional) Create a network address translation (NAT) configuration file. See ipnat.conf(4). @@ -84,35 +85,38 @@ - To re-enable packet filtering after it has been temporarily - disabled either reboot the machine or perform the following - series of commands: + disabled either reboot the machine or run the following + command: - 1. Enable Solaris IP Filter: + # svcadm enable network/ipfilter - # ipf -E + which essentially executes the following ipf commands: + 1. Enable Solaris IP Filter: + # ipf -E - # ipf -E + which essentially executes the following ipf commands: + 1. Enable Solaris IP Filter: + # ipf -E - 2. Activate packet filtering: + 2. Load ippools: - # ipf -f + # ippool -f + See ippool(1M) + 3. Activate packet filtering: - 3. (Optional) Activate NAT: + # ipf -f - ipnat -f + 4. (Optional) Activate NAT: + # ipnat -f - See ipnat(1M). + See ipnat(1M). Note - - If you reboot your system, the packet filtering rules in - the /etc/ipf/ipf.conf file and the /etc/ipf/ipnat.conf - file are activated. + If you reboot your system, the IPfilter configuration is + automatically activated. --Boundary_(ID_x6gCGbiIa+tpTOSxwJeHtg) Content-type: text/plain; name=ipf.1m Content-transfer-encoding: 7BIT Content-disposition: inline; filename=ipf.1m System Administration Commands ipf(1M) NAME ipf - alter packet filtering lists for IP packet input and output SYNOPSIS ipf [-6AdDEInoPRrsvVyzZ] [-l block | pass | nomatch] [-T optionlist] [-F i | o | a | s | S] -f filename [-f filename...] DESCRIPTION The ipf utility is part of a suite of commands associated with the Solaris IP Filter feature. See ipfilter(5). The ipf utility opens the filenames listed (treating a hyphen (-) as stdin) and parses the file for a set of rules which are to be added or removed from the packet filter rule set. If there are no parsing problems, each rule processed by ipf is added to the kernel's internal lists. Rules are added to the end of the internal lists, matching the order in which they appear when given to ipf. ipf's use is restricted through access to /dev/ipauth, /dev/ipl, and /dev/ipstate. The default permissions of these files require ipf to be run as root for all operations. Enabling Solaris IP Filter Feature Solaris IP Filter is installed with the Solaris operating system. However, packet filtering is not enabled by default. Use the following procedure to activate the Solaris IP Filter feature. 1. Assume a role that includes the IP Filter Manage- ment rights profile (see rbac(5)) or become superuser. 2. Configure system and services' firewall policies. See svc.ipfd(1M) and ipf(4). 3. (Optional) Create a network address translation (NAT) configuration file. See ipnat.conf(4). 4. (Optional) Create an address pool configuration file. See ippool(4). Create an ipool.conf file if you want to refer to a group of addresses as a single address pool. If you want the address pool configuration file to be SunOS 5.11 Last change: 3 Apr 2008 1 System Administration Commands ipf(1M) loaded at boot time, create a file called /etc/ipf/ippool.conf in which to put the address pool. If you do not want the address pool confi- guration file to be loaded at boot time, put the ippool.conf file in a location other than /etc/ipf and manually activate the rules. 5. Enable Solaris IP Filter, as follows: # svcadm enable network/ipfilter To re-enable packet filtering after it has been temporarily disabled either reboot the machine or run the following command: # svcadm enable network/ipfilter which essentially executes the following ipf commands: 1. Enable Solaris IP Filter: # ipf -E 2. Load ippools: # ippool -f See ippool(1M) 3. Activate packet filtering: # ipf -f 4. (Optional) Activate NAT: # ipnat -f See ipnat(1M). Note - If you reboot your system, the IPfilter configuration is automatically activated. OPTIONS The following options are supported: -6 This option is required to parse IPv6 rules and to have them loaded. Loading of IPv6 rules is subject to change in the future. SunOS 5.11 Last change: 3 Apr 2008 2 System Administration Commands ipf(1M) -A Set the list to make changes to the active list (default). -d Turn debug mode on. Causes a hex dump of filter rules to be generated as it processes each one. -D Disable the filter (if enabled). Not effective for load- able kernel versions. -E Enable the filter (if disabled). Not effective for load- able kernel versions. -F i | o | a Specifies which filter list to flush. The parameter should either be i (input), o (output) or a (remove all filter rules). Either a single letter or an entire word starting with the appropriate letter can be used. This option can be before or after any other, with the order on the command line determining that used to execute options. -F s | S To flush entries from the state table, use the -F option in conjuction with either s (removes state information about any non-fully established connections) or S (deletes the entire state table). You can specify only one of these two options. A fully established connection will show up in ipfstat -s output as 4/4, with devia- tions either way indicating the connection is not fully established. -f filename Specifies which files ipf should use to get input from for modifying the packet filter rule lists. -I Set the list to make changes to the inactive list. SunOS 5.11 Last change: 3 Apr 2008 3 System Administration Commands ipf(1M) -l pass | block | nomatch Toggles default logging of packets. Valid arguments to this option are pass, block and nomatch. When an option is set, any packet which exits filtering and matches the set category is logged. This is most useful for causing all packets that do not match any of the loaded rules to be logged. -n Prevents ipf from making any ioctl calls or doing any- thing which would alter the currently running kernel. -o Force rules by default to be added/deleted to/from the output list, rather than the (default) input list. -P Add rules as temporary entries in the authentication rule table. -R Disable both IP address-to-hostname resolution and port number-to-service name resolution. -r Remove matching filter rules rather than add them to the internal lists. -s Swap the currently active filter list to be an alterna- tive list. -T optionlist Allows run-time changing of IPFilter kernel variables. To allow for changing, some variables require IPFilter to be in a disabled state (-D), others do not. The optionlist parameter is a comma-separated list of tuning commands. A tuning command is one of the following: list Retrieve a list of all variables in the kernel, SunOS 5.11 Last change: 3 Apr 2008 4 System Administration Commands ipf(1M) their maximum, minimum, and current value. single variable name Retrieve its current value. variable name with a following assignment To set a new value. Examples follow: # Print out all IPFilter kernel tunable parameters ipf -T list # Display the current TCP idle timeout and then set it to 3600 ipf -D -T fr_tcpidletimeout,fr_tcpidletimeout=3600 -E # Display current values for fr_pass and fr_chksrc, then set # fr_chksrc to 1. ipf -T fr_pass,fr_chksrc,fr_chksrc=1 -v Turn verbose mode on. Displays information relating to rule processing. -V Show version information. This will display the version information compiled into the ipf binary and retrieve it from the kernel code (if running or present). If it is present in the kernel, information about its current state will be displayed; for example, whether logging is active, default filtering, and so forth). -y Manually resync the in-kernel interface list maintained by IP Filter with the current interface status list. -z For each rule in the input file, reset the statistics for it to zero and display the statistics prior to them being zeroed. SunOS 5.11 Last change: 3 Apr 2008 5 System Administration Commands ipf(1M) -Z Zero global statistics held in the kernel for filtering only. This does not affect fragment or state statistics. FILES /dev/ipauth /dev/ipl /dev/ipstate Links to IP Filter pseudo devices. /etc/ipf/ipf.conf Location of ipf startup configuration file. See ipf(4). /usr/share/ipfilter/examples/ Contains numerous IP Filter examples. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRI- BUTE TYPEATTRIBUTE VALUE _ AvailabilitySUNWipfu _ Interface StabilityCommitted SEE ALSO ipfstat(1M), ipmon(1M), ipnat(1M), svcadm(1M), ipf(4), ipnat.conf(4), ippool(4), attributes(5), ipfilter(5) DIAGNOSTICS Needs to be run as root for the packet filtering lists to actually be affected inside the kernel. SunOS 5.11 Last change: 3 Apr 2008 6 --Boundary_(ID_x6gCGbiIa+tpTOSxwJeHtg) Content-type: text/plain; name=ipfilter.5 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=ipfilter.5 NAME ipfilter - IP packet filtering software DESCRIPTION IP Filter is software that provides packet filtering capa- bilities on a Solaris system. On a properly setup system, it can be used to build a firewall. Solaris IP Filter is installed with the Solaris operating system. However, packet filtering is not enabled by default. See ipf(1M) for a procedure to enable and activate the IP Filter feature. HOST-BASED FIREWALL To simplify IPfilter configuration management, a firewall framework is created to allow users to configure IPfilter by expressing firewall policy at system and service level. Given the user defined firewall policy, the framework generates a set of IPfilter rules to enforce the desired system behavior. Users specify system and service firewall policies that allow or deny network traffic from certain hosts, subnets, and interface(s). The policies are translated into a set of active ipf rules to enforce the specified firewall policies. Note - Users can still specify their own ipf rule file if they choose not to take advantage of the framework. See svc.ipf(1M) and ipf(4). Model This section describes the host-based firewall framework. See svc.ipfd(1M) for details on how to configure firewall policies. A three layer approach with different precedence levels helps us achieve the desired behaviors. Global Default - default system-wide firewall policy. This policy is automatically inherited by all services unless services modify their firewall policy. Network Services - higher precedence than Global Default. A service's policy allows/disallows traffic to its specific ports, regardless of Global Default policy. Global Override - another system-wide policy that takes precedence over the needs of specific services in Network Services layer. Global Override | | Network Services | | Global Default A firewall policy includes a firewall mode and an optional set of network sources. Network sources are IP addresses, subnets, and local network interfaces, from which a system can receive incoming traffic. The basic set of firewall modes are: None - no firewall, allow all incoming traffic Deny - allow all incoming traffic but deny from specified source(s). Allow - deny all incoming traffic but allow from specified source(s) Layers in Detail The first system-wide layer, Global Default, defines a firewall policy that applies to *any* incoming traffic, e.g. allowing or blocking all traffic from an IP address. This makes it simple to have a policy that blocks all incoming traffic or all incoming traffic from unwanted source(s). The Network Services layer contains firewall policies for local programs that provide service to remote clients, e.g. telnetd, sshd, and httpd. Each of these programs, a network service, has its own firewall policy that controls access to its service. Initially, a service's policy is set to inherit Global Default policy, a "Use Global Default" mode. This makes it simple to set a single policy, at the Global Default layer, that can be inherited by all services. When a service's policy is different from Global Default policy, the service's policy has higher precedence. If Global Default policy is set to block all traffic from a subnet, the SSH service could be configured to allow access from certain hosts in that subnet. The set of all policies for all network services comprises the Network Service layer. The second sytem-wide layer, Global Override, has a firewall policy that also applies to any incoming network traffic. This policy has highest precedence and overrides policies in the other layers, specifically overriding the needs of network services. The example is when it's desirable block known malicious source(s) regardless of services' policies. User Interaction This framework leverages IPfilter functionality and is active only when svc:/network/ipfilter is enabled and inactive when network/ipfilter is disabled. Similarly, a network service's firewall policy is only active when that service is enabled and inactive when the service is disabled. A system with an active firewall has IPfilter rules for each running/enabled network service and system-wide policy(s) whose firewall mode isn't "None." User configures firewall by setting the system-wide policies and policy for each network service. See svc.ipfd(1M) on how to configure a firewall policy. The firewall framework composes of policy configuration and a mechanism to generate ipfilter rules from the policy and applying those rules to get the desired IPfilter configuration. A quick summary of the design and user interaction: - system-wide policy(s) are stored in network/ipfilter - network services' policies are stored in each SMF service - user activates firewall by enabling network/ipfilter, see ipf(1M) - user activates/deactivate a service's firewall by enabling/disabling that network service - changes to system-wide or per-service firewall policy results in an update to the system's firewall rules ATTRIBUTES See attributes(5) for a description of the following attri- butes: tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRI- BUTE TYPEATTRIBUTE VALUE _ Interface StabilityCommitted SEE ALSO ipf(1M), ipnat(1M), ipf(4), ipnat(4), attributes(5) NOTES The nfsd service is managed by the service management facil- ity, smf(5), under the service identifier: svc:/network/ipfilter:default. Administrative actions on this service, such as enabling, disabling, or requesting restart, can be performed using svcadm(1M). The service's status can be queried using the svcs(1) command. In the current release of the Solaris operating system, IP Filter startup configuration files are stored in /etc/ipf. --Boundary_(ID_x6gCGbiIa+tpTOSxwJeHtg) Content-type: text/plain; name=svc.ipfd.1m Content-transfer-encoding: 7BIT Content-disposition: inline; filename=svc.ipfd.1m System Administration Commands svc.ipfd(1M) NAME svc.ipfd - IPfilter firewall monitoring daemon SYNOPSIS /lib/svc/bin/svc.ipfd svc:/network/ipfilter:default DESCRIPTION svc.ipfd monitors actions to services with firewall configuration and initiates update services' IPfilter configuration. The daemon allows us to react to changes in system's firewall configuration in an incremental fashion, at per service level. A service's firewall policy is activated when it's enabled, deactivated when it's disabled, and updated when its configuration property group is modified. svc.ipfd monitors SMF repository for these actions and invokes IPfilter rule generation process to carry out the service's firewall policy. Environment Variables and Context This daemon is started by the network/ipfilter service either through the start or refresh method. Thus, the daemon inherits the environment variables and credentials from the method and runs as root with all zone privileges. FIREWALL STATIC CONFIGURATION Static definition describing service's network resource configuration that is used to generate service specific ipf rules. A new per service "firewall_context" property group contains a service's static definition, similar to "inetd" property group in inetd managed services. - firewall_context/name, IANA name or RPC name for non-inetd service, equivalent to inetd/name property - firewall_context/isrpc, a boolean property where a "true" value indicates an RPC service, equivalent to inetd/isrpc property. For RPC services, the value of firewall_context/name is not an IANA name but is either an RPC program number or name, see rpc(4). Additionally, some services may require a mechanism to generate and supply their own ipf rules. An optional property ipf_method, provides a mechanism to allow custom rule generation. - firewall_context/ipf_method, a command, normally a script that generates ipf rules for a service. The framework does not generate rules for services with this property definition but expect these services to provide their own rules. A service's ipf_method specifies a command that takes an additional argument, its own fmri and generates the service's firewall rules and output the rules to stdout. To generate rules for a service with ipf_method property, the framework execs the command specified in ipf_method, passing the service fmri as the additional argument and stores the rules for that service by redirecting the command output, the rules, to the service's rule file. Because an ipf_method is exec'ed from the context of either network/ipfilter start or refresh method process, it inherits the execution context and runs as root. Administrative Privilege The service static configuration, is delivered by service developer and and not intended to be modified by users. These properties are only modified upon installation of an updated service definition. FIREWALL POLICY CONFIGURATION A per service property group, firewall_config, stores the services' firewall policy configuration. Since network/ipfilter:default is responsible for two firewall policies, Global Default and Global Override system-wide policies as explained in ipfilter(5), it has two property groups, firewall_config_default and firewall_config_override, to store the respective sytem-wide policies. Below are the properties, their possible values and correspoding semantics: policy "none" policy mode - no access restriction. For a global policy, this mode allows all incoming traffic. For a service policy, this mode allows all incoming traffic to its service. "deny" policy mode: more restrictive than "none". This mode allows incoming traffic from all sources except those specified in the "apply_to" property. "allow" policy mode: most restrictive mode. This mode blocks incoming traffic from all sources except those specified in the "apply_to" property. apply_to A multi-value property listing network entities to enforce the chosen policy mode. Entities listed in apply_to property will be denied if policy is "deny" and allowed if policy is "allow". The syntax for possible values are: host: host:IP "host:192.168.84.14" subnet: network:IP/netmask "network:129.168.1.5/24" ippool: pool:pool number "pool:77" interface: if:interface_name "if:e1000g0" exceptions A multi-value property listing network entities to be excluded from the "apply_to" list. For example, when deny policy is applied to a subnet, exceptions can be made to some hosts in that subnet by specifying them in the "exceptions" property. This property has the same value syntax as "apply_to" property. For individual network services only: firewall_config/policy A service's policy can also be set to "use_global". Services with "use_global" policy mode inherits the Global Default firewall policy. For the Global Default only: firewall_config_default/policy - can also be set to "custom" Global Default policy, firewall_config property group in svc:/network/ipfilter:default, can also be set to "custom". Users can set policy to "custom" to use prepopulated IPfilter configuration, e.g. existing IPfilter configuration or custom configurations that can't be provided by the framework. This Global Default only policy mode allows users to supply a text file containing the complete set of ipf rules. When "custom" mode is selected, the specified set of ipf rules is *complete* and the framework will not generate ipf rules from configured firewall policies. firewall_config_default/custom_policy_file A file path to be used when Global Default policy is set to "custom". The file contains a set of ipf rules which provide the desired IPfiler configuration. For example, users with existing ipf rules in /etc/ipf/ipf.conf can excute the following commands to use the existing rules: 1. Set custom policy #svccfg -s ipfilter:default setprop \ firewall_config_default/policy = astring: "custom" 2. Specify custom file #svccfg -s ipfilter:default setprop \ firewall_config_default/custom_policy_file = astring: \ "/etc/ipf/ipf.conf" 3. Refresh configuration #svcadm refresh ipfilter:default firewall_config_default/open_ports Non-service program requiring allowance of its incoming traffic can request the firewall to allow traffic to its communication ports. This multi-value property property contains protocol and port(s) tuple in the form "{tcp | udp}:{PORT | PORT-PORT}" Initially, the system-wide policies are set to "none" and network services' policies are set to "use_global". Enabling network/ipfilter activates the firewall with an empty set of ipfilter rules, since system-wide policy is "none" and all services inherit that policy. To configure a more restrictive policy, use svccfg(1M) to modify network services and system-wide policies. Administrative Privilege User configures firewall policy by modifying the service's firewall_config property group. A new authorization "solaris.smf.value.firewall.config" is created to allow delgation of firewall administration privilege to users. The Service Operator users will need this new authorization to be able to configuration firewall policy. DEVELOPER DOCUMENTATION Services providing remote capabilities are encouraged to participate in the firewall framework to control network access to the service. While framework integration isn't mandatory, remote access to services that are not integrated in the framework may not function correctly when a system-wide policy is configured. Integrating a service into the framework is as straightforward as defining two additional property groups and their corresponding properties in the service manifest. IPfilter rules are generated when user enables the service. In the non-trivial case of custom rule generation where a shell script is required, there are existing scripts that can be used as examples. The additional property groups, firewall_config and firewall_context store firewall policy configuration and provides static firewall definition, respectively. Below is a summary of new property groups and properties and their appropriate default values. Firewall policy configuration: firewall_config See FIREWALL POLICY CONFIGURATION section for more information. Access to is protected by a new authorization definition and a user-defined property type. The new authorization should be assigned to the property group value_authorization property such as Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_configuration" as the property type. firewall_config/policy This property's initial value should be "use_global" since services, by default, inherit the Global Default firewall policy. firewall_config/apply_to An empty property, this property has no initial value. firewall_config/exceptions An empty property, this property has no initial value. Firewall static definition: firewall_context See FIREWALL STATIC CONFIGURATION section for more information. Third party should follow service symbol namespace convention to generate a user-defined type, Sun delivered services can use "com.sun,fw_definition" as the property type. firewall_context/name Service with well-known, IANA defined port which can be obtained by getservbyname(3SOCKET), the service's IANA name is stored in this property. For RPC services, the RPC program number is stored in this property. firewall_context/isrpc For RPC services, this property should be created with its value set to "true" firewall_context/ipf_method In general, the specified firewall policy is used to generate IPfilter rules to the service's communication port, derived from firewall_context/name property. Services which don't have IANA defined ports and are not RPC services, will need to generate their own IPfilter rules. Services that generate their own rules may choose not to have firewall_context/name and firewall_context/isrpc properties. See the following services svc:/network/ftp:default svc:/network/nfs/server:default svc:/network/ntp:default and others with existing ipf_method for guidance. ATTRIBUTES See attributes(5) for descriptions of the following attributes: System Administration Commands svc.ipfd(1M) ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu SUNWipfr | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO ipfilter(5), ipf(4), rpc(4), svcs(1), svcprop(1), svcadm(1M), svccfg(1M), attributes(5), smf(5) --Boundary_(ID_x6gCGbiIa+tpTOSxwJeHtg)-- From Darren.Reed@sun.com Sat Oct 4 17:42:03 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m950g3OR008056 for ; Sat, 4 Oct 2008 17:42:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m950g28p006533 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 4 Oct 2008 17:42:03 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8800605PY3NA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 04 Oct 2008 17:42:03 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K88003T0PXXU600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 04 Oct 2008 17:42:02 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m950funj002475 for ; Sun, 05 Oct 2008 00:41:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8800H01PR19600@fe-emea-09.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 05 Oct 2008 01:41:55 +0100 (BST) Received: from [129.146.106.55] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8800DKXPXTQJ00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 05 Oct 2008 01:41:55 +0100 (BST) Date: Sat, 04 Oct 2008 17:46:14 -0700 From: Darren Reed Subject: Re: Solaris host-based firewall [PSARC/2008/580 FastTrack] - updated manpages In-reply-to: <48E56CBA.8090503@sun.com> Sender: Darren.Reed@sun.com To: Tony Nguyen Cc: John Plocher , PSARC-ext@sun.com Message-id: <48E80E56.8090704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DA1309.9060408@Sun.COM> <20080924185200.GB9765@Sun.COM> <48DB9C51.9010407@Sun.COM> <20080926163550.GP9765@Sun.COM> <48DD280E.7060304@sun.com> <48E2A914.7090003@Sun.COM> <48E51523.7080609@sun.com> <48E526E3.8060007@sun.com> <48E5368E.9050705@sun.com> <48E540DA.6080107@sun.com> <48E543B4.60802@Sun.Com> <48E56CBA.8090503@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 99 With no further comments, I'm marking this case approved as the timer expired yesterday. Darren