#ident "%W% %E% SAC" PSARC/2008/181 Solaris Hotplug Framework Submitter: Colin Zou Owner: Garrett D'Amore Intern: Phi Tran gw-99 Sorry for the late and parochial issues, but I'm still officially on sabbatical. And I still seem to be the first in the fine. gw-1 How does this play with devkit, device allocation, SunRay? gw-2 This project seems to require administrative audit, yet there is no mention. See the 20 Questions (and Solaris Audit Policy). gw-3 What is the method context for the service? Are there any properties? Is this enabled by the profile? Is there any reason to ever disable it manually? gw-4 Root is not a privilege (nor is uid 0 special) why isn't this authorization driven? Just how are you doing access control? Access control decisions also require audit. gw-5 I'm dubious about the Patch binding. Verify with the Solaris Evaluations and Trusted Extensions project teams that this is appropriate for a Patch. The manager is Craig Payne. gw-6 What would be the meaning of "remote clients". INET sockets should be avoided as they add an attack vector. I'm still dubious about doors being complex. gw-7 What is the compelling reason that RBAC must be postponed? How is the project complete without meeting the Solaris Policies? Is a PAC waver going to be requested? gw-99a userland: RBAC is not authentication, in this case it is authorization based access control. gw-1 How does this play with devkit, device allocation, SunRay? All the above are investigated. They are out of scope of this project and there are no conflicts. Details see following: - devkit: It is being ported to Solaris and is similar as HAL regarding as functionality and interface dependencies. It is a userland utility which is going to depend on libdevinfo and libsysevent. It gets device information from libdevinfo and listens to sysevents for device add/remove events. This project does not break the existing interfaces which devkit will depend on. I've talked to the devkit team and confirmed this. - device allocation: It "manages the ownership of devices". It depends on devfs interfaces. This project implements hotplug controller drivers and framework which are in the kernel device driver level which is under devfs. So it does not impacts device allocation. The userland administer tool introduced by this project is used to issue commands to kernel drivers to hot add/remove devices to/from the "system". It is not related with user ownerships. And the tool will conform to RBAC, so only a user with proper authorizations can issue commands to hotplug devices to/from the system. This prevents the tool from conflicting/breaking device allocation. - SunRay: Sun Ray client is not related. Sun Ray server is a userland application which can run on Solaris and Linux. It manages remote devices on Sun Ray clients including hotplug operations. However, Sun Ray server is an independent userland application which does not interact with Solaris hotplug framework or device drivers. For example, if a usb keyboard is plugged to a Sun Ray client, the Sun Ray server gets the event from network and starts a userland process to deal with the hotplug event. And then a Sun Ray specific userland usb device driver works for the device. Sun Ray support is out of scope of this Solaris project. gw-2 This project seems to require administrative audit, yet there is no mention. See the 20 Questions (and Solaris Audit Policy). In scope. See section 3.1.7 and 3.3.8 of "Userland Components of Solaris Hotplug" document (file: shp-userland.txt). gw-3 What is the method context for the service? Are there any properties? Is this enabled by the profile? Is there any reason to ever disable it manually? In scope. See section 3.3 of "Userland Components of Solaris Hotplug" document (file: shp-userland.txt). gw-4 Root is not a privilege (nor is uid 0 special) why isn't this authorization driven? Just how are you doing access control? Access control decisions also require audit. In scope. See section 3.1.5, 3.2.1, 3.3.1 and 3.3.7 of document "Userland Components of Solaris Hotplug" (file: shp-userland.txt). gw-5 I'm dubious about the Patch binding. Verify with the Solaris Evaluations and Trusted Extensions project teams that this is appropriate for a Patch. The manager is Craig Payne. Hotpug project team got comments from Craig's team for this issue: "The TX implementation of device allocation for hotlug doesn't rely on cfgadm directly. Instead it relies on devfsadm which relies on HAL. I can't find any reference in the project materials to devfsadm. That is the interface we care about since that is where entries get added to the device allocation files. Do devices managed via the new hotplug framework still go through devfsadm processing? If so, then this project seems to be compatible with existing functionality. But it should be required to verify that by testing with Trusted Extensions enabled. " The project team's answer to the above question is: "Yes, they still go through devfsadm processing." So it is understood that this project is OK to co-exist with TX and have a Patch binding. And the project team will do the tests with Trusted Extensions enabled. For reference, the following are more investigation results from hotplug project team on this issue: There are mainly two parts of this project, one is to implement hotplug controller drivers and framework in the kernel device driver level; another is the userland administer tool to issue commands to the kernel drivers to initiate the operation of hot add/remove device to/from the system. All these jobs are not directly related with "Solaris Evaluations and Trusted Extensions project". Our userland administer tool will conform to RBAC, so that only users with proper authorizations can perform the device hotplug operations for a system. Given these, we didn't see any risks that our project would break "Solaris Evaluations and Trusted Extensions project". And, for a reference of the existing stuff, cfgadm(1M) is the existing framework which does the similar functionality. It co-exists with TX for many years. gw-6 What would be the meaning of "remote clients". INET sockets should be avoided as they add an attack vector. I'm still dubious about doors being complex. The project team turns to door in commitment documents. See section 3.3.2 of "Userland Components of Solaris Hotplug" document (file: shp-userland.txt). gw-7 What is the compelling reason that RBAC must be postponed? How is the project complete without meeting the Solaris Policies? Is a PAC waver going to be requested? RBAC will be supported. See section 3.1.5, 3.2.1, 3.3.1 and 3.3.7 of document "Userland Components of Solaris Hotplug" (file: shp-userland.txt). pt-1 Why does the hotplug daemon need to run with all privileges? The existing software stack for DR and hotplugging is based upon cfgadm(1M), libcfgadm plugins, and calls to the RCM framework. The diversity of client scripts and plugins for the RCM framework complicates the issue of trying to determine the exact privileges needed. Different plugins or scripts may need different privileges to function properly. And the RCM scripting API is a public interface. We could not really know exactly what privileges are required by customer scripts in the field. It would be a long term maintenance nightmare to try and specify a minimized set of privileges needed by the RCM daemon to cope with the needs of its client plugins and scripts. (Especially since any customer could write a new RCM script that needs a new privilege we didn't think we needed.) This is the problem as I understand it. It's possible that my understanding of how privileges and authorizations are inherited by fork()'ed processes is incorrect. I am not totally certain about it. Because, you see, there was an effort to investigate and possibly solve this issue, but it was abandoned before all the investigations were completed. An agreement was reached by upper management to defund further enhancements of this nature to the existing software stack. See the 1-pager about the original investigation, and then see section 2.3.2 of the agreement that was eventually reached: http://esp.west/espsw/msw/rm-dr/ProjectStatus/BugCourt/DRCE/docs/lp-1pager.txt http://esp.west/espsw/msw/rm-dr/ProjectStatus/BugCourt/DRCE/docs/DRtransitionplan.pdf I don't think our situation is hopeless here because our architecture is different. The problem with cfgadm as I understand it is that everything depends upon the user who runs a cfgadm command, and the privileges that are then inherited from there by all other parts of the stack. In our architecture we have separate address spaces and inserted a controlled door interface between those address spaces, so that we don't have the same kind of problem about inherited privileges. For example, if a user runs cfgadm(1M), it links a libcfgadm plugin into that same cfgadm(1M) address space. That libcfgadm plugin then calls the librcm interface to communicate with RCM. The librcm library will fork() a new process to run the RCM daemon on demand for each operation. First, librcm checks that the user is running as 'root' before it tries to fork(). Second, if any privileges were dropped before the fork(), I think it would limit what the RCM daemon could then do when it runs. In our architecture, the hotplug(1M) CLI uses libhotplug.so to communicate through a private door interface to the hotplugd(1M) daemon. No privileges are required, except certain RBAC authorizations are required. The CLI and the library perform the RBAC checks before making a door call to the daemon. And the daemon makes the same RBAC checks using the credentials of each incoming door call. The only way to make the hotplugd(1M) daemon do anything is through that controlled door interface, which is protected by RBAC. And then the hotplugd(1M) will only do very specific things in response to those door calls. In some cases, the hotplugd(1M) responds to the door call by doing certain operations that require RCM interactions. But it has full privileges so that the RCM daemon will inherit them and function properly in those cases. So that's why I tried to say we're keeping with the spirit of the principle of least privilege in our architecture. The old model required you to run as root with full privileges in order to do a cfgadm state change operation. Our new model let's you grant a specific RBAC authorization to an ordinary user permitting them to perform hotplug operations, without giving them the full privileges that cfgadm used to require. Commitment issues 07/22/2009 gw-8 What's the requirement for the read authorization? What data is being protected from viewing? After more investigation, no read authorization is required. It has been removed. gw-9 I find the description of where (non-smf) authorizations are being checked confusing: authorizations are to be checked at the point of access control enforcement. Presumably this is in the hotplug service (hotplugd). Where and how is access control being enforced? The daemon is the point of enforcement and is the only place where authorizations are checked. The documents have been updated accordingly. gw-10 I find the description of where (non-smf) Solaris Audit take place confusing: Audit is to take place (with the calling user's Audit context) at the policy enforcement point. Presumably this is in the hotplug service (hotplugd). Audit records are to conform with the Solaris Audit Policy through the use of PSARC/2000/517 Thread-safe audit API and with a conforming contract as noted in PSARC/2003/397 Contracted audit interfaces for open source. Where and how is Audit being done? Auditing will only occur in the daemon. The documents have been updated to clarify this. gw-11 Nit: solaris.smf.manage.hotplug probably should follow the example found in the SMF policy for the general/framework property. The solaris.smf.manage.hotplug is the action_authorization and the value_authorization specified in the SMF service manifest. gw-12 All the interfaces seem to be Consolidation Private. How does this permit management of the authorizations? I'd expect some of the interfaces to be Committed, some to be Project Private and maybe some Consolidation Private. The hotplug(1M) command is now Committed. The rest of the interfaces are either Consolidation Private or Project Private. gw-13 hotplug(1m) Evolving -> Committed? Some mention should be made of the Rights Profile (i.e., interface) required to successfully manage hotpluging. Why are there --long options? Changed hotplug(1M) to Committed, and updated the manpage accordingly. Also included a note about the rights profile. ged-01 In shp-userland.txt, why are you delivering the libhotplug headers. Private headers need not be delivered to end-users. Especially I would not deliver the _impl.h, since its internal use only within ON. Okay, not delivering the header files sounds right. At least not delivering the libhotplug_impl.h. The libhotplug interfaces are all "Consolidation Private" in phase 1, at least. I think we might increase the interface stability in phase 2. So I'm not entirely sure yet about libhotplug.h. Let's defer a final decision until the meeting, so no updates to the materials yet. ged-02 It seems like changestate is a bit awkward/counterintuitive to admin users (at least from my read). I'd recommend new commands instead: "enable", "disable", "power_off", "power_on" for connectors for ports, "attach" and "detach" seem enough... is there a need for administrators to enter the initialize state explicitly? (That doesn't make a lot of sense to me.) A new user interface has been designed per the above suggestion. The interface uses different subcommands for each state transition. The hotplugd(1M) manpage has been revised accordingly. ged-03 In shp-overview.pdf, it seems like you could predefine some more values for DDI_HP_CN_TYPE... I'd like to see types for USB, PCMCIA, CARDBUS, FIREWIRE, SCSI, FC, IB, and SDCARD. These are the types of devices in Solaris that have some form of hotplug support via cfgadm. (They might not be implemented, but reserving the name space still seems like a good idea to me.) The team's response is that we do not yet have enough information on which buses will be supported by the new hotplug framework, or how exactly that support would be implemented. It might be premature to reserve such namespaces. Also, there is a concern we might reserve namespaces incorrectly if we try doing it now. One example cited within the team was with USB. Would we want to reserve a single value for USB right now? What if we implement the USB support and instead realize we want separate values for each version of USB? seb-01 What stability level are the options that the -o argument to the hotplug command operates on? They're not documented in the man page. How are users expected to know their semantics? We introduce a new feature to get online help about supported options and their possible values through the hotplug(1M) command. The manpage can document defined options.