privileges create on table level with security

[RNB-IT]

I ave a question about the security levels in filemaker.

I use a function to get access to the records of the tables based on File Maker Accounts and Privilege Sets  (filemaker 13)

 

in the security tab i use a custom privilege set and set for my table the View , Edit and Delete to custom.

In the calculate tab i use a custom function to set the appropriate access.

that works fine, but why can'y i do the same with new / create, that option is not available

 

View, Edit and Delete  have options; No, Limited... , Yes,

but  Create has only:  No and Yes.

How can i make this work so that some users cannot create new records for certain tables.

[Lee Smith]

Hi RNB,

 

Please update your profile to reflect your current FileMaker version, OS and platform. Here is a quick link for you MY PROFILE

[Steven H. Blackwell]

In the Custom Record Privileges modal window, select the row that has the Table Name.  Then, in the Create popup, select No.

 

 

Steven

[comment]

In the calculate tab i use a custom function to set the appropriate access.

...

 

How can i make this work so that some users cannot create new records for certain tables.

 

What exactly does "some users" mean in this context? Normally, "some users that can do this thing but not another" would be assigned to a privilege set of their own - not determined by a calculation.

[RNB-IT]

In the Custom Record Tab, modal screen there is for the view option an possibility to use an calculation.

I use an database with all users to set the Privileges Set according the users rights. Without adding for each user his own Privilege Set. 

Why not use a calculation the option is available in View Edit and Delete

[comment]

Why not use a calculation the option is available in View Edit and Delete

 

Well, one reason is that the calculation option is not available for the Create privilege - and also for many other privileges, such as access to,layouts, printing, and many more... And there is a good reason why this is so: the calculation option for View, Edit and Delete is provided so that you can allow users to view, edit or delete certain records only (for example, records that were created by them in the first place). It was not meant to allow certain users to view, edit or delete any record.

 

I am not sure what kind of a calculation you are using to distinguish among users, and I suspect it may not be entirely secure. It's certainly not as efficient as using privilege sets (plural!) for this purpose.

[RNB-IT]

I use the Privilege Sets for this purpose

 

for each table,  for each user we define

View                                 1      

Edit View                          1     1    

Create  Edit View              1    1     1     

Delete Create Edit View    1     1    1    1  

 

results binair 1, 3, 7, 15

 

LockUser globalfield contains , "Company = 7;  Contacts = 15; Orders = 7;  Payments= 1"

 

then use a function to extract the result,  SeedCode_GetValue( LockUser; "Company")

This we use in the Privilege Set on the table Company in the Limited... options on View, Edit and Delete on the privilege set

when the result is true the action can be completed,

also it's possible with one or two extra fields to add status levels:

when create an invoice and added some lines, you can't delete the record, 

when the invoice is printed , the user can not edited or delete the invoice.

.... a lot of other,

 

and this all is controlled by the system

 

That reduce the amount of Privilege Sets extreem --> One Set for all users!

BUT the Create option is missing in this set-up.... for a plain database no problem, but for related records it should be available,

Example: when we have printed the invoice,  the system should not allow to to create related records. 

[comment]

What is your question at this point? I think the situation has been clarified.

 

 

That reduce the amount of Privilege Sets extreem --> One Set for all users!

 

As you can see, that is not a good thing.

 

 

Example: when we have printed the invoice,  the system should not allow to to create related records.

 

I believe this could (and probably should) be handled by field validation. That is assuming no one should be allowed to do that, not even admin.

 

 

--

Note that you could deny all users the privilege of creating records in all tables - and provide them with a scripted way to create a new record. The script would be set to run with full privileges, and it could check the existence of your conditions before performing the action.

[Steven H. Blackwell]

This is really the wrong way to manage privileges.  Group users with similar privileges into a single Privilege Set.  Define all the privileges needed for that role.  Then attach as many individual Accounts to that Privilege Set as needed.

 

The system you describe is a target-rich environment for an attack against your files.

 

