Hi all,
again - sorry for delay but i am kinda busy :(. See answers below:
> Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote:
>>
>>>
>>>> Regarding the "ipmitool" - I was in contact with guys working
>>>> on/with "ipmitool" (Kevin.Song at Sun.COM, Hesam.Kohanteb at Sun.COM,
>>>> turgo-ipmi at Sun.COM ..) to clarify some technical details regarding
>>>> the BMC driver, and they did not raise any objections/concerns
>>>> regarding porting of freeipmi to Open Solaris, they were rather
>>>> looking forward for it. Does my answer satisfy your question, or
>>>> there should be detailed description what functionality is covered
>>>> by ipmitool/freeipmi and whether they do compete or complement?
>>>
>>> I think the ARC needs to be presented with why this is needed given
>>> we have ipmitool.
>> Answer directly from my director Fritz Ferstl
>> (Friedrich.Ferstl at sun.com) :
>>
>> "We need freeimpi because it is used by 'Tortuga', the provisioning
>> core of our OpenSolaris HPC SW stack. 'Tortuga' is open source and
>> thus uses other open source components such as freeipmi. Usage of
>> ipmitool has been assessed but freeipmi has found to be a better fit
>> for the time being."
>
> I'd like this spelled out in more detail. Specifically, *why* is
> freeipmi deemed a better fit? Is it simply a matter of licensing, or
> are the technical or architectural considerations here.
For the UniCluster / Tortuga side freeipmi is used primarily for its
"bmc-config" tool. The "bmc-config" command provides an easy way to extract
the configuration information from on bmc and store it in a file that can be
used to back up the configuration or be modified and pushed to other similar
BMC's. Specifically UniCluster contains a tool called "bmc-tool" that allows
you to extract the configuration from one bmc and push it to another while
automatically replacing LAN configuration parameters. This tool is part of our
general cluster BMC configuration strategy.
The freeipmi tools, such as bmc-config, can be configured to use different
drivers including the OpenIPMI driver (which is the default in our bmc-tool
tool).
>
> One of the problems we (Sun) have historically suffered from is *too
> many* different service processor and platform management systems.
> I'm personally not too keen to integrate another one.
freeipmi is just a CLIENT tool that supports ONLY IPMI service processors.
>
> Other questions (sorry if these seem obvious -- I've little experience
> with service processor stuff since the E10K SSP. :-)
>
> Can freeimpi and ipmitool coexist on the same platform? What int4tr
sorry, I do not not know what is "int4tr" - can you explain (or provide
me some link to docs, where I can study it - uncle google was not
helpful, sorry)? anyway, freeipmi and ipmitool can happily coexist on
the same platform. you can think of them like "vncviewer" and
"tvncviewier" (both are VNC clients and both can coexist on the same
platform)
>
> Is this really a Linux familiarity case?
well, I believe it is. why it would not be? freeipmi has good name in
linux world (as a set of ipmi client tools)
>
> IPMI specs seem to require signing an "Adopters agreement for IPMI"
> from Intel. Has anyone checked to see if freeipmi has followed the
> necessary steps so our legal bases are covered for integrating it?
I will try to double check this, but I bet the "Adopters agreement for
IPMI" has to be signed by companies implementing IPMI spec which is not
freeipmi case (that are implementing client tools) - in fact, as the Sun
is already providing servers with IPMI interface, I believe that Sun has
signed "Adopters agreement for IPMI".
>
>>>
>>> What is the relationship between the daemons in this case and the
>>> ipmievd one from PSARC/2006/412 ? Particularly in light of the long
>>> discussion in that case about FAM.
>>
>> The "ipmievd" is just logging the IPMI events to syslog while
>> freeipmi "bmc-watchdog" is able to also trigger an action upon
>> receive of an IPMI event. The "ipmidetecd" is able to find new
>> machines in specified subnets that are exposing an IPMI interface and
>> add it to "freeipmi managed" hosts.
>
> Have the security implications of this been properly reviewed by a
> member of the security team? How does one ensure that a machine
> running ipmidetecd and the watchdog doesn't reboot a system that it
> shouldn't? Are there any authorization or authentication steps
> taken? Again, this might all be covered as part of IPMI itself, and
> so seem to be obvious, but not all the readers here (certainly not
> this author) are familiar with IPMI.
I am not aware of any member of security team that would do the security
review - I did not know it is needed. If it is needed, I will try to
arrange it - is there any process behind it, or can you give me a
contact to someone? Regarding your question, I will try to enlighten it:
1. IPMI standard clearly defines the authentication and authorization of
users (described in foss checkslist in 3.4.6, see bottom of email please)
2. user management is performed on SP side - so, on SP side you can
define users (with credentials) and grant them permissions to perform
certain activities. IPMI defines 3 groups
of permissions (monitor/user, manager/operator, admin).
- monitor/user has ability just monitor the platform
- manager/operator has (in addition to monitor/user group) ability
to perform for example power operations
- admin has (in addtion to manager/operator) ability to manage SP
(access control, reset SP, upload new firmware etc.)
(through vendor extension, it is possible to setup SP in a way, that
users are taken from DS (NIS, AD, LDAP) and permissions mapping is done
through DS groups (e.g. all users from NIS group "ipmi_ops" will be
granted "manager/operator" permissions))
3. freeipmi (or any other IPMI client tool, e.g. ipmitool) has to
specify the "SP user" to authenticate the access to SP. authorization to
perform the action (reboot the machine, for example) is then done on SP
side by comparing the authenticated user's permissions.
By default, any SP is delivered with only ADMIN user with some
"predefined" password. It is up-to system (lab) administrator to setup
SP users that have ability to access the SP.
In freeipmi client tools you need to specify user that is used when
accessing the SP - this applies also for watchdog services.
Example - command performed as user "mb123456":
> ipmimonitoring -h latte2 -u uadmin
where "-u uadmin" specifies that for authentication the user with name
"uadmin" has to be used. for command to be successful, the user "uadmin"
has to be defined on SP side and it has to be in group (at least)
"monitor/user"AND a valid password for user "uadmin" has to be provided
(the command will prompt for password upon invocation).
For services (bmc-watchdog and ipmidetecd), the password for user that
is configured to access the SP is stored in file and file is readable
only by the user that is used to run the service.
Regards,
Michal
PS: excerpt from freeipmi foss checklist regarding the IPMI security, as
used by freeipmi:
The authentication/authorization mechanism is part of project nework
services
(as defined by IPMI spec.) and it takes into acount the user
identity.
A functionality available to the user depends on successful
authentication
and on the user authorization.
The project implements the authentication mechanism as requested
by IMPI 1.5 and 2.0
specification. For communication involving IPMI 1.5 clients/sides,
available authentication types are (defaults to MD5 if not
specified):
- NONE,
- STRAIGHT_PASSWORD_KEY,
- MD2,
- MD5
For communication involving IPMI 2.0 clients/sides, it is possible to
choose a "cipher suite" to be used. The Cipher Suite is a set of
authentication,
integrity, and confidentiality algorithms to use for IPMI 2.0
communication.
The authentication algorithm identifies the algorithm to use for
session setup,
the integrity algorithm identifies the algorithm to use for
session packet signatures,
and the confidentiality algorithm identifies the algorithm to use
for payload encryption.
Defaults to cipher suite ID 3 if not specified (see below). The
following cipher
suite ids are currently supported:
0 - Authentication Algorithm = None; Integrity Algorithm = None;
Confidentiality Algorithm = None
1 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm =
None; Confidentiality Algorithm = None
2 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm =
HMAC-SHA1-96; Confidentiality Algorithm = None
3 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm =
HMAC-SHA1-96; Confidentiality Algorithm = AES-CBC-128 ." .sp ."
4 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm =
HMAC-SHA1-96; Confidentiality Algorithm = xRC4-128 ." .sp ."
5 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm =
HMAC-SHA1-96; Confidentiality Algorithm = xRC4-40
6 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
None; Confidentiality Algorithm = None
7 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
HMAC-MD5-128; Confidentiality Algorithm = None
8 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
HMAC-MD5-128; Confidentiality Algorithm = AES-CBC-128 ." .sp ."
9 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
HMAC-MD5-128; Confidentiality Algorithm = xRC4-128 ." .sp ."
10 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
HMAC-MD5-128; Confidentiality Algorithm = xRC4-40
11 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
MD5-128; Confidentiality Algorithm = None
12 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
MD5-128; Confidentiality Algorithm = AES-CBC-128 ." .sp ."
13 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
MD5-128; Confidentiality Algorithm = xRC4-128 ." .sp ."
14 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
MD5-128; Confidentiality Algorithm = xRC4-40
In addition, project supports specifying the privilege level
(according the IPMI
specification) which can be of (defaults to admin):
- USER
- OPERATOR
- ADMIN
Notice, that the authentication/authorization is not done at the
operating system level, but on the IPMI level (adheres to requirements
and recommendations of IPMI spec).
>
> -- Garrett
>
>
