Gary Winiger wrote: >> Gary Winiger wrote: >> >>>> Summary of the concerns and proposed solutions for the PSARC 2007/414: >>>> >>>> Concern: Does clear text CHAP secret provides enough security? >>>> > > It seems that this project is being factored to bypass this issue. > See the project teams response below. > Is the project complete without a CHAP secret? > No, we need to move all configuration data to SCF including CHAP secrets. > >>> I'm going to leave this one for now to get a feeling of others. >>> >>> >>> >>>> Concern: The iSCSI target manifest does not comply with SMF authorization. >>>> Proposal: >>>> -We will add action_authorization and value_authorization to the >>>> manifest to make >>>> it SMF authorization compliant. >>>> >>>> >>> Good. Is there an updated spec showing this? >>> >> I updated the scf_design doc with a section on "Iscsi Target RBAC >> authorization". >> > > At the code review level, I'm not sure > 2. Iscsitgt service manifest > will do what you want it to do. Please have the SMF folk code > review your service manifest. > Yes, this will require code review from the SMF folk.
Since the original PSARC only address the conversion of configuration to SCF data, the issue of RBAC came up during this PSRAC exchange, I'm requesting to open a P3 CR to address the RBAC issue, this should not affect the security issue with the implementation of PSARC 2007/177, this will speed up the putback of the SCF converson that the FishWorks team is waiting for. > >>> Some how, I've >>> missed the FMRI and man pages documenting it. Shouldn't this >>> turn iscsitadm into being completely authorization driven? ;-) >>> >>> >> No authorization is needed for iscsitadm, the cli sends the request to >> the daemon and >> the daemon verify the user credential. I don't think update to the man >> page is needed. >> > > What daemon would that be? The iscsitgtd daemon performs all scf operations and verify the data are correct, this is the prefer method to update the iscsi target configuration. > svc.configd is in charge of changing > properties and enforcing authorizations for the repository. > Without man page updates, how is the admin going to know > that the user/role must have the Iscsi Target Management Rights > Profile to successfully run iscsitadm? > We can add the RBAC authorization to the iscsitadm(1M) man pages for the RBAC authorization putback. > >>> It would be nice to see the updated man page. >>> >>> >>> >>>> Issues: >>>> -The CHAP secret will be put back after PSARC 2007/177 is putback. >>>> The PSARC 2007/414 will >>>> cover the putback of the CHAP secret at a later time, and no >>>> additional case is needed. >>>> >>>> >>> I'm not sure how to read this. Is this accepting a case dependency >>> on 2007/177? Or is it saying that a two phase project is being >>> requested. Phase 1 without CHAP, phase 2 after 177 with CHAP. >>> >>> >> We are requesting to make this a 2 phase project, and we will provide >> all the documents to >> address both phases. The 2nd phase will accept the 2007/177 dependency. >> > > Is the project complete in phase 1? No. > Is the intent that this > ARC case cover both phases? Yes, the reason for the 2 phases was because of the dependency on PSARC 2007/177. > Why is a phased approach needed or > desirable to the administrator? > It's probably not desirable, but without knowing when 2007/177 will be approve, that how we scheduled the project. -Tim > Gary.. >
