Disable DXL ?

Hello,

I am trying to Limit DXL to only Corp. approved scripts. I am able to create a folder and point to it but I am still able to run scripts under the "DXL Libray" if I double-click on them. I would like to limit all users, so that they may only run scripts located in the corp and not run any customs DXL scripts that aren't approved what am I doing wrong?

Thank you,
Jim
SystemAdmin - Tue Dec 20 21:26:04 EST 2011

Re: Disable DXL ?
kbmurphy - Tue Dec 20 23:55:31 EST 2011

You could try trusting your users. If someone is hell-bent on running some DXL, there are ways that they can do so. Instead of pulling your hair out trying to figure this solution out (hint: there are no solutions that will prevent a determined user), you could let your users know that they should speak to you for their DXL needs.

Re: Disable DXL ?
OurGuest - Wed Dec 21 04:27:20 EST 2011

Tounge in cheek, you could always write a trigger that would delete "users" scripts. This would meet your objective and make you famous. Kind of like, "Billy the Kid" famous.

In years to come, it would be amusing to tell your story around the indoor conferences.

Re: Disable DXL ?
SystemAdmin - Wed Dec 21 08:23:37 EST 2011

OurGuest - Wed Dec 21 04:27:20 EST 2011
Tounge in cheek, you could always write a trigger that would delete "users" scripts. This would meet your objective and make you famous. Kind of like, "Billy the Kid" famous.

In years to come, it would be amusing to tell your story around the indoor conferences.

Hello,

If that is the case that you truely cannot limit the execution of DXL then this is a poor design in the way they implement DXL in DOORS. Yes typically you should trust your users but the job of an Admin to to safe guard the data not to trust anyone(a.k.a users).

-Jim

Re: Disable DXL ?
OurGuest - Wed Dec 21 08:44:19 EST 2011

SystemAdmin - Wed Dec 21 08:23:37 EST 2011
Hello,

If that is the case that you truely cannot limit the execution of DXL then this is a poor design in the way they implement DXL in DOORS. Yes typically you should trust your users but the job of an Admin to to safe guard the data not to trust anyone(a.k.a users).

-Jim

If you want to take it to that extreme -- disable the server, that will disable dxl and trust is not required.

Re: Disable DXL ?
mcnairk - Wed Dec 21 08:54:48 EST 2011

Ideas:
  • Use the Windows/Unix permissions to limit user (Read/Execute) access to the files?
  • Add a trigger (although I hate them) that allows only a specified user group to run specified DXLs.

Ken.

Re: Disable DXL ?
SystemAdmin - Wed Dec 21 08:57:16 EST 2011

OurGuest - Wed Dec 21 08:44:19 EST 2011
If you want to take it to that extreme -- disable the server, that will disable dxl and trust is not required.

extreme?? - I don't believe that your IT department would give you local Admin rights to a server. So by not having the capability to limit DXl you are basically giving your users local Admin rights. I know some functionality can only be access via the "Administrator" but that is only a small portion of DXL's functionality. Thank you.

-Jim

Re: Disable DXL ?
Mathias Mamsch - Wed Dec 21 09:10:09 EST 2011

SystemAdmin - Wed Dec 21 08:23:37 EST 2011
Hello,

If that is the case that you truely cannot limit the execution of DXL then this is a poor design in the way they implement DXL in DOORS. Yes typically you should trust your users but the job of an Admin to to safe guard the data not to trust anyone(a.k.a users).

-Jim

