Jump to content

Runtime security revisited


This topic is 6128 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Is the following a true statement?:o

[color:green]Anyone with FileMaker Advanced can use Add File Reference to tap into the data file of a distributed runtime -- even though it had been "bound" as a runtime component and Administration Access has been removed.

My testing says it is. Does anyone have a different experience?

Is there a countermeasure? (i.e., a way to prevent it?)

Thanks for any advice.

Link to comment
Share on other sites

Thanks for responding, but I don't understand what you mean. I'm trying to protect a runtime to the maximum extent afforded by FileMaker. I just haven't been able (after reading maybe 100 posts on the subject) to determine exactly what that "maximum extent" is.

Link to comment
Share on other sites

I don't understand what you mean

Simply this: the data files that are associated with the runtime that you built can be opened with FileMaker Pro just as easily as they can be opened with the runtime engine.

What are the threats you're trying to protect against?

Steven

Link to comment
Share on other sites

For my distributed, single-user application, I would like maximum protection against someone viewing my scripts, my custom calculations and my data structures (table and field definitions). By the way, I do use the 2-file separation model (GUI and data).

Link to comment
Share on other sites

For my distributed, single-user application, I would like maximum protection against someone viewing my scripts, my custom calculations and my data structures (table and field definitions). By the way, I do use the 2-file separation model (GUI and data).

You could remove the [Full Access] Account with the Developer Tool utility. This will help to meet this goal. It will not completely guarantee it.

Steven

Link to comment
Share on other sites

Yes, I'm definitely doing that for my released product. But this leads to a variation of my original question:

Since it appears to be true that Add File Reference can be used to tap into a "protected" application, are there additional measures that can taken to prevent that?

Link to comment
Share on other sites

To be 100% honest, I think you're going to waste more time on trying to protect your solution then you will in general.

How many licenses do you think you'll lose to intellegent developers sitting around with their trigger fingers on their mouse sitting around until someone releases a faulty fm application so they can crack it and re-distribute it freely to the world!! LOL, but seriously, most of the people who use my products can barely even open word so... I don't know it depends how much time and money you want to waste for the few licenses you will lose.

If you're actually concerned about security (which i don't think you are given that you are talking about a file which is already open) well that may be a different matter.

Link to comment
Share on other sites

given that you are talking about a file which is already open

Genx, thanks for the added perspective. I'm not sure what you mean by "already open", because I considered that binding and removing admin access was closing (locking down) the files.

Again, what I'm striving for is "protection against someone viewing my scripts, my custom calculations and my data structures".

Link to comment
Share on other sites

I don't mean already open as in insecure.

I mean as in your user logs in, then they open up another FM file and add a relationship -- this can only be done if they have already logged into the main file... but the main danger here is not so much them seeing the internal workings of the scripts and / or your data structure, but rather their ability to execute these scripts remotely from the other file and see the data.

For scripts, data structures and custom calcs -- This is all controllable via FM's security settings. Simply put -- if you want no one to see your inner workings, remove all possible accounts that have access to all this information. Read the help to see what controls what if you're confused.

I'd go into more detail, but i've no time!! argh lol. Should at least help you get started.

Link to comment
Share on other sites

PS, I'll also admit I'm a bit of a "n00b" (is that what the kids say these days :o ) when it comes to making my security sets as efficient as possible. I think I'll do some reading about this in a few weeks and spend a couple of days in seclusion with some files : hehe.

Link to comment
Share on other sites

I understand. I have reading to do, also. I'll try to come up with a summarizing statement along the lines of "if I implement all of the following measures, then where is the application still vulnerable". I'm still trying to identify and understand all of the involved considerations.

Thanks again.

Link to comment
Share on other sites

Boy, someone has sure done an about face...or is it getting older and confronting reality???

If someone wants in, they can get in. I've always worried about users sharing a single copy, more than I have about someone ripping off the whole system (certainly a possibility). Let's see what FM has in store for Version 9.

Steve

Edited by Guest
Link to comment
Share on other sites

Didn't say anything about using dodgey software to get in -- Just that you can probably do more to protect from FM style break ins.

Yes, let's see what FM 9 has in store (though i'm not sure much will have changed :P - but you never know)

EDIT: OHHHH you're not talking abbout me righttttt.

Edited by Guest
Link to comment
Share on other sites

Since it appears to be true that Add File Reference can be used to tap into a "protected" application, are there additional measures that can taken to prevent that?

Essentially not. If the file is open with a particular set of privileges, then it is open with that set of privileges. You must distinguish data table privileges from UI privileges.

Steven

Link to comment
Share on other sites

You must distinguish data table privileges from UI privileges.

I need to mention that my application uses the Guest account to avoid asking the user to sign in -- and that it's provided as a bound runtime with the [Full Access] Account removed.

So, is the best approach simply to define a custom privilege set for the Guest account and set FieldAccess=none for every table? Also, since I'm using the 2-file separation model, it appears that the Guest account needs to be defined that way in both files. Is that correct?

The best way I know to summarize what I'm trying to achieve is a locked-down, single-user runtime with only entry and edit capability, plus field-level exports-- and that hides the data structures and script definitions, of course. This would seem to be a very common requirement for many distributed solutions, but I've found no specific mention of this case in the help files. Any guidance will be greatly appreciated.

Link to comment
Share on other sites

I'm trying to achieve is a locked-down, single-user runtime with only entry and edit capability, plus field-level exports-- and that hides the data structures and script definitions

Are you saying this is possible? -- or not possible. How do you suggest that I proceed?

Link to comment
Share on other sites

This topic is 6128 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.