Steven

[comment]

The system you describe is a target-rich environment for an attack against your files.

 

How so? Bad practice - certainly, inefficiency - most likely, but where do you see a vulnerability?

[Steven H. Blackwell]

How so? Bad practice - certainly, inefficiency - most likely, but where do you see a vulnerability?

How about manipulation of the data in the so-called LockField?

 

Steven

[comment]

I think you are assuming that users have permission to edit the field. I see nothing in the OP's description to indicate that. It's certainly something that's worth mentioning (I thought of bringing it up it myself), but I wouldn't make such a broad-sweeping conclusion until then.

[Wim Decorte]

I think it's pretty much a given that the OP's solution is a lot more vulnerable to manipulation / attack.  Just by moving a crucial security check to the data level.  Even if you can't change that bit of data you may be able to bypass wherever that data is parsed / checked.  If it does get parsed in a variable for instance then that variable can be changed,...

[comment]

I think it's pretty much a given that the OP's solution is a lot more vulnerable to manipulation / attack.  Just by moving a crucial security check to the data level. 

 

I don't see how that's a given. If the data level is inherently insecure, then why bother with security at all?

 

 

 If it does get parsed in a variable for instance then that variable can be changed,...

 

If...

[Wim Decorte]

 If the data level is inherently insecure, then why bother with security at all?

 

 

Really?  So you don't bother locking your doors because houses get broken into?

 

How many products do you know that are 100% and guarantueed-to-always-be secure?

 

Your best protection of a FM file is the FM security scheme.  Anything else is less secure and has been proven to be in many demos over the years.  Do I claim that that FM security is fool-proof?  No.  But it is better than anything you can come up with on the data / scripting level.

[comment]

