IAM
====

Name:           Socket Filter Framework
Submitter:      anders.persson@sun.com
Owner:          Sebastien Roy
Intern:         Suhasini Peddada
Exposure:       open

SUMMARY
=======

        This is a project to implement a socket filter framework, which
        makes it possible for modules to intercept requests and notifications
        passed between the socket and protocol layers. The Solaris SSL kernel
        proxy (PSARC/2005/625) will be converted to use the framework.

ISSUES
=======

 PSARC/2009/590 Socket Filter Framework
 Inception review issues:
 
 DJM-1	What filters will be provided with the initial integration
 
 DJM-2	Will it be possible to build a filter that can easily
 	control all off host networking on a per user basis ?
 	eg any user in a given group or with a given uid can't
 	access the network but can do local socket stuff ?
 
 	In other words can this case provide a solution to 6215035 ?
 
 DJM-3	Even we have exlusive stack networking the fact that
 	filters can only be managed from the global zone seems
 	very surprising to me as someone who doesn't understand
 	the internals of this part of networking.  As such I think
 	this will be very surprising to admins, who I expect will
 	want to be able to provide different filtering per zone.
 
 	Would it be possible for soconfig(1M) to allow specifying
 	which zones the filters apply to ?
 
 DJM-4	Is it possible to give a non global zone sufficient privilege
 	so that it can mange filters ?
 
 DJM-5	What privileges are required to setup a filter programatically ?
 
 DJM-6	What RBAC rights profile will soconfig(1M) be in and what
 	privileges will it run with ?	
 
 ram-1	What is the proposed release binding of this change?
 
 GED-0	As a level 0, I would like to understand why we need a different
 	framework for sockets than we use for other kinds of networking.
 	(I.e. STREAMS).
 
 GED-1	Is it really appropriate that we expose this API to external consumers
 	as Committed?  If its only for KSSL, perhaps we ought to start with
 	a more limited Committment?  At least until we have some experience
 	with it?  Are there other kinds of consumers expected.
 
 kb-01	callback for sof_accept?
 
 kb-02   add FMRI for the SMF service to the interface table.

Commitment review issues:

seb-1   Since inception, 2009/685 was submitted and approved.  The
        approach used by that case to restrict network access is crude
        and has serious limitations.  Could socket filters be extended
        to provide more fine-grained controls (per socket, per user,
        etc.).  There is evidently a related FGAP project (Fine
        Grained Access Policy), perhaps the project team has or can
        investigate the potential intersections...

seb-2   Interface table nit: there is no such thing as an Unstable
        interface.  The old taxonomy had such a concept, but the
        newer equivalent is Uncommitted.

seb-3   Why one service per filter rather than one service instance
        per filter?

VOTE
====
Approve - Seb, Rick, Garrett
Deny - 
Abstain - Glenn
Not Participating (NP) - 


THE NEXT STEP
=============

	Team: Work with Casper Dik with respect to his current project

	Team: Consult with SMF team

	Need opinion: sanity behind split streams/sockets world

	Need opinion: multiple filter frameworks