settingsLogin | Registersettings

[openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

0 votes

Hello,

Decided to start a new thread due to too much technical details in old
thread.
(You can see thread [openstack-dev] [keystone] [nova] )

The problem: Trusts can not be used to retrieve a token for further work
with python-client.

I made some research for trust's use cases. The main goal of trusts is
clear to me: delegation of privileges of one user to another on specific
time (or limitless). But if I get a trust and then get a token from it, it
can not be used in any python-client. The reason why it happens so - is
'authenticate' method in almost all python-clients. This method request a
keystone for authentication and get a new auth token. But in case of
trust-scoped token it can't be true - this method always return '403
Forbidden' [1]

The question: Is there a way to create a trust and use it for requests to
any other service? E.g., We can get a token from trust and use it (but
actually, we are not).

Or am I misunderstanding trust's purpose? How are trusts should worked?

[1]
https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156

Best Regards,
Nikolay Makhotkin
@Mirantis


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Feb 16, 2015 in openstack-dev by Nikolay_Makhotkin (2,300 points)   4 7
retagged Mar 6, 2015 by admin

21 Responses

0 votes

On Wed, Feb 18, 2015 at 07:23:52PM +0100, Raphael Glon wrote:
Hi,

This is about review:
https://review.openstack.org/#/c/156633/

1 line, can be controversial

Its purpose is to add the possibility not to use libguestfs for data
injection in nova, even when installed.

Not discussing about the fact that libguestfs should be preferred over fuse
mounts for data injection as much as possible because mounts are more
subject to causing security issues (and already have in the past nova
releases).

However, there are a lot of potential cases when libguestfs won't be usable
for data injection

This was the case here (fixed):
https://bugzilla.redhat.com/show_bug.cgi?id=984409

I entcountered a similar case more recently on powerkvm 2.1.0 (defect with
the libguestfs)

So just saying it could be good adding a simple config flag (set to True by
default, to keep the current behaviour untouched) to force nova not using
libguestfs without having to uninstall it and thus prevent other users on
the host from using it.

The bug you quote above was easily fixed. If you have problems with
powerkvm then file a bug about them so they can be investigated &
fixed too. Just disabling its use is simply not at all helpful as the
alternative impl is horribly insecure against malicious disk images
which can cause host kernel crash.

Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 19, 2015 by Daniel_P._Berrange (27,920 points)   2 4 10
0 votes

On Wed, Feb 18, 2015 at 07:23:52PM +0100, Raphael Glon wrote:
I entcountered a similar case more recently on powerkvm 2.1.0
(defect with the libguestfs)

What's the actual bug? We've worked hard, with IBM, to make
libguestfs work on POWER 7 and POWER 8 systems. I have full access to
those systems through Red Hat. If there's a new bug I'm sure we'll be
able to fix it.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 19, 2015 by Richard_W.M._Jones (620 points)   1
0 votes

@Renat, They are conceptually different:
- regular tokens are created for the owner of addressed resource
- trust scoped tokens are for trustees and have some security restrictions.
The case is about disallowing a trustee to aquire a regular token allowing
him anything the trustor is allowed. It'd be an exploit.

On Thu, Feb 19, 2015 at 9:01 AM, Renat Akhmerov rakhmerov@mirantis.com
wrote:

Hi,

On 18 Feb 2015, at 23:54, Nikolay Makhotkin nmakhotkin@mirantis.com
wrote:

Nova client's CLI parameter 'bypassurl' helps me. The client's API also
has 'management
url' attribute, if this one is specified - the client
doesn't reauthenticate. Also the most of clients have 'endpoint' argument,
so client doesn't make extra call to keystone to retrieve new token and
service_catalog.

Thank you for clarification!

I want to say an additional “thank you” from me for helping us solve this
problem that’s been around for a while.

And just a small conceptual question: in my understanding since trust
chaining has already landed this kind of reauthentication doesn’t make a
lot of sense to me. Isn’t trust chaining supposed to mean that trust-scoped
tokens a regular tokens should be considered equal? Or we should still
assume that trust scoped tokens are sort of limited? If yes then how
exactly they must be understood?

Thanks!

Renat Akhmerov
@ Mirantis Inc.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kind Regards,
Alexander Makarov,
Senoir Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 19, 2015 by Alexander_V_Makarov (900 points)   1 2
0 votes

On 19 Feb 2015, at 18:32, Alexander Makarov amakarov@mirantis.com wrote:

@Renat, They are conceptually different:
- regular tokens are created for the owner of addressed resource
- trust scoped tokens are for trustees and have some security restrictions.
The case is about disallowing a trustee to aquire a regular token allowing him anything the trustor is allowed. It'd be an exploit.

Alexander,

Thanks for explanations. I kind of get the general idea, yes. What is best source where we could go and read in details about that? The only page I was able to find is https://wiki.openstack.org/wiki/Keystone/Trusts https://wiki.openstack.org/wiki/Keystone/Trusts but it would be nice if something more tutorial-like existed.

Renat Akhmerov
@ Mirantis Inc.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 19, 2015 by Renat_Akhmerov (12,320 points)   2 5 7
0 votes

@Renat, I like the idea. For now we have a spec:
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-trust-ext.rst
It's consiedered to be enough but as for me it lacks TL;DR section :)

On Thu, Feb 19, 2015 at 8:15 PM, Renat Akhmerov rakhmerov@mirantis.com
wrote:

On 19 Feb 2015, at 18:32, Alexander Makarov amakarov@mirantis.com wrote:

@Renat, They are conceptually different:
- regular tokens are created for the owner of addressed resource
- trust scoped tokens are for trustees and have some security restrictions.
The case is about disallowing a trustee to aquire a regular token allowing
him anything the trustor is allowed. It'd be an exploit.

Alexander,

Thanks for explanations. I kind of get the general idea, yes. What is best
source where we could go and read in details about that? The only page I
was able to find is https://wiki.openstack.org/wiki/Keystone/Trusts but
it would be nice if something more tutorial-like existed.

Renat Akhmerov
@ Mirantis Inc.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kind Regards,
Alexander Makarov,
Senoir Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 19, 2015 by Alexander_V_Makarov (900 points)   1 2
0 votes

On 02/19/2015 12:45 PM, Richard W.M. Jones wrote:
On Wed, Feb 18, 2015 at 07:23:52PM +0100, Raphael Glon wrote:

I entcountered a similar case more recently on powerkvm 2.1.0
(defect with the libguestfs)
What's the actual bug? We've worked hard, with IBM, to make
libguestfs work on POWER 7 and POWER 8 systems. I have full access to
those systems through Red Hat. If there's a new bug I'm sure we'll be
able to fix it.

Rich.

Hi, thank you for all your answers.

Not saying there are "actual" bugs (anyway I'm stuck here because i
would need to find time+environment to recheck all/reproduce) -> i
haven't even deployed juno on pkvm yet

We've talked with ibm (and they have likely been working with you) and
they are really responsive in fixing defects with their distribution

We've entcountered two problems with powerkvm regarding nova + libguestfs.

  1. since pkvm 2.1.x is forked from a Fedo 19, we fell back to this Red
    Hat bug you fixed regarding the attach method

Note that one of the workaround proposed was

sudo sysctl -w fs.protected_hardlinks=0 + common user nova/qemu

-> Not a specialist here, but seems like to be able to use libguestfs to
avoid "potential" issues with fuse mounts, we open other "potential"
holes somewhere else

  1. because pkvm 2.1.x is forked from fedo 19 it embeds rather old
    versions of libguestfs and libvirt.

We also entcountered the following issue(as you see from the dates, it
is rather "old"). About this, i was not perfectly accurate saying it was
a libguestfs defect, it was a pkvm defect embedding an old version of
libguestfs and anyway it also has been fixed quickly

http://paste.ubuntu.com/8465699/

Sep 30 14:25:33 host-power8-1 libvirtd[15894]: Domain id=2
name='guestfs-xv6mh1nvhr17ktj6'
uuid=341b09bc-6583-4b72-9df8-dc9b18116303 is tainted: custom-argv
Sep 30 14:25:33 host-power8-1 libvirtd[15894]: Unable to read from
monitor: Connection reset by peer
Sep 30 14:25:33 host-power8-1 kernel: [ 878.869394]
qemu-system-ppc[16250]: unhandled signal 11 at 00000000000000d8 nip
000000003070c0ac lr 000000003070bff4 code 30001
Sep 30 14:25:33 host-power8-1 libvirtd[15894]: cannot lookup default
selinux label for /tmp/libguestfsrOhcjP/console.sock
Sep 30 14:25:33 host-power8-1 libvirtd[15894]: cannot lookup default
selinux label for /tmp/libguestfsrOhcjP/guestfsd.sock
Sep 30 14:25:33 host-power8-1 libvirtd[15894]: cannot lookup default
selinux label for /var/tmp/.guestfs-0/kernel.16152
Sep 30 14:25:33 host-power8-1 libvirtd[15894]: cannot lookup default
selinux label for /var/tmp/.guestfs-0/initrd.16152

  1. Had no time to investigate on this but when using libguestfs with
    nova, the ghost was not always destroyed after file injection.
    Sometimes, you could find an instance spawned with the libguestfs ghost
    still running in the same time. Anyway, I've got no logs to detailthis
    issue, i'll try to get some one day

So summing up this patch was about:

File injection with libguestfs not working in some specific environment
(dist pkvm 2.1.0 + libguestfs pkvm packaged version + nova havana) and i
supposed i was not the only one concerned

On our side we had to temporarily disable file injection using libguestfs

Since nova still considers fuse mounts as acceptableit would have been
practical if, at the time, it had been flexible on the fact to use or
not libguestfs when this one is installed. (By the way, correct me if
wrong, but there are no current open issues with fuse mounts, and if
there are, why is it still proposed in nova ? would even say this is the
default/most used method because there is no dist considering libguestfs
is a dependency for the nova-compute package)

Get your reluctance. Giving up with the patch.

regards

raphael


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 23, 2015 by Raphael_Glon (300 points)   1
0 votes

On Mon, Feb 23, 2015 at 11:08:31AM +0100, Raphael Glon wrote:
On 02/19/2015 12:45 PM, Richard W.M. Jones wrote:

On Wed, Feb 18, 2015 at 07:23:52PM +0100, Raphael Glon wrote:

I entcountered a similar case more recently on powerkvm 2.1.0
(defect with the libguestfs)
What's the actual bug? We've worked hard, with IBM, to make
libguestfs work on POWER 7 and POWER 8 systems. I have full access to
those systems through Red Hat. If there's a new bug I'm sure we'll be
able to fix it.

Rich.

Hi, thank you for all your answers.

Not saying there are "actual" bugs (anyway I'm stuck here because i would
need to find time+environment to recheck all/reproduce) -> i haven't even
deployed juno on pkvm yet

We've talked with ibm (and they have likely been working with you) and they
are really responsive in fixing defects with their distribution

We've entcountered two problems with powerkvm regarding nova + libguestfs.

  1. since pkvm 2.1.x is forked from a Fedo 19, we fell back to this Red Hat
    bug you fixed regarding the attach method

Note that one of the workaround proposed was

sudo sysctl -w fs.protected_hardlinks=0 + common user nova/qemu

-> Not a specialist here, but seems like to be able to use libguestfs to
avoid "potential" issues with fuse mounts, we open other "potential" holes
somewhere else

The alternative Nova implementation is not using fuse, it is using real
mounts on the host FS. This is not a potential issue, it is an actual
issue. There have been bugs in Linux filesystem drivers, including ext4,
that would have allowed a malicous kernel image to crash and/or exploit
the host kernel if mounted.

http://libguestfs.org/guestfs.3.html#security-of-mounting-filesystems

The libguestfs architecture is explicitly designed such that any security
critical tasks take place inside an unprivileged KVM guest. So unless Nova
is using libguestfs in a broken way, the security of libguestfs is effectively
equivalent to the security of KVM in general. This is a faaar better security
architecture design

  1. because pkvm 2.1.x is forked from fedo 19 it embeds rather old versions
    of libguestfs and libvirt.

Fedora 19 is end of life so not really relevant any more as a target.
If there are bugs you find in current versions of Fedora please file
bugs so they can be addressed.

Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 23, 2015 by Daniel_P._Berrange (27,920 points)   2 4 10
0 votes

On 02/23/2015 11:23 AM, Daniel P. Berrange wrote:
The alternative Nova implementation isnot using fuse, it is using real
mounts on the host FS. This is not a potential issue, it is anactual
issue. There have been bugs in Linux filesystem drivers, including ext4,
that would have allowed a malicous kernel image to crash and/or exploit
the host kernel if mounted.

http://libguestfs.org/guestfs.3.html#security-of-mounting-filesystems

Ok noted -> so why is losetup or qemu-nbd still proposed by nova and
still the default method ?


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 23, 2015 by Raphael_Glon (300 points)   1
0 votes

On 02/23/2015 11:23 AM, Daniel P. Berrange wrote:
Fedora 19 is end of life so not really relevant any more as a target.
powerkvm 2.1.x is not eol


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 23, 2015 by Raphael_Glon (300 points)   1
0 votes

On 02/23/2015 11:23 AM, Daniel P. Berrange wrote:
The alternative Nova implementation isnot using fuse,

yeah you're right -> read your page too quickly
https://www.berrange.com/tags/nbd/

added the term fuse where it should not have been


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 23, 2015 by Raphael_Glon (300 points)   1
...