I think you are breaking an unlocked door (all puns intended...). I am certainly not advocating lax security (see my note as early as post #6 of this thread).

 

However, saying that "just by moving a crucial security check to the data level" the solution becomes "a lot more vulnerable to manipulation / attack" does not make it so. You need to provide a reason.

 

Crucial security checks at the data level are routine. If your security schema specifies that records are accessible when =

Get ( AccountName ) = Table::CreatedBy

then you have a crucial security check at the data level. Does that make it "a lot more vulnerable to manipulation / attack"?

[Wim Decorte]

 

Crucial security checks at the data level are routine. If your security schema specifies that records are accessible when =

Get ( AccountName ) = Table::CreatedBy

then you have a crucial security check at the data level. Does that make it "a lot more vulnerable to manipulation / attack"?

 

The crucial call happens inside the security schema layer in this case.  As it should.

 

 

Contrast that to what the OP mentions earlier in the thread:

"

for each table,  for each user we define

View                                 1      

Edit View                          1     1    

Create  Edit View              1    1     1     

Delete Create Edit View    1     1    1    1  

 

results binair 1, 3, 7, 15

 

LockUser globalfield contains , "Company = 7;  Contacts = 15; Orders = 7;  Payments= 1"

then use a function to extract the result,  SeedCode_GetValue( LockUser; "Company")

This we use in the Privilege Set on the table Company in the Limited... options on View, Edit and Delete on the privilege set

"

 

That clearly shows security information *stored* at the data level.  And that is what makes it vulnerable.

[comment]

That clearly shows security information *stored* at the data level.  

 

I am afraid I see no difference, conceptually, between this and storing the account name in a record. I objected to this (and still do) on grounds of efficiency and good practice - but I fail to see the increased vulnerability (when compared to relying on account name stored in a record).

 

 

 

And that is what makes it vulnerable.

 

As I said before: give me a reason.

[Wim Decorte]

I am afraid I see no difference, conceptually, between this and storing the account name in a record. I

 

An account name is not considered security information.  Almost invariable it is something that is easily guessed.

But let's be generous and say that it is part of the security information.  It is still only part of the "authentication" part, the "who are you" part.

 

Whereas what the OP is storing in a field:

globalfield contains , "Company = 7;  Contacts = 15; Orders = 7;  Payments= 1"

 

is "authentication" information, the "what are you allowed to do"

 

Big difference there.  If I can get my hands on that and manipulate it, it I can elevate my rights, which is more dangerous than guessing an account.

[comment]

You are making a semantic distinction which is irrelevant here, because Filemaker's security engine (and computers in general) do not understand the meaning of data. Let me give you an example that might provide a better illustration to what I am saying:

 

Suppose my business rules state that a salesperson belongs to an office, and has access to the records of that office only. Can you implement this without making the solution "a lot more vulnerable to manipulation / attack" or turning it into "a target-rich environment for an attack against your files"?

[RNB-IT]

The idea is that i want to have a nice layout and a structure to manipulate the Privilege Sets,

and give the administrators of the Solution tools to this without giving them complete acces to all the privilege sets....

 

Why is this bad practice

[Wim Decorte]

Suppose my business rules state that a salesperson belongs to an office, and has access to the records of that office only. Can you implement this without making the solution "a lot more vulnerable to manipulation / attack" or turning it into "a target-rich environment for an attack against your files"?

 

Yes, of course.  By using multiple privilege sets, one for each role / office and Record Level Access restrictions defined within that priv set.

[comment]

Yes, of course.  By using multiple privilege sets, one for each role / office and Record Level Access restrictions defined within that priv set.

 

Sorry, that's not allowed. Offices are at the data level. Client must be able to add/ delete/modify offices without changing the schema.

[Wim Decorte]

The idea is that i want to have a nice layout and a structure to manipulate the Privilege Sets,

and give the administrators of the Solution tools to this without giving them complete acces to all the privilege sets....

 

Why is this bad practice

 

Because you are circumventing the security schema by storing sensitive information about what users are allowed to do at the data level, in records and fields.

[Wim Decorte]

Sorry, that's not allowed. Offices are at the data level. Client must be able to add/ delete/modify offices without changing the schema.

 

Sure; assuming all the proper roles exist as privilege sets, adding an office is not a problem.  There's going to be a personnel table what has info on who is assigned to what office (together with things like their email, phone #,...).  Before you jump all over that: none of that data is security info or sensitive.

The normal RLA features apply here.  RLA dictates what you can see, the priv set dictates what you can o.

 

However if the expansion also means different roles, with authorizations that are different from any that exist in the system then a new priv set needs to be required.  Trying to block that is nonsensical.  That's like saying "we're hiring new people but we don't want to create new accounts or groups in the AD or bind their new machines to the domain".

[rob]

Okay I searched Google even.  RLA.  Obviously it is 'license agreement' right?  But the R?  Registered?  Related?  Remaining?  Russian?  Repair?  It seems there are many meanings of the RLA term so I am looking to know the "RLA features" which apply here.  If you said PLA I would know it is privileges or SLA would be server.  Yes I will probably smack my forehead when you tell me but I still need to ask if you would be so kind to explain.

[comment]

All your reasoning is good towards explaining why OP's proposal is not good practice. However, it has nothing to do with vulnerability. Because when you strip away the semantics and look at the actual mechanism in place, you'll see that what you have here is :



And this is exactly what the OP has, too. There is data in the user's record that determines if the user is authorized to perform some action.

Any vulnerability that exists in the OP's solution, exists in yours too. Any attack vector that could be exploited there, can be exploited here just as well. 

 

 

There's going to be a personnel table what has info on who is assigned to what office  ...  none of that data is security info or sensitive.

 

How do you determine if it is or isn't? The fact is that there is data in the user's record that determines if the user is authorized to perform an action. It doesn't matter if you call it "security info" or "sensitive". It still plays the same role in the decision process.

[Wim Decorte]

Okay I searched Google even.  RLA.  

 

 

 

Record Level Access.  RLA in short.  It's a common abbreviation for the feature that allows you to set a condition in the "record > view" section of a privilege set so that users can only see certain records but not others.  Typical use case: records for their own office, records that they have created,...

[Wim Decorte]

Any vulnerability that exists in the OP's solution, exists in yours too. Any attack vector that could be exploited there, can be exploited here just as well. 

 

 

 

 

 

http://www.owasp.org/index.php/File:2010-T10-ArchitectureDiagram.png

 

 

 

Semantics are important because otherwise we may not be talking about the same thing.  There are many definitions of things like vulnerability, threat, risk.  The linked graphic is just one of the models.

 

Say that there is an attack vector that allows unauthorized users to access FM data.  Or authorized users to access unauthorized data.  That attack vector would apply to both OP's and my solution if it is something in the FM application.  Other attack vectors can be because of the design choices in the solution.

 

The OP's solution would have more weakness because it stores authorization configuration information as data, whereas my solution uses the FM security model.  The probability of someone being able to use the OP's setup to elevate their rights is higher than my solution.  So more risk there.

 

As to determining what is security / sensitive: that's a call-by-call decision and decided based on a security conversation with the client.  Apart from the obvious like SSNs, credit card #s, ...

[comment]

The probability of someone being able to use the OP's setup to elevate their rights is higher than my solution.  So more risk there...

 

In my scenario, Alice works in the Cleveland office. My business rules prohibit her from accessing the records of other offices. If Alice manages to modify the data in her user record, she will breach security and gain access to those records that my business rules were meant to deny her.

In OP's scenario, Bob is a lowly clerk that has read-only access. If Bob manages to modify the data in his user record, he will breach security and gain editing privileges that OP's business rules were meant to deny him.

In both cases, the attack vector is the same and therefore the probability of someone being able to use the (common) setup to elevate their rights is also the same.

The point that you are making is not concerned with the degree of vulnerability of the solution, but with the extent of the possible damage should this vulnerability be exploited. I would tend to agree that it is reasonable to expect the damage in the second case to be more severe. But that's no more than a reasonable guess, we don't know that for sure.  

 

[_ian]

In both cases, the attack vector is the same and therefore the probability of someone being able to use the (common) setup to elevate their rights is also the same.

 

That is not true. While the attack vector may be the same, one approach has poor defences and the other has relatively strong defences. The probability of success is not the same. 

[comment]

one approach has poor defences and the other has relatively strong defences.

 

Because...?

[_ian]

well, Steven and Wim have already explained, but here goes...

 

The built in FileMaker security system is the most secure way to control who gets access to data within a FileMaker database. Home made security systems sit on top of that layer and are predicated on the user having access to certain data that will control what they can see. They usually rely on scripting and trying to prevent access by not displaying layouts -two approaches that are doomed to fail. They're almost always vulnerable to an attacker altering the data the controls what is visible. Over the years I've been asked to look at several of these systems and they were all vulnerable. In most cases a few minutes with data viewer and the design functions gives you everything you need to bypass the system.

[comment]

I am sorry, but I am a little short-timed and short-tempered as well. Have you read this thread at all? We are not talking about what happens "usually". We are discussing the difference in vulnerability between a field that contains "Cleveland" and a field that contains "7".

 

If you think that a solution that checks the contents of the first field before allowing access is somehow less vulnerable than a solution that does exactly the same thing except looking at the contents of the second field, then ... [shrug]

[Wim Decorte]

 

 

If you think that a solution that checks the contents of the first field before allowing access is somehow less vulnerable than a solution that does exactly the same thing except looking at the contents of the second field, then ... [shrug]

 

The risk does not come from checking the field.  The risk is in what the consequences are from being able to manipulate the field.

 

In one scenario if you change the field from "Cleveland" to "Boston"; that's bad because it exposes that is not supposed to be visible.  But the rest of the privileges stand; the user can still not create or delete... (whatever the FM priv set says)

 

In the second scenario; if I can change the 7 to <whatever gives me higher privileges>, now I can do more than what was intended.  That is worse than the first scenario.