[Libvir] [PATCH] About remote operation restrictions of a general user
Hi When I use virt-connect in a general user, and a general user can perform operation system such as "start". So, here's the patch adds to can't use operation system in "connect" in a general user. Signed-off-by: Shigeki Sakamoto <fj0588di@aa.jp.fujitsu.com> Thanks, Shigeki Sakamoto. Index: src/virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.71 diff -u -p -r1.71 virsh.c --- src/virsh.c 2 Apr 2007 11:56:38 -0000 1.71 +++ src/virsh.c 4 Apr 2007 05:51:08 -0000 @@ -360,6 +360,8 @@ static int cmdConnect(vshControl * ctl, vshCmd * cmd) { int ro = vshCommandOptBool(cmd, "readonly"); + virDomainPtr dom; + char *ret; if (ctl->conn) { if (virConnectClose(ctl->conn) != 0) { @@ -374,12 +376,25 @@ cmdConnect(vshControl * ctl, vshCmd * cm free(ctl->name); ctl->name = vshStrdup(ctl, vshCommandOptString(cmd, "name", NULL)); + ctl->conn = virConnectOpenReadOnly(ctl->name); + ctl->readonly = 1; + if (!ro && ctl->uid != 0){ + dom = virDomainLookupByID(ctl->conn, 0); + if (dom==NULL) + return FALSE; + ret = virDomainGetXMLDesc(dom, 0); + if (NULL != strstr(ret, "domain type='xen'")) + ro = 1; + free(ret); + } if (!ro) { + if (virConnectClose(ctl->conn) != 0) { + vshError(ctl, FALSE, + _("Failed to disconnect from the hypervisor")); + return FALSE; + } ctl->conn = virConnectOpen(ctl->name); ctl->readonly = 0; - } else { - ctl->conn = virConnectOpenReadOnly(ctl->name); - ctl->readonly = 1; } if (!ctl->conn) @@ -3175,6 +3190,9 @@ _vshStrdup(vshControl * ctl, const char static int vshInit(vshControl * ctl) { + virDomainPtr dom; + char *ret; + if (ctl->conn) return FALSE; @@ -3188,8 +3206,26 @@ vshInit(vshControl * ctl) !strcasecmp(ctl->name, "xen")) && ctl->uid != 0) ctl->readonly = 1; - if (!ctl->readonly) + if (!ctl->readonly) { ctl->conn = virConnectOpen(ctl->name); + + if (ctl->uid != 0){ + dom = virDomainLookupByID(ctl->conn, 0); + if (dom==NULL) + return FALSE; + ret = virDomainGetXMLDesc(dom, 0); + if (NULL != strstr(ret, "domain type='xen'")) { + if (virConnectClose(ctl->conn) != 0) { + vshError(ctl, FALSE, + _("Failed to disconnect from the hypervisor")); + return FALSE; + } + ctl->conn = virConnectOpenReadOnly(ctl->name); + ctl->readonly = 1; + } + free(ret); + } + } else ctl->conn = virConnectOpenReadOnly(ctl->name);
On Wed, Apr 04, 2007 at 03:34:23PM +0900, S.Sakamoto wrote:
Hi
When I use virt-connect in a general user, and a general user can perform operation system such as "start".
So, here's the patch adds to can't use operation system in "connect" in a general user.
Signed-off-by: Shigeki Sakamoto <fj0588di@aa.jp.fujitsu.com>
Honnestly I don't understand the problem, nor what the patch is really trying to achieve. Using connect as a normal user may work just fine (for example if using QEmu/KVM) or fail (for example if only Xen is available). What is this patch trying to do ? Please explain, I don't clearly see what its is doing and why. thanks, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Hi, Daniel This issue should be based on libvirt Authorization Model. I do not know libvirt Authorization model. How do you think? or any document exists? Or should be discuss libvirt Authorization Model later? Thanks Atsushi SAKAI Daniel Veillard <veillard@redhat.com> wrote:
On Wed, Apr 04, 2007 at 03:34:23PM +0900, S.Sakamoto wrote:
Hi
When I use virt-connect in a general user, and a general user can perform operation system such as "start".
So, here's the patch adds to can't use operation system in "connect" in a general user.
Signed-off-by: Shigeki Sakamoto <fj0588di@aa.jp.fujitsu.com>
Honnestly I don't understand the problem, nor what the patch is really trying to achieve. Using connect as a normal user may work just fine (for example if using QEmu/KVM) or fail (for example if only Xen is available). What is this patch trying to do ? Please explain, I don't clearly see what its is doing and why.
thanks,
Daniel
-- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Apr 04, 2007 at 09:33:53PM +0900, Atsushi SAKAI wrote:
Hi, Daniel
This issue should be based on libvirt Authorization Model. I do not know libvirt Authorization model. How do you think? or any document exists? Or should be discuss libvirt Authorization Model later?
Well currently this depends on the kind of virtualization used. For Xen normal user access is though the proxy and that's a read-only acces. For KEmu a non priviledged user will only be able to see and control the emulators running under his own user id. The models are very different and it's on a case by case basis, i.e. each driver will have different capabilities. The authorization model is not global. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Hi About virsh connect, I think as follows. ========================================================================== //Authorization model of a general user of now// *Local connection* *Remote connection* HV | Xen | QEmu/KVM/etc HV | Xen | QEmu/KVM/etc --------------------------------- --------------------------------- authority | R/W | R/W authority | R/O | R/W //Authorization model of a general user of mine// *Local connection* *Remote connection* HV | Xen | QEmu/KVM/etc HV | Xen | QEmu/KVM/etc --------------------------------- --------------------------------- authority | R/O | R/W authority | R/O | R/W # R/W=Read Write R/O=Read Only ========================================================================== In the same way as connection local at the time of remote connection, this revision is the contents which only Xen cannot full control. Thanks, Shigeki Sakamoto. Daniel Veillard <veillard@redhat.com> wrote:
On Wed, Apr 04, 2007 at 09:33:53PM +0900, Atsushi SAKAI wrote:
Hi, Daniel
This issue should be based on libvirt Authorization Model. I do not know libvirt Authorization model. How do you think? or any document exists? Or should be discuss libvirt Authorization Model later?
Well currently this depends on the kind of virtualization used. For Xen normal user access is though the proxy and that's a read-only acces. For KEmu a non priviledged user will only be able to see and control the emulators running under his own user id. The models are very different and it's on a case by case basis, i.e. each driver will have different capabilities. The authorization model is not global.
Daniel
-- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Hi, Daniel Would you give me a comment on this model? If not, please apply this patch.
About virsh connect, I think as follows.
========================================================================== //Authorization model of a general user of now//
*Local connection* *Remote connection*
HV | Xen | QEmu/KVM/etc HV | Xen | QEmu/KVM/etc --------------------------------- --------------------------------- authority | R/W | R/W authority | R/O | R/W
//Authorization model of a general user of mine//
*Local connection* *Remote connection*
HV | Xen | QEmu/KVM/etc HV | Xen | QEmu/KVM/etc --------------------------------- --------------------------------- authority | R/O | R/W authority | R/O | R/W
# R/W=Read Write R/O=Read Only ==========================================================================
In the same way as connection local at the time of remote connection, this revision is the contents which only Xen cannot full control.
Thanks, Shigeki Sakamoto.
On Tue, Apr 10, 2007 at 04:02:57PM +0900, S.Sakamoto wrote:
Hi, Daniel
Would you give me a comment on this model? If not, please apply this patch.
About virsh connect, I think as follows.
========================================================================== //Authorization model of a general user of now//
*Local connection* *Remote connection*
HV | Xen | QEmu/KVM/etc HV | Xen | QEmu/KVM/etc --------------------------------- --------------------------------- authority | R/W | R/W authority | R/O | R/W
I don't see why you consider that currently a general user can open a R/W Xen connection. This will fail. That's IMHO normal. A normal user must use the --readonly flag when connecting to Xen. For remote connections it really depends, if the administrator opened the xend port then the remote access would be R/W so those two points looks wrong to me. I still don't understand what you are trying to achieve. And I won't apply any patch until I understand what you are trying to do, why, how the patch work and what the side effects may be. I'm sorry if this is annoying but this really must be done. You need to convince me on those points, and so far I still block on the very early step: - what you are trying to achieve ? - why ? Explain to me, possibly with example what the actual problem is. So far I disagreed with what you exposed in your model, and I don't understand what and how your patch is supposed to change things. Please explain, thanks, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Hi, Daniel Sorry, I think that explanation was not enough... About "virsh connect" of Xen: When a general user has access to remote, he can't carry out a command of "virsh --connect xen start <domain>", but, he can carry out a command of "virsh --connect http://10.xx.xx.xx:8000 start <domain>". (What is a kind of Hypervisor? not judge it to be it.Therefore this is not ReadOnly. "virsh.c - vshInit" decides "R/O" or "R/W" by the result that judged a kind of Hypervisor to be it.) I think that it is a problem that a general user can carry out command (e.g."start","destroy"). So, I make the patch which prevented remote control using the following problem. 1)in general user # virsh destroy <domain> operation virDomainCreate forbidden for read only access -- I agree with this behavior # virsh --conexct xen destory <domain> operation virDomainCreate forbidden for read only access -- I agree with this behavior # virsh --conect http://10.xx.xx.xx:8000 destroy <domain> <domain> was destory ... -- I think that this behavior is a problem 2)in root user # virsh destroy <domain> <domain> was destory ... -- I agree with this behavior # virsh --conexct xen destory <domain> <domain> was destory ... -- I agree with this behavior # virsh --conect http://10.xx.xx.xx:8000 destroy <domain> <domain> was destory ... -- I agree with this behavior Thanks, Shigeki Sakamoto.
I don't see why you consider that currently a general user can open a R/W Xen connection. This will fail. That's IMHO normal. A normal user must use the --readonly flag when connecting to Xen. For remote connections it really depends, if the administrator opened the xend port then the remote access would be R/W so those two points looks wrong to me.
I still don't understand what you are trying to achieve. And I won't apply any patch until I understand what you are trying to do, why, how the patch work and what the side effects may be. I'm sorry if this is annoying but this really must be done. You need to convince me on those points, and so far I still block on the very early step: - what you are trying to achieve ? - why ? Explain to me, possibly with example what the actual problem is. So far I disagreed with what you exposed in your model, and I don't understand what and how your patch is supposed to change things. Please explain,
thanks,
Daniel
On Thu, Apr 12, 2007 at 02:14:37PM +0900, S.Sakamoto wrote:
Hi, Daniel
Sorry, I think that explanation was not enough...
About "virsh connect" of Xen:
When a general user has access to remote, he can't carry out a command of "virsh --connect xen start <domain>", but, he can carry out a command of "virsh --connect http://10.xx.xx.xx:8000 start <domain>". (What is a kind of Hypervisor? not judge it to be it.Therefore this is not ReadOnly. "virsh.c - vshInit" decides "R/O" or "R/W" by the result that judged a kind of Hypervisor to be it.)
I think that it is a problem that a general user can carry out command (e.g."start","destroy").
So, I make the patch which prevented remote control using the following problem.
1)in general user # virsh destroy <domain> operation virDomainCreate forbidden for read only access -- I agree with this behavior # virsh --conexct xen destory <domain> operation virDomainCreate forbidden for read only access -- I agree with this behavior # virsh --conect http://10.xx.xx.xx:8000 destroy <domain> ?$B!!!! ?$B!!<domain> was destory ... -- I think that this behavior is a problem
Yes, that is a problem - a problem with XenD though - it insanely allows complete control over any domain when connecting over TCP+HTTP. Everyone strongly recommends against turning on the TCP+HTTP server in XenD for this reason. In Fedora we only turn on UNIX+HTTP server, so only root is able to connect to XenD. In the new XenAPI, the TCP+XMLRPC service will include user authentication so it will be possible to explicitly allow full operational access to XenD by a non-root user.
2)in root user # virsh destroy <domain> <domain> was destory ... -- I agree with this behavior # virsh --conexct xen destory <domain> <domain> was destory ... -- I agree with this behavior # virsh --conect http://10.xx.xx.xx:8000 destroy <domain> <domain> was destory ... -- I agree with this behavior
Basically libvirt/virsh should not be enforcing policy in this scenario. virsh should always default to a read-write connection, except in the case of using Xen locally as a non-root user, where we know that read-only is required due to the libvirt_proxy only allows read-only. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Hi, Daniel
1)in general user # virsh destroy <domain> operation virDomainCreate forbidden for read only access -- I agree with this behavior # virsh --conexct xen destory <domain> operation virDomainCreate forbidden for read only access -- I agree with this behavior # virsh --conect http://10.xx.xx.xx:8000 destroy <domain> <domain> was destory ... -- I think that this behavior is a problem
Yes, that is a problem.
I intended to have made it to solve this problem, But...
In the new XenAPI, the TCP+XMLRPC service will include user authentication so it will be possible to explicitly allow full operational access to XenD by a non-root user.
If include user authentication, it solve the problem. I think so too. Therefore I retire from this problem. Thanks, Shigeki Sakamoto.
About "virsh connect" of Xen:
When a general user has access to remote, he can't carry out a command of "virsh --connect xen start <domain>", but, he can carry out a command of "virsh --connect http://10.xx.xx.xx:8000 start <domain>". (What is a kind of Hypervisor? not judge it to be it.Therefore this is not ReadOnly. "virsh.c - vshInit" decides "R/O" or "R/W" by the result that judged a kind of Hypervisor to be it.)
I think that it is a problem that a general user can carry out command (e.g."start","destroy").
So, I make the patch which prevented remote control using the following problem.
1)in general user # virsh destroy <domain> operation virDomainCreate forbidden for read only access -- I agree with this behavior # virsh --conexct xen destory <domain> operation virDomainCreate forbidden for read only access -- I agree with this behavior # virsh --conect http://10.xx.xx.xx:8000 destroy <domain> <domain> was destory ... -- I think that this behavior is a problem
Yes, that is a problem - a problem with XenD though - it insanely allows complete control over any domain when connecting over TCP+HTTP. Everyone strongly recommends against turning on the TCP+HTTP server in XenD for this reason. In Fedora we only turn on UNIX+HTTP server, so only root is able to connect to XenD.
In the new XenAPI, the TCP+XMLRPC service will include user authentication so it will be possible to explicitly allow full operational access to XenD by a non-root user.
2)in root user # virsh destroy <domain> <domain> was destory ... -- I agree with this behavior # virsh --conexct xen destory <domain> <domain> was destory ... -- I agree with this behavior # virsh --conect http://10.xx.xx.xx:8000 destroy <domain> <domain> was destory ... -- I agree with this behavior
Basically libvirt/virsh should not be enforcing policy in this scenario. virsh should always default to a read-write connection, except in the case of using Xen locally as a non-root user, where we know that read-only is required due to the libvirt_proxy only allows read-only.
Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
participants (4)
-
Atsushi SAKAI -
Daniel P. Berrange -
Daniel Veillard -
S.Sakamoto