I'm not sure what you mean by "noaccess". Do you want us to change the method_context for LMS from "root:root" to "noaccess:noaccess"?
Gary Winiger wrote: > OOPS looks like an empty reply escaped my try to kill it. > Sorry... > > >> Gary Winiger wrote: >> >>> ... >>> Team, thanks for the excellent update. Still a few open questions: >>> >>> * Other than the IOCTL, I've missed seeing interface taxonomies. >>> * I've also missed seeing the release binding. >>> * What's the set of exported interface? >>> >>> >> The interface taxonomy for the IOCTLs is "project private", release >> binding: micro/patch. >> Other than that there's no other exported interface. The users are >> directly talking >> to the firmware which is AMT's real interface-provider. This project >> only provides >> an HTTP(s) service on TCP port 16992/16993 to relay the messages to/from >> the firmware. >> > > Nits, that could be edifying. > It seems to me there might well be other interfaces other than > just the IOCTLs lurking about. Yes as I said, I read that the > IOCTLs were project private. > Other interfaces might be the device name, the service name > and service properties. > Presumably this is the case that exports the device (/dev/heci), > either that or it has a case dependency that I missed. > Presumably this is the case that exports the service > (svc:/network/lms). > > Are there any service specific properties? > > >>> * 5.6-5.8 seem incomplete to me. What privileges? What Rights >>> Profiles, and why? Perhaps more explicitly, what's the >>> method_context of svc:/network/lms and how does this proposed >>> service comply to the SMF policy: >>> http://opensolaris.org/os/community/arc/policies/SMF-policy/ >>> (which unfortunately is 2 revs behind the internal >>> http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp) >>> Yes I'm sending John email once again ;-{ >>> >>> >> The method_context section of LMS includes a limited set of privileges: >> basic,sys_net_config,net_rawaccess >> This is to grant LMS the rights to open /dev/heci and send IOCTLs. >> > > Hummm, this seems to be different than a later reply. The point > is to run with the least effective and permitted privileges > an non-system (viz "noaccess" user/group) ids as possible. > Anything above that needs some justification. > > >>> * 7 "? Remotely Protect Computing Assets : Through Out of Band >>> communication, each system's software version numbers are checked >>> and, if necessary, system software and virus protection are >>> remotely updated with the most recent patches and virus definitions. >>> Viruses and worms can also be contained at their source, if needed, >>> by means of built-in circuit-breaker functionality. >>> >>> "Intel AMT infrastructure supports the creation of setup and >>> configuration interfaces for management applications, as well >>> as network, security, and storage administration." >>> >>> What does this mean relative to this project? How are Solaris >>> veriion numbers (service tags ;-) being checked? How is Solaris >>> system software and virus protection being remotely updated >>> with the most recent patches and virus definitions? >>> >>> Gary.. >>> >>> >> This project currently does not deliver these features for phase I. But >> after the integration of >> this project will work with ISVs (i.e. anti-virus vendors, etc.) to add >> the above mentioned feature. >> The implementation detail is TDB. However, we realize/document the >> following AMT capabilities >> e.g. >> Remote software version checking/updating can be done by the using the >> EEPROM >> named 3PDS (3rd Party Data Storage), and share it with remote management >> console. >> See 6.18 about StorageRealm. >> > > Hummm, not for phase I seem OK, but remotely nuking Solaris > components without administrative requests seems overall bad. > There's the whole "Connected Customer" group under Steve Wilson > that needs to be brought into the picture for anything related > to Software Updating. I suspect there's a parallel group for > Firmware Updating some place in John Fowler's orginization. > I'd suggest contacting FWARC before proceeding along those > lines. > > Gary.. >
