Schneier on Security

Roger • September 7, 2009 6:54 AM

I have been thinking recently about the “access control” mechanism provided by emailing files around.

Yes, I know that email is not designed for this purpose, and it is in many ways a really awful solution, but it’s interesting to consider why users employ the system. I suspect that it reflects a fundamental brokenness not in the design of how file systems support ACLs, but in the way they are conventionally administered: centralisation of control.

Firstly, consider “DAD” as mentioned above. Alteration and Destruction are largely eliminated because access is granted only to a copy of the document, not to the original. True, confusion can be caused by circulating a modified version, but this can be tidied up by referring to an original. In many ways this is similar to the Wiki model. (As a sort of side-effect this has the feature of creating a sort of Heath-Robinson off-site backup which has the signal advantage of being able to retrieve files without talking to the IT department.)

Disclosure is interesting because it places access control to the document under the transparent, flexible control of the actual information owner — well, sort of. Unfortunately, in the email model you cannot separate access to the document from delegation of the right to distribute the document. Sometimes such delegation is a good thing, sometimes not; it would be good if the two privileges could be separated. Of course strictly speaking it is impossible to prevent a document being copied by someone who is allowed to read it, but a low hurdle is good enough for many purposes.

Requesting access is also simple: the interface combines a search function with a very simple access request! (“Hey Joe, can you send me last month’s financials, please?”)

It’s interesting to compare this to what happens in a typical company. Although a file system can theoretically allow information owners control over their own files’ ACLs, in practice this is usually completely controlled by system administrators on the grounds that it is too hard for mere users. So if a file owner wishes to use the file system to provide access, he or she has to go through the slow, tiresome process of lodging a support request with the IT department — assuming he or she even realises that this is possible, as it generally isn’t advertised.

Often, to ease its own workload the IT department will refuse to do this on a finer granularity than assigning groups to directories, and will get severely pissed off if requests appear more often than a few times per year. In one department for which I worked, not only would we go no finer than groups to directories, but the request had to come from a “section head” who was the nominal owner of a cluster of directories. This meant the poor benighted user had to pester not one but two short-tempered, time poor bureaucrats for every ACL change. As two of the three players in this game were unlikely to even know what an ACL is, this procedure certainly helped to keep IT’s ticket response times down. And don’t get me started on the procedure for editing group membership.

Even worse, it is very difficult for the information owners to determine who has access to their data (a savvy user can see which groups have access, but not who is in the group, and not historic changes to the ACL), and impossible to determine who has actually accessed it. It is possible to log that data, but such detailed logging is rarely turned on, and even if it is, mere users are definitely not provided access to the sacred logs. And whilst it is possible in principle to parse the logs to find out the exact list of who had access at a certain date in the past, this is a major chore even for administrators.

In contrast, with email the actual information owner can assign access to individuals or groups as often or as rarely as he or she wishes, using a transparent, simple-to-understand interface that automatically provides an auditable log that the user can view as often as he or she desires. The only missing features are ability to monitor delegated assignment of access (i.e., forwarding!), and revocation.

I’m not 100% sure where I’m going with this, but I guess the key point is that an effective access control system should leave user authentication and directories to the professionals, but leverage that to put access control in the information owners’ hands, through an interface that is simple, transparent, and easily audited. It could probably be built fairly easily from LDAP and Wikis.

And maybe the standard set of privileges (RWX or RWXD) is sub-optimal, too — too low level. A better set might be to use automatic version control instead of a “write” privilege, and the access properties be “access” (“yes / no”), “delegation” (“yes / no”), and “revocation” (“manual / single access / automatic after n days”). To simplify rules for composing groups, users can be manipulated in groups for ease of adding several at once, but groups are not first class subjects and privileges apply individually. That is, if I add Joe Blow, then add “All Users” of which Joe is a member, and finally remove Joe, then Joe is gone; it doesn’t matter that he was added twice. Ah, it’s late and I am now meandering.