Re: [Openipmi-developer] [PATCH] ipmi_lan: Accept higher privilegethan requested
On Thu, 2012-07-26 at 07:21 -0700, Andy Cress wrote: > Al, > > This is in the open session logic (once). > If the session requires a higher privilege level, it should request a > higher privilege level. > Either the firmware will allow the session open with the requested > privilege or it won't. > I don't understand your reference to 'random IPMI commands'. Ohhh, you're right. It would be caught at the set session privilege level stage later on, I forgot about that. My "random IPMI commands" was in reference to the actual IPMI commands sent out later in the session, like Get Device ID or Get Sensor Reading or Get SEL Info. I'm mixing different issues in my head. Al > Is there really a use case where you would not want it to proceed, given > that there is a use case (ILO3 bug) where allowing it to go through is > better? > > Andy > > > Even if the privilege is detected wrong here, it should not abort, but > > proceed. > > If the privilege is wrong, the target firmware will reject it. > > I do a similar check/error out in FreeIPMI. I believe it's the right > thing to do to error out at the "authentication phase" and tell the user > they can't connect at the requested privilege level. Otherwise, random > IPMI commands will just fail with "privilege level not sufficient" later > on. > > Al > -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH] ipmi_lan: Accept higher privilegethan requested
Al, This is in the open session logic (once). If the session requires a higher privilege level, it should request a higher privilege level. Either the firmware will allow the session open with the requested privilege or it won't. I don't understand your reference to 'random IPMI commands'. Is there really a use case where you would not want it to proceed, given that there is a use case (ILO3 bug) where allowing it to go through is better? Andy > Even if the privilege is detected wrong here, it should not abort, but > proceed. > If the privilege is wrong, the target firmware will reject it. I do a similar check/error out in FreeIPMI. I believe it's the right thing to do to error out at the "authentication phase" and tell the user they can't connect at the requested privilege level. Otherwise, random IPMI commands will just fail with "privilege level not sufficient" later on. Al -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH v2] ipmi_lan: Accept different privilege than requested
Currently openipmi expects that the privilege level in the
open session response equals the privilege which was requested.
This is wrong, because it is legal to request a lower privilege
level than allowed for a user:
According to IPMI v2.0 spec the RCMP+ Open Session Response
contains the _maximum_ privilege Level allowed for a session.
Furthermore Andy Cress pointed out:
Even if the privilege is detected wrong here, it should not abort, but
proceed.
The bug was found because there seems to be a bug in the HP ILO3 IPMI
implementation where the maximum privilege level returned in the response
is "admin" even if the user is only allowed to login with privilege
"operator".
Both bugs together prevent the ipmilan stonith agent to work with ILO3
and fence with priv="operator".
This patch fixes the behavior of openIPMI and allows the "session open"
response message to contain an different privilege level than requested.
An warning is issued if the privilege level is lower than requested.
With this patch fencing with "priv=operator" works correctly.
Signed-off-by: Arnd Hannemann
---
lib/ipmi_lan.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/lib/ipmi_lan.c b/lib/ipmi_lan.c
index c55445e..cc75531 100644
--- a/lib/ipmi_lan.c
+++ b/lib/ipmi_lan.c
@@ -4530,13 +4530,11 @@ got_rmcpp_open_session_rsp(ipmi_con_t *ipmi,
ipmi_msgi_t *rspi)
lan = (lan_data_t *) ipmi->con_data;
privilege = msg->data[2] & 0xf;
-if (privilege != lan->cparm.privilege) {
- ipmi_log(IPMI_LOG_ERR_INFO,
+if (privilege < lan->cparm.privilege) {
+ ipmi_log(IPMI_LOG_WARNING,
"%sipmi_lan.c(got_rmcpp_open_session_rsp): "
"Expected privilege %d, got %d",
IPMI_CONN_NAME(ipmi), lan->cparm.privilege, privilege);
- handle_connected(ipmi, EINVAL, addr_num);
- goto out;
}
session_id = ipmi_get_uint32(msg->data+4);
--
1.7.9.5
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH] ipmi_lan: Accept higher privilege than requested
On Thu, 2012-07-26 at 06:41 -0700, Andy Cress wrote:
> Certainly a needed patch, but why do this check at all (other than FYI)?
>
> Even if the privilege is detected wrong here, it should not abort, but
> proceed.
> If the privilege is wrong, the target firmware will reject it.
I do a similar check/error out in FreeIPMI. I believe it's the right
thing to do to error out at the "authentication phase" and tell the user
they can't connect at the requested privilege level. Otherwise, random
IPMI commands will just fail with "privilege level not sufficient" later
on.
Al
> Andy
>
> -Original Message-
> From: Arnd Hannemann [mailto:a...@arndnet.de]
> Sent: Thursday, July 26, 2012 7:16 AM
> To: openipmi-developer@lists.sourceforge.net
> Subject: [Openipmi-developer] [PATCH] ipmi_lan: Accept higher privilege
> thanrequested
>
> Currently openipmi expects that the privilege level in the
> open session response equals the privilege which was requested.
> This is wrong, because it is legal to request a lower privilege
> level than allowed for a user:
>
> According to IPMI v2.0 spec the RCMP+ Open Session Response
> contains the _maximum_ privilege Level allowed for a session.
>
> Additionally there seems to be a bug in the HP ILO3 IPMI implementation
> where the maximum privilege level returned in the response is "admin"
> even if the user is only allowed to login with privilege "operator".
>
> Both bugs together prevent the ipmilan stonith agent to work with ILO3
> and fence with priv="operator".
>
> This patch fixes the behavior of openIPMI and allows the "session open"
> repsonse
> message to contain an higher privilege level than requested.
> With this patch fencing with "priv=operator" works correctly.
>
> Signed-off-by: Arnd Hannemann
> ---
> lib/ipmi_lan.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/ipmi_lan.c b/lib/ipmi_lan.c
> index c55445e..095f133 100644
> --- a/lib/ipmi_lan.c
> +++ b/lib/ipmi_lan.c
> @@ -4530,7 +4530,7 @@ got_rmcpp_open_session_rsp(ipmi_con_t *ipmi,
> ipmi_msgi_t *rspi)
> lan = (lan_data_t *) ipmi->con_data;
>
> privilege = msg->data[2] & 0xf;
> -if (privilege != lan->cparm.privilege) {
> +if (privilege < lan->cparm.privilege) {
> ipmi_log(IPMI_LOG_ERR_INFO,
>"%sipmi_lan.c(got_rmcpp_open_session_rsp): "
>"Expected privilege %d, got %d",
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH] ipmi_lan: Accept higher privilege than requested
Certainly a needed patch, but why do this check at all (other than FYI)?
Even if the privilege is detected wrong here, it should not abort, but
proceed.
If the privilege is wrong, the target firmware will reject it.
Andy
-Original Message-
From: Arnd Hannemann [mailto:a...@arndnet.de]
Sent: Thursday, July 26, 2012 7:16 AM
To: openipmi-developer@lists.sourceforge.net
Subject: [Openipmi-developer] [PATCH] ipmi_lan: Accept higher privilege
thanrequested
Currently openipmi expects that the privilege level in the
open session response equals the privilege which was requested.
This is wrong, because it is legal to request a lower privilege
level than allowed for a user:
According to IPMI v2.0 spec the RCMP+ Open Session Response
contains the _maximum_ privilege Level allowed for a session.
Additionally there seems to be a bug in the HP ILO3 IPMI implementation
where the maximum privilege level returned in the response is "admin"
even if the user is only allowed to login with privilege "operator".
Both bugs together prevent the ipmilan stonith agent to work with ILO3
and fence with priv="operator".
This patch fixes the behavior of openIPMI and allows the "session open"
repsonse
message to contain an higher privilege level than requested.
With this patch fencing with "priv=operator" works correctly.
Signed-off-by: Arnd Hannemann
---
lib/ipmi_lan.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/ipmi_lan.c b/lib/ipmi_lan.c
index c55445e..095f133 100644
--- a/lib/ipmi_lan.c
+++ b/lib/ipmi_lan.c
@@ -4530,7 +4530,7 @@ got_rmcpp_open_session_rsp(ipmi_con_t *ipmi,
ipmi_msgi_t *rspi)
lan = (lan_data_t *) ipmi->con_data;
privilege = msg->data[2] & 0xf;
-if (privilege != lan->cparm.privilege) {
+if (privilege < lan->cparm.privilege) {
ipmi_log(IPMI_LOG_ERR_INFO,
"%sipmi_lan.c(got_rmcpp_open_session_rsp): "
"Expected privilege %d, got %d",
--
1.7.9.5
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions
will include endpoint security, mobile security and the latest in
malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH] ipmi_lan: Accept higher privilege than requested
Currently openipmi expects that the privilege level in the
open session response equals the privilege which was requested.
This is wrong, because it is legal to request a lower privilege
level than allowed for a user:
According to IPMI v2.0 spec the RCMP+ Open Session Response
contains the _maximum_ privilege Level allowed for a session.
Additionally there seems to be a bug in the HP ILO3 IPMI implementation
where the maximum privilege level returned in the response is "admin"
even if the user is only allowed to login with privilege "operator".
Both bugs together prevent the ipmilan stonith agent to work with ILO3
and fence with priv="operator".
This patch fixes the behavior of openIPMI and allows the "session open" repsonse
message to contain an higher privilege level than requested.
With this patch fencing with "priv=operator" works correctly.
Signed-off-by: Arnd Hannemann
---
lib/ipmi_lan.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/ipmi_lan.c b/lib/ipmi_lan.c
index c55445e..095f133 100644
--- a/lib/ipmi_lan.c
+++ b/lib/ipmi_lan.c
@@ -4530,7 +4530,7 @@ got_rmcpp_open_session_rsp(ipmi_con_t *ipmi, ipmi_msgi_t
*rspi)
lan = (lan_data_t *) ipmi->con_data;
privilege = msg->data[2] & 0xf;
-if (privilege != lan->cparm.privilege) {
+if (privilege < lan->cparm.privilege) {
ipmi_log(IPMI_LOG_ERR_INFO,
"%sipmi_lan.c(got_rmcpp_open_session_rsp): "
"Expected privilege %d, got %d",
--
1.7.9.5
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
