OS-agnostic way to set permissions and encrypt files

Question

A friend of mine is physician and shares his office with other physicians (they're all psychiatrists). They're looking for a not to pricey and secure way to share and store files (basically text-only notes and reports) on a server (preferentially running Ubuntu Linux) over the LAN.

They need to be able to dynamically set the permissions on certain files: Sometimes physician A needs to give read access on a certain file to physician B and remove it again. Or physician B and C need read/write access on a certain file that physician A has no access at all.

Besides that, it's very important that no other person can read those files even if this person would gain physical access to the server.

They're not into memorizing hundreds of passwords, so I'm also looking for some kind of OS-agnostic SSO solution maybe even using a hardware token.

On the clientside, they all have different workstations (Windows XP, Linux and OSX).

I was thinking of a solution using TrueCrypt in combination with eTokens, so no matter where the files are saved, they're always encrypted and can only be read by people having the permission to.

Does anyone of you have a better idea or could you point me to a similar setup/howto? Or would you just setup a smart intranet webapplication by yourself in this case?

Answer 1

Sounds like a very difficult situation to handle without using some integrated package that has document management features. My own company sells a product that we sell into medical organizations to create\scan, store, and manage images and text information, and there are a bunch of features just designed around securing the information. One the of the big concerns for such organizations, btw, is HIPAA regulations, which is why I assume your customer wants encryption of the files.

BTW, HIPAA not only has strict requirements for protecting data but also requires logging access to it, so simply encrypting data may not be sufficient.

Outside of that comment, trying to give non-tech people "full control" over files and folders where they have to constantly manage and change permissions (and maybe encryption status for individual files) for other users is, IMHOO, a recipe for frustration.

Answer 2

I agree with Schmitty23 .. I think it is a mistake to manually manage the permissions .. it is highly prone to errors and difficult to manage. I suggest a simply configured document management system.

--> http://www.knowledgetree.com/
--> http://www.openkm.com/
--> http://contineo.sourceforge.net/features.html
--> http://www.alfresco.com/

Response to Javier's comments.
a- No DMS is as intuitive as "File/Open/Save", but permissions are far easier to deal with than file system security. Set it up simply and the users will adjust.
--> THEY WILL LOVE VERSION CONTROL.
b- I have no idea about encryption, although I imagine the OS can encrypt the file system. Some systems can store the docs themselves in the database, which could also be encrypted.
c- I have not used any of these ... they came up in a search of "Ubuntu Document Management". I have used Plone, which I did not include because it was a pain.

Answer 3

I think you have described the simplest use case for Multi Level Security. There is an implementation of MLS in Fedora but I know nothing about it.

Security is a pain. There will always be tradeoffs.

SAMBA properly configured might solve your problem. Imagine each doctor has two shares, one exclusively private and another shared only with all the other doctors.

Since I do not see a way around multiple passwords, each physician would have to manage a list of passwords with some password management application like PasswordSafe and keep the password DB in their private share in a TrueCrypt volume. They would need to memorize three passwords at most: one for their machine, another to mount the SAMBA share, and another for the password management application.

In the private share they would keep a TrueCrypt volume containing their for-their-eyes-only information. In that TrueCypt volume they would have one directory per patient. Or they would have one TrueCrypt volume per patient plus one for administration.

In the shared share they would create a directory for each combination of doctors able to view the information. Yes, I know, there would be an explosion of combinations; this so called solution does not scale. Suppose there are 10 doctors, that would mean 2^10 (=1,024) possible directories. But I think that this practice is much smaller. The directories should have a standardized naming convention that indicates who the directory is shared with. Each directory would be scanned regularly to insure the proper permissions are enforced.

The problem with TrueCrypt is that only one person mount a particular volume at the same time.

You can flesh the rest out from here.

Answer 4

One more comment .. my experience tells me that doctor types like to feel like they have full control over their information, but also never want to have to understand why problems arise with poorly designed IT systems, especially when it's due to the way they decide to use it. So they might say they want to constantly monitor "their" files and manage access by other users, but in reality will probably never do it well, causing problems for them or the other users in the office.

If they insist on going this route, you might want to manage access via shares; Give each provider a share of their own, private to them and only they have permissions. Have them store all files there.

Make a shared folder, perhaps with subdirectories for each user and one "public" subfolder. For each user, map a drive to the personal subfolder (shared\doctorX) and map one to the public folder (shared\public)

When a Doctor wants to give access to a doc, they can move or copy from their private directory - to either the shared\Doctorx folder if they want one user to see the file, or to the shared\public if they want all users to see it.

Encryption would still have to be managed somehow. But this gives each provider an easy mapped drive to get them to their own docs, to docs that other providers are submitting to them, and to docs that other providers want all people to see.