1 2 Previous Next 25 Replies Latest reply on Jan 25, 2017 4:50 PM by Malcolm

    Please criticize my quirky security idea.

    Magnus Fransson

      Hi all,

       

      I have an awkward security demand to solve.

       

      At first it seems straightforward: A certain group of users should be able to crate (and edit) records in a table only through scripts.

      -Easy! You say. Just block the group in the security settings, and grant the scripts "Full access".

      -Not enough. I say.

      The problem is that the system uses the "separation model". The records will be blocked in the data file and the script will have "Full access" only in the GUI file.

       

      My suggested solution uses a Global field in a calculated security that only allows access to the table if the Global field contains a specific value. That way the script can manipulate the Global field to temporarily turn on, and then off, the access to the table. And since the Global table are in the GUI file I can even make the Global field require "Full access" to be manipulated by the script.

       

      What I'm thinking of right now is: Any and every way anyone can punch a hole in the solution. And how I can "repair" said holes.

       

      With best regards Magnus Fransson.

        • 1. Re: Please criticize my quirky security idea.
          User26869

          Hi Magnus

           

          First thing that comes to mind is: if any user has got FMPA, they'll be able to tinker with the global variable as they please.

          It might not be an issue if you're 100% sure that none of those users have got a copy of FMPA.

           

          Just a quick thought

           

          Chloe

          • 2. Re: Please criticize my quirky security idea.
            User26869

            Forget about me, somehow I replaced "field" by "variable"...

             

            Oops!

            • 3. Re: Please criticize my quirky security idea.
              philmodjunk

              Another option is to put the "full access" scripts in the data file that are performed from the interface file when needed. It goes against the purpose for using data separation, but it does avoid the issue created by trying to use a "full access" script in the interface file to modify data in the data file's tables.

              • 4. Re: Please criticize my quirky security idea.
                Magnus Fransson

                Hi Chloe, User26869

                 

                No harm done. ;-D

                 

                Those $$Variables can of course be manipulated through the data viewer.

                 

                But that's not why I chose global fields. Variables are local to the file they created in. That means that a variable created in the GUI file can't be accessed in the data file. (I have tried.)

                 

                But by creating the appropriate table occurrence a global field can be accessed anywhere.

                 

                Best regards Magnus Fransson.

                • 5. Re: Please criticize my quirky security idea.
                  Magnus Fransson

                  Hi philmodjunk,

                   

                  It would be a consideration if I starting from scratch.

                  But the demand is a increase of security in a existing solution. The tables, scripts and security groups already exists. So I just want to do "a slight modification".

                   

                  With best regards Magnus Fransson.

                  • 6. Re: Please criticize my quirky security idea.
                    rgordon

                    "But that's not why I chose global fields. Variables are local to the file they created in. That means that a variable created in the GUI file can't be accessed in the data file. (I have tried.)"

                     

                    You can have a script in the data file that Sets the variable with a Script parameter.  In the GUI file call the external script in the data file and pass the variable value with the script parameter.

                    • 7. Re: Please criticize my quirky security idea.
                      Magnus Fransson

                      Hi rgordon,

                      That can be useful in another situation. But Variables still is not suitable in this situation, since they can be manipulated through the data viewer.

                       

                      With best regards Magnus Fransson.

                      • 8. Re: Please criticize my quirky security idea.
                        alecgregory

                        Hi Magnus,

                         

                        I think Phil's solution is the best way to do this. It's simple and secure. That said, your suggested global field approach will work. However, unless you turn on File Access Protection then this is extremely easy to circumvent. You would just have to create a new file, add the data file as an external data source, add the table that contains the global and then set the global field in the same way the script does.

                         

                        Even with File Access Protection, it's possible for global fields to get stuck with the wrong value at file open. If your system crashes in the middle of a script, for example.

                         

                        A side note regarding global variables: these were previously very insecure. However, from FileMaker 15 and later you cannot access the Data Viewer without full access file privileges. Combined with setting the minimum version of FileMaker allowed to open a file to 15 this improves global variable security.

                         

                        Alec

                        1 of 1 people found this helpful
                        • 9. Re: Please criticize my quirky security idea.
                          Magnus Fransson

                          Hi Alec, alecgregory

                           

                          Huge thanks for pointing at File Access Protection! I had missed that. But I have activated it now. (I wonder in which version of FileMaker that was added?)

                           

                          As for putting the scripts in the data file. This is a increased limitation of the users in a existing solution. And the scripts is rather complex, so I do not like the idea of moving them. I prefer to just add a row at the beginning and a other one in the end of the scripts.

                           

                          The ill effects of any crashes is, hopefully, mitigated by the use of FileMaker server.

                           

                          With best regards Magnus Fransson.

                          • 10. Re: Please criticize my quirky security idea.
                            philmodjunk
                            This is a increased limitation of the users in a existing solution.

                             

                            Since this is a script to run with "full access" granted why would the specific number of groups/accounts/privilege sets matter? That would all still be kept the same as you currently have it.

                             

                            And the scripts is rather complex, so I do not like the idea of moving them.

                             

                            There's an import option that will directly import the script from one file into the other. If the table occurrence names are the same in both files, no other changes would be needed.

                            • 11. Re: Please criticize my quirky security idea.
                              wimdecorte

                              Magnus Fransson wrote:

                               

                              Hi Alec, alecgregory

                               

                              Huge thanks for pointing at File Access Protection! I had missed that. But I have activated it now. (I wonder in which version of FileMaker that was added?)

                               

                              FileMaker 11 I believe - it's a HUGE security feature.

                              • 12. Re: Please criticize my quirky security idea.
                                CamelCase_data

                                If the issue is that users should be able to edit records via script only - not a "real security" where they shouldn't have access to the data etc - there's a handy little checkbox in Field Options > Auto-Enter: "Prohibit modification of value during data entry". That, in combination with proper validation criteria for the fields, could be part of a solution to your problem.

                                • 13. Re: Please criticize my quirky security idea.
                                  Malcolm

                                  Even a [Read Only] account is allowed to modify global fields. Have you tested to see that your security control works?

                                   

                                  What happens when some one targets the data file? Using a field in a remote file to secure the data file seems risky. What happens when the GUI file is missing? How does security work then?

                                   

                                  Malcolm

                                  • 14. Re: Please criticize my quirky security idea.
                                    siplus

                                    In the data file you could have empty layouts, having a name (looking like a get(UUID) ), with a trigger onLayoutEnter executing specific scripts, with admin access or not.

                                     

                                    The gui file can go to related records (a dummy rel) using layout name by calculation, and the calc is an ExecuteSQL which pulls a specific layout name from a specific secret table having 2 fields, an ID and a LayoutName. Given the ID you get the LayoutName.

                                     

                                    Nothing to see in DataViewer.

                                     

                                    Off the top of my head.

                                    1 2 Previous Next