Dale Ghent writes: > 6) Why /usr/lib/lms and not /usr/lib/amt/lmsd ?
Unless there are multiple private objects associated with amt, and enough of them that littering /usr/lib with them would be seen as annoying, there's no reason to create a subdirectory in /usr/lib. Mark Logan writes: > > http://www.opensolaris.org/os/community/arc/policies/ITS/ > > http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ > > > > http://www.opensolaris.org/os/community/arc/bestpractices/security-questions/ > > > I think we are OK, since LMS only accepts connections from the local > machine. > See: http://openamt.org/wiki/LocalManageabilityService It's unclear exactly how the daemon does this. The web page you've provided seems to suggest that both 127.0.0.1 (which is strictly internal) *and* the local host name will work. The local host name typically resolves to one of the local interface IP addresses. However, the documentation is imprecise. It doesn't discuss what assumptions it makes about the host name to address mappings. In fact, it incorrectly associates host names with the kernel's routing mechanism, so it's quite unclear what (if anything) is meant here. If this documentation is correct, it seems to indicate that the daemon is in fact able to receive connection requests from outside of the box. That would place it under the "secure by default" and access control rules. (I can't tell if this web page is a normative or an informative reference. If it's meant to be normative, it's not complete. Please provide complete documentation with the case materials.) > > Are the port numbers involved registered with IANA? What security is > > provided? > > > The ports are registered with IANA: 16992 and 16993. OK. Those appear to be AMT SOAP/HTTP and AMT SOAP/HTTPS. > HTTP digest access authentication is required. That implies that there's a user name and password (or verifier) database stored somewhere. Where are these things stored and how are they protected? > > What privileges are required to talk with the kernel driver? What > > does that kernel driver do? > > > The kernel driver requires root privileges. Meaning "all privileges," I assume, and not magic UID 0. > The driver just passes the HTTP requests down to the AMT firmware and > passes the HTTP responses back up. That's not what I was asking. What can the driver do to the system? Can it modify system memory? Can it reboot the system? Can it turn off power? Can it force the system to reload a different kernel? I'm trying to get an idea of whether this device node is just a monitoring interface or if it has more serious security issues to be concerned about. David Chieu writes: > Mark Logan wrote: > > James Carlson wrote: > > > >> Would it be necessary for someone inside a non-global zone to access > >> that driver? If not, why not? If so, then how is that secured > >> How about inside an xVM instance? > >> > >> > > I'm going to let David answer to these questions. > This project phase I is only concerned about global zone and dom0. Phase > II targets non-global and domUs. Currently, we're *not* aware of any > customer requirements to access heci driver from a non-global zone. I'm > not familiar with virtualization - please advise if there are areas that > we need to take notes. That's fine. As long as you know of no customer requirement to do this, and you're not supporting it, I'm happy. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
