Forum Discussion

Lewis_Beard's avatar
4 months ago

"Enable Test Script" UIv4 security experiences?

On our portal, I recently noticed the "Enable Test Script" option under the UIv4 security section, because UIv4 recommended I toggle it from Enabled to Disabled. I avoid UIv4 like the plague but as LM forces it on us more and more, I end up having to use it more and more. Maybe in this one case it was a good thing because I wasnt aware about the toggle.

I even reached out to LM and the person who helped me provided a lot of good information but had to look into it himself in terms of sharing documentation because apparently its just a small print mention in a table.

As I suspected when I asked them, switching this to disabled means you cant edit datasources or troubleshoot them in the temp editor window, so therefore you couldnt do anything malicious. I even checked (and so did he, the LM contact) to make sure you cant edit and hit play if you can view datasources when its enabled, you can only do it if you can Manage the Modules.

I verified we have no roles that have Manage except adminstrator, and our administrator list is pretty locked down. We might lock it down a bit more. But basically right now on our portal, only administrators can use the loophole that exists with this enabled, and only they can toggle the setting for the whole portal to disable it, but they can toggle it right back.

So all that being said, what experiences do you all have with this feature? Turning it off seems good, but on the other hand, I already know the administrators and they can toggle it back at any time.

Thoughts?

  • Anonymous's avatar
    Anonymous
    4 months ago

    Modules toolbox has come a long way, but that's not saying much. It's got a long way to go.

    My opinion: Actions that aren't associated with editing the module shouldn't be exclusively in the editor. LM has made the decision to have a "viewer" and an "editor". If they persist in this, they should put things like "show associated devices", "test appliesto", "test active discovery", and "test collection" in the viewer as well as the editor. They do not change the DS, so they don't need to be locked into the editor. That would solve the problem of modifying the script then using the test script button to run some malicious or untested code. 

    My 2nd opinion: they should do away with the module viewer. The editor should be the only way to view the details of a DS. It's where most of the pencils in the new UI take you anyway. Once there, I don't see any harm in having two levels of permissions: 1) read only and 2) read write. The read only users would be able to do anything except change the module. So they would be able to run any of the tests, see associated devices, etc. But the script fields would be locked down. They'd be able to read them, but not modify them. RW would obviously have everything.

    I guess my point is that RO users should be able to test appliesto, discovery, and collection (same as poll now, really) because that doesn't involve a modification, even temporary, of the DS. Creating a new permission level just because you took the lazy route and only checked permissions when someone hits the save button is, well, lazy.

  • Anonymous's avatar
    Anonymous

    What I'd really like is for my engineers, who don't have manage permissions on collectors, to be able to use the poll now button. The output of many of my custom DSs contains helpful debug info that is only needed when investigating deeper. 

    It doesn't make sense that poll now permissions are coupled with manage permissions on the collector. I wish someone from LM could tell us if this was on the roadmap.

  • Anonymous's avatar
    Anonymous

    We have two admins. Everyone else is peons.

  • Makes sense. We decided to try the portal-level toggle just to assess how tedious it is or not. I question the toggle's value at the portal level because admins can already toggle it if they wanted to get spicy. But we are giving it a whirl.

    Appreciate the insight. Your perspective on the issue makes sense to me. I'll see if others see this and reply also, but I appreciate the feedback. Cheers!

  • Have you done anything with that toggle? And if you've toggled it to disabled, have you found it a hinderance? I often do things where the portal toggle is temporarily in opposition. :) Or does your short administrator list make you feel good about leaving it enabled?

    • Anonymous's avatar
      Anonymous
      Lewis_Beard wrote:

      I avoid UIv4 like the plague

       

  • Me too, but the enable/disable exists in UIv3 under the Settings -> Account Information (Portal Settings tab).

    Just wondering what your explicit thoughts are about enabling or disabling, in terms of security vs tedium.

    But I also cant stand UIv4 myself. The recent switch on the LogicModules page to force UIv4 has left me hating myself. :) Or at least the UI. :) I only realized UIv4 forces out installed modules from the exchange side to the "My Module Toolbox" side. Oof. Anyway, side tangent. :)

    • Anonymous's avatar
      Anonymous

      Modules toolbox has come a long way, but that's not saying much. It's got a long way to go.

      My opinion: Actions that aren't associated with editing the module shouldn't be exclusively in the editor. LM has made the decision to have a "viewer" and an "editor". If they persist in this, they should put things like "show associated devices", "test appliesto", "test active discovery", and "test collection" in the viewer as well as the editor. They do not change the DS, so they don't need to be locked into the editor. That would solve the problem of modifying the script then using the test script button to run some malicious or untested code. 

      My 2nd opinion: they should do away with the module viewer. The editor should be the only way to view the details of a DS. It's where most of the pencils in the new UI take you anyway. Once there, I don't see any harm in having two levels of permissions: 1) read only and 2) read write. The read only users would be able to do anything except change the module. So they would be able to run any of the tests, see associated devices, etc. But the script fields would be locked down. They'd be able to read them, but not modify them. RW would obviously have everything.

      I guess my point is that RO users should be able to test appliesto, discovery, and collection (same as poll now, really) because that doesn't involve a modification, even temporary, of the DS. Creating a new permission level just because you took the lazy route and only checked permissions when someone hits the save button is, well, lazy.