You should take into account, that a huge part of the DOORS client is in fact written in DXL. Most dialogs in DOORS, the complete project explorer, etc. are all DXL scripts that ship with DOORS. Therefore you cannot have DOORS without running DXL. I would definitively see the use for only being able to run 'signed' scripts. But since DOORS is 'client' only, meaning the DOORS server having no real purpose other than storing files, this would again only be "security by obscurity". So lets talk about the native low security options first. You can "disable" running DXL (which will just disable some buttons) and enable DXL restrictions on 9.3, which will make it at least uncomfortable for users to run DXL in the client. This will probably throw off 70-80% of your users of running untrusted DXL. The other 20%-30% will still find ways to execute their DXL scripts. In addition you should make your management aware that a) there seems to be a need for DXL scripts if people start using DXL b) they are wasting money with engineers learning DXL not being able to spend their time with their engineering, but solving problems around DOORS. The solution is to establish a central DOORS support, which will not only help the users to get their stuff done but also create and maintain scripts that have a certain quality standard, can be reused among different divisions and can have an eye on how people are using DOORS and derive possible enhancements from that.

However it would be a fun project, to really disable custom DXL as a prove of concept, maybe by hooking certain functions in DXL on global level and deploying that hooks to the clients. These could create an error in case of untrusted scripts (one would need to think about how to make the DXL scripts check if they are trusted, but I guess that could be solvable).

Just some ideas, maybe that helps, Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Disable DXL ?
mcnairk - Wed Dec 21 09:14:32 EST 2011

mcnairk - Wed Dec 21 08:54:48 EST 2011
Ideas:

  • Use the Windows/Unix permissions to limit user (Read/Execute) access to the files?
  • Add a trigger (although I hate them) that allows only a specified user group to run specified DXLs.

Ken.

I forgot:
  • Uncheck "Edit DXL" in Manage Users (this disables the Run button in the Edit DXL window)
  • Put all "official" DXLs in the menu (these can still be run with "Edit DXL" unchecked)

My users don't have access to the server files, so they can't double click on them...

Ken.

Re: Disable DXL ?
SystemAdmin - Wed Dec 21 09:19:44 EST 2011

SystemAdmin - Wed Dec 21 08:23:37 EST 2011
Hello,

If that is the case that you truely cannot limit the execution of DXL then this is a poor design in the way they implement DXL in DOORS. Yes typically you should trust your users but the job of an Admin to to safe guard the data not to trust anyone(a.k.a users).

-Jim

Well, I find these words a bit harsh - how can Telelogic know what you mark as "Corporate Approved" and what not?

Since the client itself consists mainly of DXL, it would not be too great if prevention of all except corporate DXL scripts (and Telelogic scripts - and IBM scripts - and scripts provided by third parties for exporting - and for connecting to other tools - and...) were possible.

You can do your best by a) not allowing users to run dxl without the correct power, b) deleting the delivered scripts of the library, c) modifying the access rights on the DXL library path, so that no one may copy their own scripts there, but as Kevin hinted, the users will find a way, if they really want to.

About your job to protect the data: this can be achieved by setting access rights, writing triggers, splitting up modules etc. etc. If this is done well, your data should be secure enough.

Just my 2cts.
-- Mike

Re: Disable DXL ?
SystemAdmin - Wed Dec 21 09:56:13 EST 2011

SystemAdmin - Wed Dec 21 09:19:44 EST 2011
Well, I find these words a bit harsh - how can Telelogic know what you mark as "Corporate Approved" and what not?

Since the client itself consists mainly of DXL, it would not be too great if prevention of all except corporate DXL scripts (and Telelogic scripts - and IBM scripts - and scripts provided by third parties for exporting - and for connecting to other tools - and...) were possible.

You can do your best by a) not allowing users to run dxl without the correct power, b) deleting the delivered scripts of the library, c) modifying the access rights on the DXL library path, so that no one may copy their own scripts there, but as Kevin hinted, the users will find a way, if they really want to.

About your job to protect the data: this can be achieved by setting access rights, writing triggers, splitting up modules etc. etc. If this is done well, your data should be secure enough.

Just my 2cts.
-- Mike

I am not trying to be "harsh". I know that the client is basically a user interface to DXL. But they could have taken more thought about limiting the execution of custom written script. All scripts that are needed for the execution of the client could have been encryted and have a signature/key to valid IBM approved scripts. While disabling the all DXL functionality inless ran from a directory that was setup by the Admin alone with a signature/key.

