I think we’ve hit a security problem with groups in the ACL and I’d welcome any help anyone can offer.
Imagine this situation:
You are a notes development house
You have a client using domino
You give them a database - all their users only have editor access and are in a group called “ClientUsers”
Your developers are members of a group called “DevHouseUsers”. This group is in the ACL as manager
An admin user at the client site looks at the ACL of the database and sees the group entry.
They then create (or modify if existing) a group document on their server address book - they call the group “DevHouseUsers” and add themselves.
Bang - they have Manager access as the ACL gives them the highest access.
I know that the access rights will favour the lowest (Create, Delete, etc), but this still seems like a huge security hole.
Any comments? have I gone off half cocked here?
Cheers
K
Subject: Groups in ACL - potential security hole??
Hi,
no security hole. Thats how it works (has to).
If your question is if you can give someone a replica of a database and force him to only have a specific access-level lower then manager on his copy, then the answer is NO. There is always a way how to “break in”. (Actually there is no difference if you give it to a user as a local replica or to your customer on a server)
You have to keep in mind that ALL data in THEIR replica can always be READ and MODIFIED.
However it is a completly different part if the user (or your customer) can replicate changed data BACK to your system. This is where the real security starts.
Real security in Notes is on document-level with reader/author fields. With these you can manage it that way that some documents will never be replicated to your customer (reader fields) or if they are that the changes will not come back (authors). (… an other option is encryption but this does not matter.)
The real question that you have to tell is what do you want to protect ?
If it is the design of your database? Then hide it !
If these are “data” documents then make sure that they don’t get there at all or encrypt them ?
Bye
Hynek
PS: By the way the admin of your customer can simply turn on “Full Administration” rights and see any documents or modify the ACL at will.
Subject: Some ideas (none of them are perfect!).
An interesting topic this one and an enjoyable challenge when you are waiting
for replies to your own post :o) As others have pointed out, there is no
perfect solution to this if you let your application sit on servers you do not
control.
But you can make it demonstrably protected from ‘reasonable’ abuse; Here are
some ideas (I am assuming you replicate the DB to your customer’s server):
UL>]
LI>]When you give the application .NSF to the customer, do NOT use enforce
consistent ACL, then use selective replication to prevent ACL replication
between you and them:
UL>]
LI>]In the ACL on their replica:
UL>]
LI>]Only grant Manager access to your server and while you are setting up the
application, an administrative ID you own e.g. // (that has access to the customer’s server).
LI>]Only grant their staff a maximum of Author access, then use ACL Roles,
AUTHOR/READER fields & Access Controlled Sections to control access to read,
create and edit the various document types/specific sections in documents.
/UL>]
LI>]In the ACL on your server you can put in whatever groups etc. you like.
Obviously you would put your customers server with less than Designer!
/UL>]
LI>]Encrypt the .NSF on the customer’s server with their server’s ID (to
prevent their admins trying to hack it locally).
LI>]In the databases’s Open event you can add code to process the ACL and if
your code sees entries that you do not permit in the ACL with Manager access
then you can take action e.g. Log to a document type in the application that is
not selected by any user-facing views, send an e-mail back to you etc. Further,
if the entity opening the database has Manager access you could make the code
remove the offending entries from the ACL.
LI>]For actions that you want to protect you can start by hiding them with
ACL Roles, then code them to check what server they are being run from and
abort if it is not your server(s). I know this is a bit of a nasty hack, but if
you store the permitted servers list in a profile document then it is
reasonably manageable.
LI>]If there are some special fields in documents that only need to be
accessed by your staff, then generate an encryption key that is only given to
your staff and encrypt the field(s) with that key.
LI>]When the app is rolled out you could hide the database design - This
means that even if the ACL is breached, they cannot disable your ACL reporting
code that runs when the database is opened.
/UL>]
This would protect you from superficial attempts to muck about with your
application. If you remove the “//” ID
from the ACL on the customer’s replica and then manage changes only from your
end that presents them with a challenge (you can always run agents under your
server’s ID to ‘inject’ ACL entries into the customer’s replica at a later
date).
Anyhoo, I’d better stop before I get flamed for writing a “How to hack” guide;
Like folks have said, as long as they have your application hosted on their
server you have lost total control. How far you go depends on the criticality
of the application; If super-critical then host it on an Extranet server you
own then and provide your customer with access over the web/SSL, or a direct
Notes connection over port 1352 (remember to disable replication, as this opens
up possibilities and don’t trust the R6 ACL option for “Replicate or copy
documents”, as this is ignored by earlier Notes clients (IRIS, I really wish
this was enforced by the server!)).
gl
Subject: Tags, grrrrrr 
There’s me formatting my post with indented bullets that previewed fine and when I post it gets screwed up!
Sorry, hope you can make it out!
Subject: Start accessing this db with a Notes client.
You can actually use rich text formatingFonts
Colors
Subject: RE: Some ideas (none of them are perfect!).
Why are people trying to propose solutions to this? There isn’t one. Full Access Administration makes all of this stuff irrelevant.
A Domain Administrator controls the apps on his server. Period. End of story. Do not pass Go.
Why are people trying to find some way around this?
And James, email me. nathan at openntf dot org I’ll share a secret with you.
Subject: RE: Some ideas (none of them are perfect!).
I never said my suggestions were a solution, just that they would make it harder to abuse, so one might consider the application ‘reasonably’ secured.
Subject: Groups in ACL - potential security hole??
One other thing: I’m sure it’s way too late to do anything about it for this application and there may very well be good reasons for not doing it this way, but you could sort your potential permissions problems quick if you made this web-based, at least for their part. If they get into the database through a web interface, it remains entirely hosted on your server rather than having to exist on theirs as well
Subject: Groups in ACL - potential security hole??
Kieran,
Yes, this is a problem, so you have to think about it in advance. For example, do you need to have a group with manager access? Why not use an Admin ID that has manager access, and set your group as designer? That way, no-one can change the ACL, although they still can get higher up the ACL levels if they create a group.
Basically, there are 3 solutions.
a) Trust the admins that they wont try and do this
b) Not use groups, use explicit names (nasty, if you’ve got a lot of users)
c) Use your certifiers. For example, add */support/yourcompany as designer/manager, and */users/yourclient as editor/reader/whatever
Hope that helps
Ben
Subject: RE: Groups in ACL - potential security hole??
b) Not use groups, use explicit names (nasty, if you’ve got a lot of users)>c) Use your certifiers. For example, add */support/yourcompany as designer/manager, and */users/yourclient as editor/reader/whatever
How will this protect against a full access administrator?
Hans Haraldsen
Subject: Groups in ACL - potential security hole??
It’s not a security hole. It’s just an aspect of how Notes works. A domain administrator can modify ANYTHING within his domain. If he didn’t want to great a group called “DevHouseUsers,” he could just as easily allow himself Full Administration Access.
Subject: Effective Rights - Monitoring changes
As said before, if you don’t own the server, you don’t have total control.
As groups and groups within groups (in groups) could make it very messy to find out what rights somebody really has, we developed a report that shows the effective rights of people on databases (and what causes that level of rights). Because you can also schedule those reports, you can monitor and log changes.
It’s a commercially sold product (US$999), but i would argue that an example like this makes it worth the investment.
www.integra4notes.com/admins
Subject: Groups in ACL - potential security hole??
How is that a security hole? It’s difficult for me to imagine a set of circumstances under which administrators shouldn’t have or shouldn’t be allowed to assign full manager access to a database on their own servers. What are you trying to achieve here? If you’re trying to, say, keep them from getting into your source code, there are other (and far more suitable) ways of doing that.
Subject: RE: Groups in ACL - potential security hole??
Not so much the source code - you can hide the design.
It just seems really odd that when enforce consistent ACL is selected, with our server as the admin server, that they can bypass the security just by editing their address book. Surely the contents of the groups on the admin server should be what is used by the database??
Subject: RE: Groups in ACL - potential security hole??
Surely not. I’m also missing the point, I think, of making the admin server external. Shouldn’t resolution of renaming (Readers and Authors fields) be based on, say, the address book that contains the user population?
Subject: RE: Groups in ACL - potential security hole??
Don’t get me wrong, I can see the sense in how it is set up.
But could you explain how we could set a database up using an admin group for our users, without creating the possibility for their admins to circumvent the ACL?
for example, but doing this, they get:
-
manager access, and the ability to edit ACL
-
Access to areas restricted by roles assigned to our group - for example, the ability to raise documents which must only be raised by our users. This is controlled using the security on the last tab of the form properties - how else would we acheive that??
Like I said, I see the sense in being able to administer it, but how do you prevent a rogue admin fouling things up, short of accompanying our application with another physical server, essentially expanding our domain physically into their office…
Am I being unreasonable?
Subject: RE: Groups in ACL - potential security hole??
You can’t, really – and that’s why an admin, in any system, is a highly-trusted position. All you can do, really, is put great whacking warnings all over any config items, including a “you break it, you pay to have it fixed” message.
Subject: RE: Groups in ACL - potential security hole??
That’s fair enough, but it doesn’t make us or Lotus/IBM look very good if the client we’re offering services to can hack the ACL that simply … especially when one of the big selling points of notes going back to the earliest versions is the build in security.
I’ll get off me soap box, and stop me foul-mouthed whining - I know that’s what you’re all thinking 
Subject: RE: Groups in ACL - potential security hole??
By that particular measure (which you may see as hacking but I see as a proper and appropriate use of well-known features), Notes is no less secure than Oracle, Exchange, or any other system. At some level, there are people in charge of the system who simply cannot and should not be locked out from their godlike functions, because if you do, the system can break down and not be fixable. You’ve hit the insoluble problem: how do you protect things from the people who run the system. It’s not a new problem, by any means. It was about two thousand years ago that Juvenal asked “quis custodiet ipsos custodes?”
Subject: And it was only 1985 when Jello Biafra asked, “Who will babysit the babysitters?”