Fragile UI? Don’t do it “on my behalf!”
Is the agent property “Run On Behalf Of” dangerous? Sure, you might say, but it’s obviously dangerous--a low-level access that should be granted with great care.
But I think that the UI in the Security tab of the Domino server document is a bit fragile or unclear on the significance of granting certain rights. As developers we sometimes talk about “fragile code”--code that works but is hard to change without creating bugs or other cascading effects. Changing it without fully understanding it can be dangerous. (more)
But I think that the UI in the Security tab of the Domino server document is a bit fragile or unclear on the significance of granting certain rights. As developers we sometimes talk about “fragile code”--code that works but is hard to change without creating bugs or other cascading effects. Changing it without fully understanding it can be dangerous. (more)
I have to confess that I hadn’t needed to set agents to “Run on Behalf” until I recently began working on code to automatically set the property during application builds/deployment. So I started playing with it during unit testing.
It is cool, and dangerous, and I was able to sign agents as myself and get into databases I wasn’t in the ACL of by assigning the appropriate “Behalf of” user. Fine. A little unnerving that I might be enabling the abuse of this “feature” but I was okay with it.
Then, I began to feel a desire to see it work in the inverse: I took myself out of the “Sign agents to run on behalf of someone else” field in the server document. I rebooted the server. My agent ran, still, without an error. Then, I didn’t feel so good.
So I took myself out of the “Run Unrestricted Methods” field.
[mind you not until I actually opened the Administrator Help and reread this sentence buried in the intro paragraph of the “Controlling Agents…” document: “A user or group name in one list will automatically receive the rights of the lists beneath. Therefore a name has to be entered in only one list, which then gives that user the highest rights.”]
Ok, so rights cascade. I bounced the server again. And it still ran. It wasn’t until I took myself out of the “Full Access Administrators” group that an access error got logged.
It seems to me that the danger, here, beyond that the feature is scary to begin with, is that looking at the security configuration doesn't clearly tell you what rights you are granting. And granting just anyone rights that could allow them to, say, clandestinely read the CEOs email or change salary information with the signature of the CFO is a BAD idea.
It is cool, and dangerous, and I was able to sign agents as myself and get into databases I wasn’t in the ACL of by assigning the appropriate “Behalf of” user. Fine. A little unnerving that I might be enabling the abuse of this “feature” but I was okay with it.
Then, I began to feel a desire to see it work in the inverse: I took myself out of the “Sign agents to run on behalf of someone else” field in the server document. I rebooted the server. My agent ran, still, without an error. Then, I didn’t feel so good.
So I took myself out of the “Run Unrestricted Methods” field.
[mind you not until I actually opened the Administrator Help and reread this sentence buried in the intro paragraph of the “Controlling Agents…” document: “A user or group name in one list will automatically receive the rights of the lists beneath. Therefore a name has to be entered in only one list, which then gives that user the highest rights.”]
Ok, so rights cascade. I bounced the server again. And it still ran. It wasn’t until I took myself out of the “Full Access Administrators” group that an access error got logged.
It seems to me that the danger, here, beyond that the feature is scary to begin with, is that looking at the security configuration doesn't clearly tell you what rights you are granting. And granting just anyone rights that could allow them to, say, clandestinely read the CEOs email or change salary information with the signature of the CFO is a BAD idea.
Category Coding Practices
| Permalink |
|
|
|
|
|
Comments
Basically, the server is doing the same thing it would if you set the agent to "Run as Web User," then logged in with that user's account, and did ?OpenAgent.
It's not a bit different.
Posted by Nathan T. Freeman At 03:58:32 PM On 11/15/2007 | - Website - |
But I do think it's a bit different than "Run as Web User" -- I don't need to log in as the user at all, simply type their name in the behalf-of box. I don't need their password or internet password.
Posted by Matt Vargish At 05:25:04 PM On 11/15/2007 | - Website - |
If you can edit person docs in the Address Book, then you have pretty much the same effective authorities as Run on Behalf Of.
Posted by Nathan T. Freeman At 10:27:01 AM On 11/19/2007 | - Website - |
Where I have doubts is really in how it's documented and the visibility of it to the average administrator.
For example: Let's say a developer is granted "Run unrestricted methods" rights to a development server because he's developing code that works with attachments. Is it obvious that this confers "on behalf of" privileges?
Take it a step further and suppose that - rightly or wrongly - the development server is a "trusted server" to a production app or mail server... Now that developer can write an agent that accesses files on another server while impersonating another user.
I tried this with two test servers (trusted, but in two separate domains). User A creates an agent on server A to run on behalf of User B and target a database on Server B to which User A doesn't have access. User A has no elevated rights on Server B, but the code runs and modifies documents acting as User B...
Again, this probably is correct behavior, but my point is that there doesn't seem to be any clarity in the documentation or in the form itself about the security risks involved or how to configure server security appropriately when using this feature.
Posted by Matt Vargish At 11:43:31 AM On 11/19/2007 | - Website - |
Ah, well on these fronts, Matt, I heartily concur. The explanations are inadequate. But I'm willing to cut the security team some slack in not setting off alarms, which would more than likely lead to policies where it was simply impossible for developers to get anything done.
Take the "unrestricted agent" rights. If I have unrestricted agent rights on a server, it's pretty trivial for me to steal the server's ID file -- which is 90% likely to be unprotected with a password, thus allowing me to forge myself as that server in any multi-server environment with ease. Or, if I didn't want to worry about a "run on behalf of," I could just run an agent on the server that would find some other agent, sign it, then .run the signed agent. Voila, it's executing with server priviledges.
Priviledge escalation techniques are not terribly well understood by the Domino community at large, and while I agree that education about them is important, I'm not certain that cramming it into the address book is the right way to go. Some documentation in the HELP might work, but again, we should remember that over-education is often the policy-maker's excuse for refusing to grant permission for ANYTHING.
Perhaps the meat of the problem is that it's too often necessary to grant some of these escalated rights to get workable solutions in place. Perhaps if we had more fine-tuned controls, then we could reduce the risk. "Run restricted" vs. "run unrestricted" is a pretty blunt instrument, especially in light of all the fine details we get from the ECL. Perhaps we should simply lobby IBM to apply the administration ECL to agent-based code on the server, and deprecate the "run unrestricted" model?
One big help would be to have a sandbox for local file access, so I could say "allowed to access TEMP subfolder in server's data folder" vs. "allowed to access entire OS file system." There's lots of local file operation stuff that people need because of programming limitations in Domino -- so maybe isolating just that part would help.
Of course, there's always the principle of actually locking down unrestricted rights, and establishing proper goverance procedures for peer code review and deployment -- so we can actually say that only approved code is executed in the environment. But that's asking a lot of most businesses, isn't it?
Posted by Nathan T. Freeman At 09:45:18 AM On 11/25/2007 | - Website - |