-Jim

Re: Disable DXL ?
llandale - Wed Dec 21 12:10:01 EST 2011

OurGuest - Wed Dec 21 04:27:20 EST 2011
Tounge in cheek, you could always write a trigger that would delete "users" scripts. This would meet your objective and make you famous. Kind of like, "Billy the Kid" famous.

In years to come, it would be amusing to tell your story around the indoor conferences.

Yes! A pre-module-open trigger can set DOORSADDINS to the corporate standard denying folks using their own menus. It would also magically disable the "user" and sibling folders. Another option would be to browse the addins and projectaddins variables, find each such offending DXL, and insert at the top:

halt // Big Brother says: <disallowed content detected>

But then they deny themselves Modify access to their own files, and then we counter with issuing:

errorBox("Naughty Naughty"); exit_

But someone would eventually get around that and become even more famous as the "Guy who hacked Billy the Guest".

-Louie

I'm thinking the path of "serenity" may be a more useful than the path of "prevention" in this case.

Re: Disable DXL ?
llandale - Wed Dec 21 12:18:30 EST 2011

There is not much you can do with DXL that you cannot do with the GUI; although using DXL can be dangerous as a fat-fingered mistake can wipe out the attributes of a module etc. Not that I've ever done anything like that while testing my "deleteOldAttrs.dxl" and "purgeOldObjects.dxl" and "deleteInActiveUsers.dxl" or a couple other that didn't quite get me fired.

I don't think you can stop an uncooperative clever person from running whatever they want. But I will say that the "clever" folks are the ones you don't mind running their own DXL as they will make far less mistakes than the clumsy folks.

  • Louie

Re: Disable DXL ?
SystemAdmin - Thu Dec 22 13:00:48 EST 2011

llandale - Wed Dec 21 12:18:30 EST 2011
There is not much you can do with DXL that you cannot do with the GUI; although using DXL can be dangerous as a fat-fingered mistake can wipe out the attributes of a module etc. Not that I've ever done anything like that while testing my "deleteOldAttrs.dxl" and "purgeOldObjects.dxl" and "deleteInActiveUsers.dxl" or a couple other that didn't quite get me fired.

I don't think you can stop an uncooperative clever person from running whatever they want. But I will say that the "clever" folks are the ones you don't mind running their own DXL as they will make far less mistakes than the clumsy folks.

  • Louie

I agree with Louie on this one.

Similar to most database systems, security in DOORS is managed by controlling access to data (not DXL).

DXL does not thwart security. It just allows user to do things they could do anyway with less keystrokes or mouse clicks.

Re: Disable DXL ?
kbmurphy - Fri Dec 23 13:01:21 EST 2011

SystemAdmin - Thu Dec 22 13:00:48 EST 2011
I agree with Louie on this one.

Similar to most database systems, security in DOORS is managed by controlling access to data (not DXL).

DXL does not thwart security. It just allows user to do things they could do anyway with less keystrokes or mouse clicks.

What I find ironic is that the original poster never said what exact problem he was trying to solve--he jumped directly to the solution. This is exactly what requirements authors should not do. Is he worried that someone will delete/create modules in DXL? It's never stated. Just that DXL should be "signed" and controlled. Again, it's coming at DOORS like it's Word or Access or something. And as I've said before, DOORS is not Access.

Kevin

Re: Disable DXL ?
SaBuc77 - Thu Dec 11 11:32:18 EST 2014

SystemAdmin - Thu Dec 22 13:00:48 EST 2011
I agree with Louie on this one.

Similar to most database systems, security in DOORS is managed by controlling access to data (not DXL).

DXL does not thwart security. It just allows user to do things they could do anyway with less keystrokes or mouse clicks.

I have the same problem with limiting DXL only to trusted code.  

