From sommerfeld@Sun.COM Thu Apr 5 21:32:35 2007 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 l364WYUr011512 for ; Thu, 5 Apr 2007 21:32:34 -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 l364VVfV026038; Fri, 6 Apr 2007 12:32:00 +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 <0JG20049B79BRV30@nwk-avmta-2.sfbay.sun.com>; Thu, 05 Apr 2007 21:31:59 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JG100I07T15S640@nwk-avmta-2.sfbay.sun.com>; Thu, 05 Apr 2007 16:24:41 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l35NOdEE016856; Thu, 05 Apr 2007 19:24:39 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l35NOdEi007087; Thu, 05 Apr 2007 19:24:39 -0400 (EDT) Date: Thu, 05 Apr 2007 19:24:38 -0400 From: Bill Sommerfeld Subject: 2007/200 Dedicated SMF services for IPsec/IKE To: PSARC-EXT Cc: Mark Fenwick Message-id: <1175815478.6761.10.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 9104 I'm sponsoring this case for Mark Fenwick. Timer expires on 4/12/2007. Release binding is Patch/Micro. Stability levels are largely Uncommitted. It declares Obsolete the interfaces defined by PSARC 2002/551 (which introduced /etc/default/ipsec) by migrating that configuration into SMF properties. Overview: Currently, IPsec and IKE are initialized as part of svc:/network/network-initial. Both the monolithic nature of network-initial and the fact that in.iked isn't restarted on error are generally regarded as a bug. This can be incrementally improved by splitting IPsec initialization out of network-initial. Detailed description: The dis-entanglement of IPsec/IKE from the generic network service allows us the opportunity to improve the integration with SMF by adding: o Greater control of each component with the SMF framework. o Dedicated restarter for in.iked o Syntax checking of configuration files. o Service specific logging, better diagnosability. o Recording of errors and failures within the SMF framework. o Finer grained control of network services. o Compliance with SAC Best Practices for SMF. o Elimination of race conditions between IPsec and system/cryptosvc (see 6266083). This project will deliver dedicated SMF services to manage the components of IPsec in Solaris: o svc:/network/ipsec/ipsecalgs o svc:/network/ipsec/policy o svc:/network/ipsec/manual-keys o svc:/network/ipsec/ike The IPsec/IKE configuration commands are removed from: o svc:/network/network-initial o /lib/svc/method/net-init The new services use existing commands as service methods. These methods will continue to use existing configuration files for the following reasons: o Existing files are well known and documented. o Configuration grammar is very complex o Some configuration data needs to be kept secret (EG: keys) o Existing customers have applications that expect these files to exist. The use of /etc/default/ipsec configuration file has been depreciated, the IPsec related parameters defined in this file have been changed to smf(5) properties. Note: The /etc/default/ipsec file delivered prior to this change contained only comments -- no actual values were defined in the file delivered with Solaris. A customer could make changes here. This case does not remove this file, but in.iked no longer reads its contents. The new services should be administered using the svcadm(1M) command. The enable/disable/refresh/restart subcommands are supported. The properties defined in the manifests can be displayed with svcprop(1M) and changed with svccfg(1M). The following man pages need to be updated to fully describe these changes: in.iked(1M) ipseckey(1M) ipsecconf(1M) ipsecalgs(1M) No attempt has been made to prevent an administrator from using these commands to manipulate IPsec configuration outside of the smf(5) framework, but the man pages do warn of the dangers of doing so. Note that in the case of in.iked(1M) being restarted, either my svcadm(1M) or by svc.startd(1M), there may be some interruption of IPsec protected traffic. This is because some state only exists in memory of the running in.iked(1M) daemon. This behavior has existed since in.iked(1M) was first introduced, fixing this is outside of the scope of this project. A new '-c' flag is added to the ipsecconf(1M) and ipseckey(1M) commands to compliment the same flag that already exists with in.iked(1M). This allows the administrator to check the configuration file for syntax errors before attempting to apply the changes. For better fault diagnosis, the existing commands have been modified to provide more diagnostic output. This is logged to the smf(5) log files defined by the services properties. The in.iked(1M) daemon forks after reading its initial configuration. Any errors before the fork are recorded in the smf(5) log file, any errors after the fork are recorded in in.iked's own log file. Before these changes, the default error log level for in.iked(1M) was "none". This has been changed to "op", this value is defined as a property of the ike service. The "op" debug level is lightweight, it records operational events such start/stop and the re-reading of a configuration file. Acceptable values for config/debug_level are documented in the ikeadm(1M) man page. Note that this value is used by in.iked(1M) on startup, it can be changed while the daemon is running using ikeadm(1M), this functionality already existed. Draft man page diffs are in the "materials/man_pages" subdirectory of the case. Draft manifests are in the "materials/manifests" subdirectory of the case. Security: The 'ike' and 'manual-key' services described here are delivered disabled, because the configuration files required to use these services do not exist when Solaris is installed. The correct adminstrative proceedure for these services is: o Create IPsec related configuration files. o Enable services with svcadm(1M) Failure to create a valid configuration file before enabling the service will cause the service to transition to maintenance mode. The 'policy' service described here does not provide additional network access or decrease host security when enabled, even when unconfigured. When a valid configuration has been defined, disabling this service may reduce system security because the policy can protect the system by droping unprotected network traffic. For this reason the 'policy' service is delivered enabled. This change delivers /etc/inet/ipsecinit.conf which defines a policy which does not enforce IPsec protection. The 'ipsecalgs' service synchronizes a list of known algorithms with the IPsec kernel modules. This service does not provide any additional network access. The 'policy' service and any customer applications that use Per-Socket Policy depend on IPsec modules being configured at system restart. For these reasons, the 'ipsecalgs' service is delivered enabled. When correctly configured, the IPsec smf(5) services increase system security by preventing unauthorized system access and providing protection for network traffic. Disabling these services could reduce system security, for this reason the IPsec smf(5) services are not included in any of the netservices(1M) profiles. In keeping with Sun's RBAC policy, this project introduces the following authorizations: A new RBAC profile 'Network IPsec Management' has been created and includes these authorizations. The existing 'Network Security' profile has been modified to include 'Network IPsec Management'. Upgrade: Changes to bfu and SUNWcsr/[pre,post]install ensure that a system that already has a valid IPsec configuration will have the new services enabled on first reboot. If the system that is upgraded does not have the /etc/inet/ipsecinit.conf file, this file will be created. The policy defined here will not change the behaviour of the system. This is achieved using a "Project Private" mechanism and as such is subject to PSARC contract /shared/sac/PSARC/2002/547/contract-xx (attached); a draft of the contract may be found in the case directory as contract-01. This method is used because there is no public interface to achieve this (see 6510895). Bug/RFE Number(s): 6185380 IPsec should be a separate (set) of smf(5) services 6462741 ipsecconf should have an option to check config file syntax 6467954 ipseckey exit code on failure inconsistent 6497802 in.iked should use smf(5) properties instead of /etc/default/ipsec 6488927 ipseckey(1M) could do a better job of dealing with multiple errors Exported Interfaces: +-----------------------------+-----------------+---------------------+ |Interfaces: | Classification: | Comments: | +-----------------------------+-----------------+---------------------+ svc:/network/ipsec/ipsecalgs Uncommitted IPsec algorithm FMRI svc:/network/ipsec/policy Uncommitted IPsec Policy FMRI svc:/network/ipsec/manual-keys Uncommitted IPsec manual key FMRI svc:/network/ipsec/ike Uncommitted IKE FMRI config/admin_privilege Uncommitted IKE property config/config_file in.iked Uncommitted IKE property config/debug_level Uncommitted IKE property config/debug_logfile Uncommitted IKE property config/ignore_errors Uncommitted IKE property config/config_file Uncommitted Policy property config/config_file Uncommitted Manual Key Property solaris.smf.value.ipsec Uncommitted IPsec authorization solaris.smf.manage.ipsec Uncommitted IPsec authorization Network IPsec Management Uncommitted RBAC Profile /usr/sbin/ipsecconf -c Committed Check flag /usr/sbin/ipseckey -c Committed Check flag /etc/default/ipsec Obsolete From Darren.Moffat@Sun.COM Tue Apr 10 03:06:17 2007 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 l3AA6HOP019114 for ; Tue, 10 Apr 2007 03:06:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3AA5c16029804; Tue, 10 Apr 2007 03:05:38 -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 <0JGA002011DE4500@brm-avmta-1.central.sun.com>; Tue, 10 Apr 2007 04:05:38 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA00B821DC8F50@brm-avmta-1.central.sun.com>; Tue, 10 Apr 2007 04:05:37 -0600 (MDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3AA5a6C013389; Tue, 10 Apr 2007 10:05:36 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGA0070113Y8700@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 10 Apr 2007 11:05:36 +0100 (BST) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGA00FQ21D5GB00@d1-emea-09.sun.com>; Tue, 10 Apr 2007 11:05:35 +0100 (BST) Date: Tue, 10 Apr 2007 11:05:28 +0100 From: Darren J Moffat Subject: Re: 2007/200 Dedicated SMF services for IPsec/IKE In-reply-to: <1175815478.6761.10.camel@thunk> Sender: Darren.Moffat@Sun.COM To: Bill Sommerfeld Cc: PSARC-EXT , Mark Fenwick Message-id: <461B6168.1090404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1175815478.6761.10.camel@thunk> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 1425 What about upgrade and the /etc/default/ipsec file ? Does upgrade migrate any settings found in that file into the SMF properties ? Aside, I find the name of the new RBAC profile a little interesting "Network IPsec" - what other kind of IPsec is there ? More seriously though, the current 'Network Security' RBAC profile has the following IPsec/IKE related entries Network Security:solaris:cmd:::/usr/lib/inet/in.iked:privs=sys_net_config,net_privaddr Network Security:solaris:cmd:::/usr/sbin/ikeadm:privs=sys_net_config Network Security:solaris:cmd:::/usr/sbin/ikecert:privs=sys_net_config Network Security:solaris:cmd:::/usr/sbin/ipsecalgs:privs=sys_net_config Network Security:solaris:cmd:::/usr/sbin/ipsecconf:privs=sys_net_config Network Security:solaris:cmd:::/usr/sbin/ipseckey:privs=sys_net_config Since this case is creating a new IPsec specific RBAC profile it seems to make sense to move these entries into that new profile as part of this case, otherwise it is an incomplete profile. > Disabling these services could reduce system security, for > this reason the IPsec smf(5) services are not included in any of the > netservices(1M) profiles. Shouldn't that mean that they *are* included and explicitly forced to the enabled state ? This is what is done with cryptosvc and GSS which are similar to IPsec in the respect that running without them would reduce system security. -- Darren J Moffat From Mark.Fenwick@Sun.COM Tue Apr 10 08:57:59 2007 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 l3AFvxqP024740 for ; Tue, 10 Apr 2007 08:57: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 l3AFvIap031273; Tue, 10 Apr 2007 09:57: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 <0JGA00H7UHNIDY00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Apr 2007 08:57:18 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.104.45]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA00FDGHNFTX20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Apr 2007 08:57:15 -0700 (PDT) Received: from bassale (punchin-client-192-9-61-254.SFBay.Sun.COM [192.9.61.254]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l3AFvELK260387; Tue, 10 Apr 2007 08:57:15 -0700 (PDT) Date: Tue, 10 Apr 2007 08:55:23 -0700 (PDT) From: Mark Fenwick Subject: Re: 2007/200 Dedicated SMF services for IPsec/IKE In-reply-to: Your message with ID <461B6168.1090404@Sun.COM> To: Darren J Moffat Cc: Bill Sommerfeld , PSARC-EXT , Mark Fenwick Reply-to: Mark Fenwick Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2358 Hi Darren, > What about upgrade and the /etc/default/ipsec file ? Does upgrade > migrate any settings found in that file into the SMF properties ? No it does not, this would be not that hard but I really don't think anybody will have ever used this file and it was never documented as an interface. > > Aside, I find the name of the new RBAC profile a little interesting > "Network IPsec" - what other kind of IPsec is there ? > If you have a better suggestion, please share. The "Network" label was used to make it fit nicely in with the other "Network" profiles in proff_attr. EG: "Network Wifi Management" :-) > More seriously though, the current 'Network Security' RBAC profile has > the following IPsec/IKE related entries > > Network > Security:solaris:cmd:::/usr/lib/inet/in.iked:privs=sys_net_config,net_privaddr > Network Security:solaris:cmd:::/usr/sbin/ikeadm:privs=sys_net_config > Network Security:solaris:cmd:::/usr/sbin/ikecert:privs=sys_net_config > Network Security:solaris:cmd:::/usr/sbin/ipsecalgs:privs=sys_net_config > Network Security:solaris:cmd:::/usr/sbin/ipsecconf:privs=sys_net_config > Network Security:solaris:cmd:::/usr/sbin/ipseckey:privs=sys_net_config > > > Since this case is creating a new IPsec specific RBAC profile it seems > to make sense to move these entries into that new profile as part of > this case, otherwise it is an incomplete profile. > This has been done already, I can send the webrev around if you would like to see it. > > Disabling these services could reduce system security, for > > this reason the IPsec smf(5) services are not included in any of the > > netservices(1M) profiles. > > Shouldn't that mean that they *are* included and explicitly forced to > the enabled state ? This is what is done with cryptosvc and GSS which > are similar to IPsec in the respect that running without them would > reduce system security. We took the decision to enable the service via the manifest. Mark ---------------------------------------------------------------------------- Mark Fenwick, Solaris Security Technologies. TEL: +1 (650) 786 2733 (X82733) __o Sun Microsystems Inc, Menlo Park, California. `\<,_ (*)/ (*) ---------------------------------------------------------------------------- From Darren.Moffat@sun.com Tue Apr 10 09:20:13 2007 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 l3AGKC9b026025 for ; Tue, 10 Apr 2007 09:20: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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3AGJUDL013067; Tue, 10 Apr 2007 17:19:34 +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 <0JGA00F07IOL4G00@brm-avmta-1.central.sun.com>; Tue, 10 Apr 2007 10:19:33 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA00MDWIOKLJC0@brm-avmta-1.central.sun.com>; Tue, 10 Apr 2007 10:19:33 -0600 (MDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3AGJVwo005635; Tue, 10 Apr 2007 16:19:31 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGA00601IN5H700@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 10 Apr 2007 17:19:31 +0100 (BST) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGA00FVQIOGGA10@d1-emea-09.sun.com>; Tue, 10 Apr 2007 17:19:29 +0100 (BST) Date: Tue, 10 Apr 2007 17:19:28 +0100 From: Darren J Moffat Subject: Re: 2007/200 Dedicated SMF services for IPsec/IKE In-reply-to: Sender: Darren.Moffat@sun.com To: Mark Fenwick Cc: Bill Sommerfeld , PSARC-EXT Message-id: <461BB910.4000503@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 2593 Mark Fenwick wrote: > Hi Darren, > >> What about upgrade and the /etc/default/ipsec file ? Does upgrade >> migrate any settings found in that file into the SMF properties ? > > No it does not, this would be not that hard but I really don't think anybody will have ever used this file and it was never documented as an interface. If it really wasn't documented then I don't see any need to migrate. >> Aside, I find the name of the new RBAC profile a little interesting >> "Network IPsec" - what other kind of IPsec is there ? >> > > If you have a better suggestion, please share. The "Network" label was used to > make it fit nicely in with the other "Network" profiles in proff_attr. Just "IPsec Management" :-) > EG: > > "Network Wifi Management" :-) I guess leave it then, it means it groups nicely in the GUI so maybe using the prefix of Network is actually a good best practice, even though the 'Network' is redundant :-) > This has been done already, I can send the webrev around if you would like to see it. I'm not sure what if any precedent we have for a command moving from one RBAC execution profile to another. So I think the case should be explicit about the move. There is no change in behaviour as far as the user who as the top level profile is concerned. There is however a significant change because exec_attr changes and that means the nameservice repositories should change too. It is also important for administrators to know that they can if they wish now not give out WiFi security management if all they want is IPsec management. The case didn't make it clear that people with the just the new profile could run the commands. >>> Disabling these services could reduce system security, for >>> this reason the IPsec smf(5) services are not included in any of the >>> netservices(1M) profiles. >> Shouldn't that mean that they *are* included and explicitly forced to >> the enabled state ? This is what is done with cryptosvc and GSS which >> are similar to IPsec in the respect that running without them would >> reduce system security. > > > We took the decision to enable the service via the manifest. Having it done in the profile rather than the manifest is actually "stronger" and will lead to more cases where it is enabled. For example if someone does the following you get it enabled: # netservices open # svcadm disable ipsec/policy # netservices limited If you enabled only in the manifest that sequence will leave it disabled, which I don't believe is the behaviour you are trying to achieve. -- Darren J Moffat From Mark.Fenwick@sun.com Tue Apr 10 12:13:47 2007 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 l3AJDkU0002649 for ; Tue, 10 Apr 2007 12:13:47 -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 l3AJCpdK028345; Wed, 11 Apr 2007 03:13:07 +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 <0JGA00801QPSMO00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Apr 2007 12:13:04 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.56.144]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA0063AQPSTV20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Apr 2007 12:13:04 -0700 (PDT) Received: from wadworth (wadworth.SFBay.Sun.COM [129.146.108.232]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l3AJD3WJ276942; Tue, 10 Apr 2007 12:13:04 -0700 (PDT) Date: Tue, 10 Apr 2007 12:11:09 -0700 (PDT) From: Mark Fenwick Subject: Re: 2007/200 Dedicated SMF services for IPsec/IKE In-reply-to: Your message with ID <461BB910.4000503@Sun.COM> To: Darren J Moffat Cc: Mark Fenwick , Bill Sommerfeld , PSARC-EXT Reply-to: Mark Fenwick Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1496 > > Having it done in the profile rather than the manifest is actually > "stronger" and will lead to more cases where it is enabled. For example > if someone does the following you get it enabled: > > # netservices open > # svcadm disable ipsec/policy > # netservices limited > > If you enabled only in the manifest that sequence will leave it > disabled, which I don't believe is the behaviour you are trying to achieve. I disagree, this is exactly the behaviour I'm trying to achieve. The reason for delivering ipsec/policy enabled is provide backwards compatability with S10 and older for those customers who choose to enable IPsec policy by delivering a policy file into /etc/inet and rebooting. I know of one OEM who does this, there are probably more. Having the ipsec/policy service enabled only makes your system more secure if the administrator created a valid policy configuration file. The default IPsec policy is "pass all IP traffic unencrypted". In the example above, the administrator made the conscious decision to disable IPsec policy, we should not change this with netservices. Mark ---------------------------------------------------------------------------- Mark Fenwick, Solaris Security Technologies. TEL: +1 (650) 786 2733 (X82733) __o Sun Microsystems Inc, Menlo Park, California. `\<,_ (*)/ (*) ---------------------------------------------------------------------------- From Darren.Moffat@sun.com Tue Apr 10 12:45:34 2007 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 l3AJjXCS003054 for ; Tue, 10 Apr 2007 12:45:34 -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 l3AJikJh007529; Wed, 11 Apr 2007 03:44:54 +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 <0JGA00B1BS6ROK00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Apr 2007 12:44:51 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA0062FS6QTZ30@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Apr 2007 12:44:50 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3AJinq7014615; Tue, 10 Apr 2007 19:44:49 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGA00601S5ZFI00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 10 Apr 2007 20:44:49 +0100 (BST) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGA00F65S6OGB20@d1-emea-09.sun.com>; Tue, 10 Apr 2007 20:44:49 +0100 (BST) Date: Tue, 10 Apr 2007 20:44:48 +0100 From: Darren J Moffat Subject: Re: 2007/200 Dedicated SMF services for IPsec/IKE In-reply-to: Sender: Darren.Moffat@sun.com To: Mark Fenwick Cc: Bill Sommerfeld , PSARC-EXT Message-id: <461BE930.9080001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 916 Mark Fenwick wrote: >> Having it done in the profile rather than the manifest is actually >> "stronger" and will lead to more cases where it is enabled. For example >> if someone does the following you get it enabled: >> >> # netservices open >> # svcadm disable ipsec/policy >> # netservices limited >> >> If you enabled only in the manifest that sequence will leave it >> disabled, which I don't believe is the behaviour you are trying to achieve. > > > I disagree, this is exactly the behaviour I'm trying to achieve. The reason for delivering ipsec/policy enabled is provide backwards compatability with S10 and older for those customers who choose to enable IPsec policy by delivering a policy file into /etc/inet and rebooting. I know of one OEM who does this, there are probably more. Okay if thats the behaviour you want I'm fine with that. I didn't read the proposal that way. -- Darren J Moffat From gww@eng.sun.com Tue Apr 10 19:24:04 2007 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 l3B2O3PH018347 for ; Tue, 10 Apr 2007 19:24:04 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3B2NO99019512; Wed, 11 Apr 2007 03:23:26 +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 <0JGB00L09AMXFI00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Apr 2007 19:23:21 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGB00MA6AMV0JB0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Apr 2007 19:23:20 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3B2NHiY029051; Tue, 10 Apr 2007 19:23:17 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l3B2OFj2022195; Tue, 10 Apr 2007 19:24:15 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l3B2OF6H022194; Tue, 10 Apr 2007 19:24:15 -0700 (PDT) Date: Tue, 10 Apr 2007 19:24:15 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/200 Dedicated SMF services for IPsec/IKE To: Darren.Moffat@sun.com, Mark.Fenwick@sun.com Cc: PSARC-EXT@sun.com, sommerfeld@sun.com Message-id: <200704110224.l3B2OF6H022194@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1243 Mark wrote in reply to Darren: > > Network > > Security:solaris:cmd:::/usr/lib/inet/in.iked:privs=sys_net_config,net_privaddr > > Network Security:solaris:cmd:::/usr/sbin/ikeadm:privs=sys_net_config > > Network Security:solaris:cmd:::/usr/sbin/ikecert:privs=sys_net_config > > Network Security:solaris:cmd:::/usr/sbin/ipsecalgs:privs=sys_net_config > > Network Security:solaris:cmd:::/usr/sbin/ipsecconf:privs=sys_net_config > > Network Security:solaris:cmd:::/usr/sbin/ipseckey:privs=sys_net_config > > > > > > Since this case is creating a new IPsec specific RBAC profile it seems > > to make sense to move these entries into that new profile as part of > > this case, otherwise it is an incomplete profile. > > > > This has been done already, I can send the webrev around if you would like to see it. Perhaps I'm missing what's being said. Because the name service may be serving systems at different patch levels, moving (removing) entries from one profile to another could break existing users of the Network Security profile. Making the Network IPsec Management profile self sufficient is fine, or including it in Network Security would be fine (presuming that's the policy the project team wishes to provide). Gary.. From Darren.Moffat@Sun.COM Wed Apr 11 08:53:17 2007 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 l3BFrGGo015655 for ; Wed, 11 Apr 2007 08:53:17 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3BFqZft008156; Wed, 11 Apr 2007 16:52:38 +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 <0JGC00I0BC3PYG00@brm-avmta-1.central.sun.com>; Wed, 11 Apr 2007 09:52:37 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGC00GFOC3OP410@brm-avmta-1.central.sun.com>; Wed, 11 Apr 2007 09:52:37 -0600 (MDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3BFqZuM020985; Wed, 11 Apr 2007 15:52:35 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGC00901C0MI000@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 11 Apr 2007 16:52:35 +0100 (BST) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGC001PUC3JGM10@d1-emea-09.sun.com>; Wed, 11 Apr 2007 16:52:32 +0100 (BST) Date: Wed, 11 Apr 2007 16:52:31 +0100 From: Darren J Moffat Subject: Re: 2007/200 Dedicated SMF services for IPsec/IKE In-reply-to: <200704110224.l3B2OF6H022194@marduk.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Gary Winiger Cc: Mark.Fenwick@Sun.COM, PSARC-EXT@Sun.COM, sommerfeld@Sun.COM Message-id: <461D043F.3030509@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704110224.l3B2OF6H022194@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 1468 Gary Winiger wrote: > Mark wrote in reply to Darren: > >>> Network >>> Security:solaris:cmd:::/usr/lib/inet/in.iked:privs=sys_net_config,net_privaddr >>> Network Security:solaris:cmd:::/usr/sbin/ikeadm:privs=sys_net_config >>> Network Security:solaris:cmd:::/usr/sbin/ikecert:privs=sys_net_config >>> Network Security:solaris:cmd:::/usr/sbin/ipsecalgs:privs=sys_net_config >>> Network Security:solaris:cmd:::/usr/sbin/ipsecconf:privs=sys_net_config >>> Network Security:solaris:cmd:::/usr/sbin/ipseckey:privs=sys_net_config >>> >>> >>> Since this case is creating a new IPsec specific RBAC profile it seems >>> to make sense to move these entries into that new profile as part of >>> this case, otherwise it is an incomplete profile. >>> >> This has been done already, I can send the webrev around if you would like to see it. > > Perhaps I'm missing what's being said. Because the name service > may be serving systems at different patch levels, moving (removing) > entries from one profile to another could break existing users > of the Network Security profile. Making the Network IPsec Management > profile self sufficient is fine, or including it in Network Security > would be fine (presuming that's the policy the project team wishes > to provide). This case actually implements both of what you suggest. The 'Network IPsec Management' profile becomes self sufficient AND it is included in the 'Network Security' profile. -- Darren J Moffat From sommerfeld@sun.com Wed Apr 11 10:18:37 2007 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 l3BHIawE022227 for ; Wed, 11 Apr 2007 10:18:37 -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 l3BHHsFS014961; Thu, 12 Apr 2007 01:17:58 +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 <0JGC0090DG1W6Q00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Apr 2007 10:17:56 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGC00EWPG1UP1D0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Apr 2007 10:17:55 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3BHHncj029717; Wed, 11 Apr 2007 13:17:49 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3BHHnX6029822; Wed, 11 Apr 2007 13:17:49 -0400 (EDT) Date: Wed, 11 Apr 2007 13:17:48 -0400 From: Bill Sommerfeld Subject: Re: 2007/200 Dedicated SMF services for IPsec/IKE In-reply-to: <1175815478.6761.10.camel@thunk> To: PSARC-EXT Cc: Mark Fenwick Message-id: <1176311868.22952.187.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1175815478.6761.10.camel@thunk> Status: RO Content-Length: 69 This case was approved during today's PSARC meeting. - Bill