>
> it's up for interpretation as far as vulnerabilities.
>

Yeah, I am all for implementing good practice by default too, and I
understand this is not optimal.  I purely wanted to make sure AAA didn't
have a huge bug in the middle of it, which was my initial concern sitting
in the Red Sox game when I received the initial message ;).

https://issues.apache.org/jira/browse/KARAF-5540.
>

Cool, Michael.  But AFAICT, in order to do "replacement" we would need to
move odl-jolokia to odlparent from controller to avoid a build loop cycle.
Maybe that should be done anyway?

Another approach could be to fix jolokia to allow configuration changes at
runtime, which I don't think it does at this time.  However, I am not sure
if this was done on purpose in order to prevent dynamically changing
jolokia Authentication strategy at runtime;  I haven't had enough exposure
in that community to fully understand.

Best Regards,

Ryan Goulding

On Tue, Apr 10, 2018 at 5:55 AM, Michael Vorburger <vorbur...@redhat.com>
wrote:

> On Mon, Apr 9, 2018 at 7:49 PM, Jamo Luhrsen <jluhr...@gmail.com> wrote:
>
>> 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?
>>>
>>
> Ryan & Stephen, this https://issues.apache.org/jira/browse/KARAF-5376?
> focusedCommentId=16431939&page=com.atlassian.jira.
> plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16431939 may
> interest you in this regard.. watch also https://issues.apache.
> org/jira/browse/KARAF-5540.
>
>
>> 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.or
>>> g/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.or
>>> g/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/jolo
>>> kia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStat
>>> us/acquireServiceStatus
>>>                 <http://192.168.24.11:8081/jol
>>> okia/exec/org.opendaylight.infrautils.diagstatus:type=SvcSta
>>> tus/acquireServiceStatus>
>>>                                             <
>>> http://192.168.24.11:8081/jolokia/exec/org.opendaylight.inf
>>> rautils.diagstatus:type=SvcStatus/acquireServiceStatus
>>>                 <http://192.168.24.11:8081/jol
>>> okia/exec/org.opendaylight.infrautils.diagstatus:type=SvcSta
>>> tus/acquireServiceStatus>>
>>>                                                                 <
>>> http://192.168.24.11:8081/jolokia/exec/org.opendaylight.inf
>>> rautils.diagstatus:type=SvcStatus/acquireServiceStatus
>>>                 <http://192.168.24.11:8081/jol
>>> okia/exec/org.opendaylight.infrautils.diagstatus:type=SvcSta
>>> tus/acquireServiceStatus>
>>>                                             <
>>> http://192.168.24.11:8081/jolokia/exec/org.opendaylight.inf
>>> rautils.diagstatus:type=SvcStatus/acquireServiceStatus
>>>                 <http://192.168.24.11:8081/jol
>>> okia/exec/org.opendaylight.infrautils.diagstatus:type=SvcSta
>>> tus/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-dev@lists.o
>>> pendaylight.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.or
>>> g/mailman/listinfo/infrautils-dev>
>>>                              <https://lists.opendaylight.or
>>> g/mailman/listinfo/infrautils-dev
>>>                 <https://lists.opendaylight.or
>>> g/mailman/listinfo/infrautils-dev>>
>>>                                       <https://lists.opendaylight.o
>>> rg/mailman/listinfo/infrautils-dev
>>>                 <https://lists.opendaylight.or
>>> g/mailman/listinfo/infrautils-dev>
>>>                              <https://lists.opendaylight.or
>>> g/mailman/listinfo/infrautils-dev
>>>                 <https://lists.opendaylight.or
>>> g/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.o
>>> pendaylight.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.or
>>> g/mailman/listinfo/controller-dev>
>>>                              <https://lists.opendaylight.or
>>> g/mailman/listinfo/controller-dev
>>>                 <https://lists.opendaylight.or
>>> g/mailman/listinfo/controller-dev>>
>>>                                   <https://lists.opendaylight.o
>>> rg/mailman/listinfo/controller-dev
>>>                 <https://lists.opendaylight.or
>>> g/mailman/listinfo/controller-dev>
>>>                              <https://lists.opendaylight.or
>>> g/mailman/listinfo/controller-dev
>>>                 <https://lists.opendaylight.or
>>> g/mailman/listinfo/controller-dev>>>
>>>
>>>
>>>
>
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Reply via email to