it's up for interpretation as far as vulnerabilities.
seems by default, the vulnerability is there. However, one can argue that users
need
to RTFM, go restart their deployment, ya da ya da ya da (hi robert...) to avoid
the non-authenticated jolokia endpoints.
JamO
On 4/9/18 10:44 AM, Ryan Goulding wrote:
Cool, so there shouldn't be any gaping vulnerabilities as was originally indicated? Not sure what is installed for
features by default anymore, but "jolokia" is part of the karaf standard features we pull in [0]. Stephen, do you know
of anyway to strip that out?
Thanks,
Ryan
[0]
https://github.com/apache/karaf/blob/karaf-4.1.x/assemblies/features/standard/src/main/feature/feature.xml#L1446
On Mon, Apr 9, 2018 at 1:38 PM, Jamo Luhrsen <jluhr...@gmail.com
<mailto:jluhr...@gmail.com>> wrote:
ok, yeah. after restarting, it seems the jolokia endpoint is now adhering to
the proper credentials.
I'm confused about the karaf jolokia stuff though. Is there no way to dump
that and only allow our odl-jolokia feature to be available? That was
pretty confusing to me. I never asked for anything jolokia to be installed
originally, but I guess it was by default.
JamO
On 4/7/18 1:07 PM, Ryan Goulding wrote:
Did you restart ODL after installing odl-jolikia? The issue is you have
jolikia installed from karaf without
auth, then try to install odl-jolikia which lays down
org.jolikia.osgi.cfg with authMode set to delegate. That
managed service won’t actually recognize the update to authmode without
a restart of Karaf. You want to ONLY
ever install odl-jolokia!!
Sent from my iPhone
On Apr 7, 2018, at 12:19 PM, Jamo Luhrsen <jluhr...@gmail.com
<mailto:jluhr...@gmail.com>> wrote:
ok, I verified that carbon sr3 is working as we expect, but the
recent Fluorine
snapshot distro I have is not behaving like I expect.
I am able to hit this
jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus
endpoint after just installing features-aaa, nothing else. The
user/password doesn't
seem to matter.
After installing odl-jolokia, it's the same behavior.
should I open a jira, or what other info can I gather?
Thanks,
JamO
On 4/5/18 3:45 PM, Ryan Goulding wrote:
for carbon-sr3 we still hadn't integrated jolokia with AAA; it
was still backed by
etc/org.jolokia.osgi.cfg, hencewhy you need to use admin/admin
after changing the password in AAA.
How did you install jolokia in Fluorine? You must install using
"odl-jolokia" feature from controller
to get protection. Standard off the shelf "jolokia" has NO
auth by default...
Regards,
Ryan Goulding
On Thu, Apr 5, 2018 at 6:23 PM, Jamo Luhrsen <jluhr...@gmail.com
<mailto:jluhr...@gmail.com>
<mailto:jluhr...@gmail.com <mailto:jluhr...@gmail.com>>> wrote:
I don't have access to my setup at the moment. I can later.
but, I think it's based on carbon sr3.
I do have a recent (2/27) snapshot distro from Fluorine
though,
and that actually doesn't even need creds to access that
jolokia diagstatus endpoint. restconf still behaves like I
expect, but the diagstatus endpoint takes any (or no)
username/password combo.
JamO
On 4/5/18 12:06 PM, Ryan Goulding wrote:
Jamo, can you comment on code version? Thanks!
Regards,
Ryan Goulding
On Thu, Apr 5, 2018 at 7:10 AM, Ryan Goulding
<ryandgould...@gmail.com
<mailto:ryandgould...@gmail.com> <mailto:ryandgould...@gmail.com
<mailto:ryandgould...@gmail.com>>
<mailto:ryandgould...@gmail.com
<mailto:ryandgould...@gmail.com>
<mailto:ryandgould...@gmail.com
<mailto:ryandgould...@gmail.com>>>> wrote:
What version of code? This wasn’t tied to AAA
until oxygen. Prior it was controlled by
etc/or.jolokia.osgi.cfg.
Thanks,
Ryan
Sent from my iPhone
On Apr 5, 2018, at 12:32 AM, Michael Vorburger
<vorbur...@redhat.com
<mailto:vorbur...@redhat.com> <mailto:vorbur...@redhat.com
<mailto:vorbur...@redhat.com>>
<mailto:vorbur...@redhat.com
<mailto:vorbur...@redhat.com> <mailto:vorbur...@redhat.com
<mailto:vorbur...@redhat.com>>>> wrote:
JamO, +aaa-dev and +controller-dev and
Stephen FYI:
On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen
<jluhr...@gmail.com
<mailto:jluhr...@gmail.com> <mailto:jluhr...@gmail.com
<mailto:jluhr...@gmail.com>>
<mailto:jluhr...@gmail.com
<mailto:jluhr...@gmail.com> <mailto:jluhr...@gmail.com
<mailto:jluhr...@gmail.com>>>>wrote:
Hi Utility folks,
I noticed in a local setup I have where
I've changed the default username
and password for RESTCONF, that I still
need to use the admin:admin creds
to hit the diagstatus endpoint.
I'm guessing that's just because this is
not tied in to the magic of
AAA and/or RESTCONF creds.
Gotta just live with it, or would it be
an easy thing to add, just to keep
things more intuitive?
This seems like a bug (bad one, security
wise), but it's not for infrautils-dev - we
don't actually do
anything
re. Jolokia in project infrautils, the
diagstatus sub-module simply exposes a JMX
bean... the code
related to the
Jolokia integration in ODL which then make
makes this available via HTTP, and secures
it with the AAA
creds (also
used by RESTCONF; there are no creds in
RESTCONF itself FYI), is actually in
controller and/or aaa (I'm
not 100%
sure myself what is where)... see
https://jira.opendaylight.org/browse/AAA-147
<https://jira.opendaylight.org/browse/AAA-147>
<https://jira.opendaylight.org/browse/AAA-147
<https://jira.opendaylight.org/browse/AAA-147>>
<https://jira.opendaylight.org/browse/AAA-147
<https://jira.opendaylight.org/browse/AAA-147>
<https://jira.opendaylight.org/browse/AAA-147
<https://jira.opendaylight.org/browse/AAA-147>>> and
https://jira.opendaylight.org/browse/CONTROLLER-1324
<https://jira.opendaylight.org/browse/CONTROLLER-1324>
<https://jira.opendaylight.org/browse/CONTROLLER-1324
<https://jira.opendaylight.org/browse/CONTROLLER-1324>>
<https://jira.opendaylight.org/browse/CONTROLLER-1324
<https://jira.opendaylight.org/browse/CONTROLLER-1324>
<https://jira.opendaylight.org/browse/CONTROLLER-1324
<https://jira.opendaylight.org/browse/CONTROLLER-1324>>>.
If you are right, we have this problem (that
when changing the default username and
password you can
still use the
previous one) on *ALL* /jolokia/ URLs, I'm
guessing.
Would you like to open a (Critical?) bug in
JIRA against AAA about this?
Tx,
M.
--
Michael Vorburger, Red Hat
vorbur...@redhat.com <mailto:vorbur...@redhat.com>
<mailto:vorbur...@redhat.com
<mailto:vorbur...@redhat.com>> <mailto:vorbur...@redhat.com
<mailto:vorbur...@redhat.com>
<mailto:vorbur...@redhat.com
<mailto:vorbur...@redhat.com>>>| IRC: vorburger @freenode | ~
= http://vorburger.ch
<http://vorburger.ch/>
example curl:
curl -u "admin:admin"
http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus
<http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus>
<http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus
<http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus>>
<http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus
<http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus>
<http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus
<http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus>>>
Thanks,
JamO
_______________________________________________
infrautils-dev mailing list
infrautils-...@lists.opendaylight.org
<mailto:infrautils-...@lists.opendaylight.org>
<mailto:infrautils-...@lists.opendaylight.org
<mailto:infrautils-...@lists.opendaylight.org>>
<mailto:infrautils-...@lists.opendaylight.org
<mailto:infrautils-...@lists.opendaylight.org>
<mailto:infrautils-...@lists.opendaylight.org
<mailto:infrautils-...@lists.opendaylight.org>>>
https://lists.opendaylight.org/mailman/listinfo/infrautils-dev
<https://lists.opendaylight.org/mailman/listinfo/infrautils-dev>
<https://lists.opendaylight.org/mailman/listinfo/infrautils-dev
<https://lists.opendaylight.org/mailman/listinfo/infrautils-dev>>
<https://lists.opendaylight.org/mailman/listinfo/infrautils-dev
<https://lists.opendaylight.org/mailman/listinfo/infrautils-dev>
<https://lists.opendaylight.org/mailman/listinfo/infrautils-dev
<https://lists.opendaylight.org/mailman/listinfo/infrautils-dev>>>
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
<mailto:controller-dev@lists.opendaylight.org>
<mailto:controller-dev@lists.opendaylight.org
<mailto:controller-dev@lists.opendaylight.org>>
<mailto:controller-dev@lists.opendaylight.org
<mailto:controller-dev@lists.opendaylight.org>
<mailto:controller-dev@lists.opendaylight.org
<mailto:controller-dev@lists.opendaylight.org>>>
https://lists.opendaylight.org/mailman/listinfo/controller-dev
<https://lists.opendaylight.org/mailman/listinfo/controller-dev>
<https://lists.opendaylight.org/mailman/listinfo/controller-dev
<https://lists.opendaylight.org/mailman/listinfo/controller-dev>>
<https://lists.opendaylight.org/mailman/listinfo/controller-dev
<https://lists.opendaylight.org/mailman/listinfo/controller-dev>
<https://lists.opendaylight.org/mailman/listinfo/controller-dev
<https://lists.opendaylight.org/mailman/listinfo/controller-dev>>>
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev