> > 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