Because it's true that DXL allows the same operations that a user could do "manually" but:

1) Through DXL the "speed" of the operations is dramatically increased! So that the possibility of a mistake...

2) Through DXL a user could impose a "process" : create some GUI to do some operations in the way he wants...

We would like to prevent our DOORS users from developing DXL code and using it for example inserting their DXL code in DOORS' menus.

1)    We have considered the "EDIT DXL" power.   This option prevents the users from editing and running DXL in the DXL Interaction window, and from the DXL Library. But the users can still create DXL attributes (and run layout DXL). How can we stop the users from  creating DXL Attributes?

2)   2) We would like to prevent our users from modifying DOORS menus: both DATABASE EXPLORER MENU and the "Menu of a Module". Is it possible to set up any permissions' restriction on the folders "baseWindowsMenuFiles" and "formalFiles" to do that? Or how? 

Re: Disable DXL ?
Mathias Mamsch - Sat Dec 13 13:46:48 EST 2014

SaBuc77 - Thu Dec 11 11:32:18 EST 2014

I have the same problem with limiting DXL only to trusted code.  

Because it's true that DXL allows the same operations that a user could do "manually" but:

1) Through DXL the "speed" of the operations is dramatically increased! So that the possibility of a mistake...

2) Through DXL a user could impose a "process" : create some GUI to do some operations in the way he wants...

We would like to prevent our DOORS users from developing DXL code and using it for example inserting their DXL code in DOORS' menus.

1)    We have considered the "EDIT DXL" power.   This option prevents the users from editing and running DXL in the DXL Interaction window, and from the DXL Library. But the users can still create DXL attributes (and run layout DXL). How can we stop the users from  creating DXL Attributes?

2)   2) We would like to prevent our users from modifying DOORS menus: both DATABASE EXPLORER MENU and the "Menu of a Module". Is it possible to set up any permissions' restriction on the folders "baseWindowsMenuFiles" and "formalFiles" to do that? Or how? 

You should activate DXL Security and restrict DXL scripts only to be run over certain trusted network share. This will also restrict the user from running batch jobs (although DXL Security is very buggy and can easily be circumvented). You cannot prevent the user to create DXL attributes or Layout DXL. You would need a DOORS client patch for that, but you would also restrict the native functionality of the DOORS client drastically this way. You would not be able to use stuff like Analysis Wizard or suspect links anymore.

I think what you are rather looking for is another client. In DOORS Web Access for example users will probably not be able to create / run DXL. Maybe you should get rid of the DOORS client altogether and give the user a special client, which is not a stripped down DOORS client, but rather a client that supports them doing the process exactly like they are supposed to do it.

Maybe you don't even need DOORS, but another tool will be fitting your needs much better. This is not a joke, I am serious about that. DOORS has been designed as a very flexible tool, that does NOT impose a process on the user. Maybe for the use cases you have, DOORS is simply the wrong tool. If DOORS is necessary due to "Data Exchange" procedures or your , you can think about having DOORS only in the background to import/export data to a different system.

In my opinion, trying to make DOORS a different tool is wasted time, because all you will probably end up with, is a very bad different tool. Regards, Mathias

Re: Disable DXL ?
Bob_Swan - Mon Jan 12 07:59:34 EST 2015

SystemAdmin - Wed Dec 21 08:23:37 EST 2011
Hello,

If that is the case that you truely cannot limit the execution of DXL then this is a poor design in the way they implement DXL in DOORS. Yes typically you should trust your users but the job of an Admin to to safe guard the data not to trust anyone(a.k.a users).

-Jim

DOORS was intended to allow users the flexibility to run DOORS to suit their needs not the designers. Why stop at DOORS, do you also stop all use of VB in OFFICE? If you don't want people to write their own dxl make it a company instruction, on pain of being fired, like smoking or fighting. My users don't want to write difficult 'C'/dxl, they want to do the engineering they get paid most for.