Gary Winiger wrote: > Alan, > > > Gary Winiger wrote: > > > There has been a lot of discussion within the ndmp team to reach > > consensus on the RBAC configuration for the NDMP service. > > Please see the attached document for an updated ndmp_rbac.txt, > > which I believe will resolve the questions asked earlier. > > Thanks for your careful response. Things are getting clearer. > > > > * 20 Questions states that ndmpd can be started manually > > > from a shell. Why should this be? Isn't it an SMF service? > > > What's wrong with svcadm enable svc:/system/ndmpd ? > > > > When the NDMP service is managed via SMF, it will support both > > backup and restore operations but the team believes that there > > is a benefit in providing profiles to allow sites to assign > > backup or restore roles separately to users, with provision > > to allow those users to manage (start, stop etc) the service. > > The attached document provides definitions and an example. > > Hummm, I agree that "operators" should be able to backup, > but not necessarially restore, while "system admins" should > be able to do both. Rather than the existing proposal which > mixes together SMF and pfexec, consider a purely SMF proposal. > Have different service instances.
This was the approach originally being pursued but we ran into some limitations of the SMF implementation and changed tack. IIRC, the challenge was how to enforce that SMF would only allow one instance (of the three defined) to run at any time. We assumed that this was the purpose of the single instance flag but it didn't appear to work the way we anticipated. > One for backup and restore > and one for backup only. Or maybe one for backup, one for > restore and one that does both. Their enabling/disabling > could be completely authorization driven. > solaris.smf.manage.ndmp (for both), solaris.smf.manage.ndmp.backup > (for only backup), and if a separate restore makes sense, > solaris.smf.manage.ndmp.restore. > Note that authorizations are hierarical so manage.ndmp includes > backup and restore (above ;-). As there is no explicit requirement for separate backup/restore roles at this time, I am going to defer this feature. We will deliver a single service that supports backup and restore using the pure SMF implementation suggested. > > > * 20 Questions 10 implies full audit is being done. Section 4.6 > > > seems to describe the Audit being done. There is no mention > > > of audit for access decisions, though I posted more than > > > one suggestion about it. > > > > > > * ndmp_design section 4.1 says this project exports Audit > > > as committed. I'm confused. The Solaris Audit API > > > is define in PSARC/2000/517 and is Contracted Project Private > > > PSARC/2003/397 discusses why. > > > > Unfortunately, there was a misunderstanding within the NDMP team > > with respect to that question. > > OK. > > > The NDMP project is a port of an existing code base that had no > > audit requirements or support. When ndmpd is running, any audit > > capability available from the VFS, file system, SCSI layer or SMF > > will be available but no audit reporting is currently provided > > by the ndmpd daemon. > > This isn't really the audit I meant. I don't expect system > services to be audited themselves. I expect them to audit > the requests made to them; particularly when the do authentication > and make access control decisions. > See the Audit Policy, which dispite the status on os.o has indeed > moved past draft and has even been updated to clarify some things. > John continues to say os.o will be updated. > http://opensolaris.org/os/community/arc/policies/audit-policy/ > > > There are dependencies on NDMP availabability, which understandably > > are not considerations for PSARC. > > I don't understand what is being driven at here and how it may > or may not relate to audit. > > > The team requests that auditing > > be a follow-on project, in the interest of not impacting dependent > > projects. > > Again I can't see why there should be any impact. Adding audit > is straight forward and IMO, seems to be required for this project, > by the policy. It further seems odd that site administrators wouldn't > be interested in what ndmp actions were made. > I'm happy to work with the project team to define the events and > supply sample code. Would it suffice to audit authentication events and backup/restore job initiation and completion? Suggestions for other events that you think should be audited are welcome. > > > * 20 Questions 10 implies Users are authenticated (an auditable > > > event) with encrypted password. From other discussions it > > > seems that CRAM-MD5 with a plaintext shared secret is used. > > > How is this aligned? > > > > > > * From other discussions about read protected properties and > > > the 2007/177 draft opinion and Solaris stored password policy, > > > how is the contents of ndmp_auth_passwd protected beyond > > > DAC? Or why is DAC an adequate policy? > > > > NDMP passwords were discussed in another email thread that resulted > > in the following summary. > > I'd really like Bill (as 177 case owner) to speak up here. > > > NDMP RBAC Configuration > > > 2. NDMP Service Management > > > > NDMP service management includes those activities that change the state of the > > service such as starting, stopping or refreshing the daemon. The following > > authorizations will permit a user to manage the NDMP service: > ^^^^^^ > > > > solaris.smf.manage.ndmp > > solaris.smf.value.ndmp > ^^^^^^^^^^^^^^^^^^^^^^ > Maybe at the code review level, but why is value necessary to > manage? ABICT, the right thing is: > <property_group name='general' type='framework'> > <!-- to start stop ndmp --> > <propval name='action_authorization' type='astring' > value='solaris.smf.manage.ndmp' /> > <propval name='value_authorization' type='astring' > value='solaris.smf.manage.ndmp' /> > </property_group> > > Checkout the updated SMF Policy -- when John finally pushes it to > os.o ;-( > I'm happy to make the updated Audit and SMF Policies available to > the project team if they can't find them by themselves. > From that updated policy: > <property_group name='general' type='framework'> > <propval name='action_authorization' type='astring' > value='solaris.smf.manage.myservice' /> > <!-- > If the authorization is intended to cover permanent > enable/disable as well as temporary, add the following > --> > <propval name='value_authorization' type='astring' > value='solaris.smf.manage.myservice' /> > </property_group> > > > 4. NDMP RBAC Profiles > > This can all be tuned up to just use SMF instead of CLI invocation. > > > can perform restore operations. > > > > NDMP Backup:::Backup files using NDMP:profiles=NDMP Management; > > help=RtNdmpBackup.html > > > > NDMP Restore:::Restore files using NDMP:profiles=NDMP Management; > > help=RtNdmpRestore.html > > > NDMP Management:::Manage the NDMP service:auths=solaris.smf.manage.ndmp, > > solaris.smf.value.ndmp,solaris.smf.read.ndmp:help=RtNdmpManage. > > > The "System Administrator" profile will be updated to include the NDMP Backup > > and NDMP Restore profiles. > > It would be more appropriate to add NDMP Backup to the existing > Media Backup Rights Profile and NDMP Restore to the existing > Media Restore Rights Profile. Then they will automatically be > bundled with the existing policy of Operator and System Administrator. > > > 5. NDMP Service Execution Attributes > > > > The NDMP service supports the following three commands: > > - ndmpd(1): the NDMP service daemon > > - ndmpadm(1M): the NDMP service administration interface > > - ndmpstat(1M): the NDMP statistics reporting tools > > > > > > 5.1. NDMP Service Daemon > > This can be done away with if a pure SMF approach is taken. > Or maybe "This should be done away with and a pure SMF approach > taken." > > > The "solaris.smf.read.ndmp" authorization will permit the root user access to the > > NDMP admin username and password protected properties. > > Good point. I'd not thought of that relative to read properties. > > > The daemon will surrender > > privileges unnecessary for NDMP runtime operation after process startup, for > > example, PRIV_PROC_EXEC, PRIV_PROC_FORK, PRIV_PROC_SETID and PRIV_PROC_OWNER. > > Thanks. > > > 5.2. NDMP Service Administration > > > NDMP administration is supported via ndmpadm(1M), which does not require any > > privileges. The following entry will be added to the exec_attr(4) file: > > > > NDMP Management:cmd:solaris::/usr/sbin/ndmpadm:privs=none > > This isn't needed at all. It just says to run ndmpadm as the > user, but with even less privileges. As this is all authorization > driven through SMF, no exec_attr entry is needed. > > Is there some where in the RBAC stuff that I could update to > make this clear to project teams? One of the team read somewhere (but can't remember where) that a user without any profile and associated exec_attr entries would be unable to execute any commands. Sorry, no-one remembers the reference. Assuming that, by default, users get 'All' as their least significant profile, which lets them run any command under their own uid/gid with no special privileges, that's fine for ndmpadm. If a user doesn't have the appropriate SMF authorization, the command will not allow that user to set property values or read protected values. We will remove the exec_attr entries for both ndmpadm and ndmpstat. Also, the value_authorization in the general/framework property group should be solaris.smf.manage.ndmp (rather than solaris.smf.value.ndmp). An updated version of ndmp_rbac.txt will follow once we hav everything mentioned here addressed. Alan > > 5.3. NDMP Statistics Reporting > > > NDMP statistical reporting is provided by ndmpstat(1M), which does not require > > any privileges. The following entry will be added to the exec_attr(4) file: > > > > NDMP Management:cmd:solaris::/usr/sbin/ndmpstat:privs=none > > Similarly, the project team has said that nothing special is needed. > Kind of like vmstat. So, let's not add this to exec_attr. > > Gary.. >
