How are locked-down file perms in Linux similiar/different to Win EFS?
April 1, 2013 12:39 PM   Subscribe

I am looking into alternatives to Windows EFS to protect sensitive data on a Linux web server. I know practically nothing about EFS, but I get the impression that the files are effectively plain-text if you are logged into the Windows machine as the user who owns the files, so the same level of "encryption" exists in a Linux environment if the files have only read/write perms for file owner and no perms for anybody else. My colleague says "No, it is not the same level of security" but doesn't provide any further info regarding how/why it's different. What am I missing here?

I am porting a PHP web application from Windows Server 2003 to Linux. The application accepts credit card data and we store it locally so we are bound to the requirements of a PCI Level 1 merchant. The card data is encrypted in the database and my question does not pertain that part of the process (assume everything is secure outside of the parameters below). Two times a month, we do an HTTPS POST to our credit card processor containing transaction data we want to process. This data includes credit card PANs. In the current process on the Windows server, the application gathers the data and saves it in a file in a directory that is encrypted with EFS. Eventually, after some sanity checks are run, this file is POSTed when a human clicks a link that says "send the file now" (I'm simplifying things here.) These files are deleted completely every couple of months.

So, again, my understanding is these files in the EFS-protected directory are basically unencrypted if a user logs into the server under the same account as the application that wrote the files. Is that an accurate statement? (This is IIS and I'm *really* fuzzy about who this user is.)

Back to the Linux version of the app, which by the way will be running Apache. It seems like I can just change the file permissions to something like 600 (-rw-------) and be effectively in the same place as EFS. A user logged in as apache/nobody/root can read the file in plain-text but nobody else has access to it.

The interpretation of the PCI requirements is that "the plaintext file cannot exist on disk for ANY length of time". I think that is stricter than is actually necessary for compliance, but assuming that is where we want to be... does the current EFS implementation even meet this? I definitely want to get to the right place security-wise, but if chmod 600 is effectively the same (file is plain-text to certain users, but unreadable to everyone else), I'd like to use this simple change for the first iteration of the Linux version of the application with a plan to do some proper encryption at a later iteration (or preferably POSTing the file contents without ever writing to a file).

So basically I'm asking how is the EFS implementation more secure than simply locking down the permissions in Linux? (E.g. "Well root can read the file in Linux whereas Administrator in Windows could not" or "It's impossible for *anyone* read the files IIS writes because that's not how IIS/EFS works, dumbass." [I am indeed a dumbass regarding IIS.])

I'm also interested in suggestions for alternative solutions (something like "AES-encrypt the file when writing and then decrypt it into memory when user clicks "send file now" and POST that") but that is not my primary short-term question.
posted by 0 to Computers & Internet (11 answers total)
 
This is when you switch to a business process and credit card processor that does not require storing credit card numbers locally and let someone else deal with the PCI hassle.
posted by wierdo at 12:47 PM on April 1, 2013 [3 favorites]


Response by poster: Agreed, and that's in the works, but not a short-term possibility.
posted by 0 at 12:49 PM on April 1, 2013


Best answer: Disk encryption is mainly designed to prevent attacks that involve physically gaining access to the disks themselves. So in the EFS case, if an attacker physically stole the disks from the server and tried to read the data, they would not be able to without breaking the encryption. Whereas in the vanilla Linux case, the files are stored in plaintext on the disk and they could easily mount the disk from another computer and read all of the files. Disk encryption makes a lot of sense for things like laptops that are physically stolen fairly often but probably less sense for a server in a physically secure data center. I have no idea what the specifics of the PCI requirements are though.
posted by burnmp3s at 12:53 PM on April 1, 2013


So... you're saying that you have code that takes the credit card information in the database, decrypts it, and writes it to disk as a plain text file? If so, I don't think there's any way to construe any other security mechanism to be equivalent to encryption. File permissions are simply that particular OS promising that it won't look at the file.

The first thing that comes to mind is that if that file gets backed up somehow, it's unencrypted on the backup medium. Or for example if the server you're on is virtual or gets virtualized in the future, the underlying host OS has access to it unencrypted.
posted by XMLicious at 1:04 PM on April 1, 2013


Best answer: I don't know who is interpreting the PCI requirements how, but there are three options for encryption on Linux that I'm aware of. Here's an answer that might help.

Basically: Yes, Linux can be made to do exactly what you want it to do, or made to do a couple of other things.

Your default Linux with 0600 permissions is indeed making it so that only root, the logged in user, or anyone with physical access to the disk who can mount it as root (ie: fire up a thumb-drive install) can read it. this almost certainly isn't compatible with the PCI requirements.

Something like a truecrypt encrypted volume as the home directory for a specific user is probably closer to what you're asking for, but I'm rooting for weirdo's suggestion.
posted by straw at 1:10 PM on April 1, 2013


Perhaps you should look into eCryptfs. This isn't "whole disk" or image encryption, but is layered on top of an existing filesystem. Maybe this might satisfy your requirements. While you're at it, don't forget to encrypt your swap space while you're at it, that can also hold data that you might not want released!

What does your OS vendor say about this? I'd want to consult them about this. You DO have production support on this obviously important-to-your-business server, yes?
posted by Geckwoistmeinauto at 1:18 PM on April 1, 2013


Response by poster: I hadn't considered physical security or backup security, so I guess I won't push back further on my colleague and instead will go ahead and make sure nothing is written in plain-text. I'm confident that the disks (and any backups that may exist) are physically secure, but since I don't have any control over that I won't rely on it. Likewise, I know there are Linux alternatives to EFS, but I'd rather keep things secure at the application level than rely on disk encryption (mostly due to weird interpersonal politics). So thanks for the answers, folks, it's clear the whole process needs to be reworked.
posted by 0 at 1:21 PM on April 1, 2013 [3 favorites]


In linux if you log in as root you can look at anything, so any attacker who gains root access can look at any unencrypted file. In addition there's the physical access part. Anyone who can boot the machine to outside media (thumb drive, usb drive, cdrom, flopp disk) can mount the disk as root and read it, no problem, if it's not encrypted.

I don't know much about EFS but I'd be surprised if this was the case - the point of encrypted file systems is that they only decrypt if you have the key, and the administrator probably shouldn't have the ability to do so.
posted by RustyBrooks at 2:12 PM on April 1, 2013


Mmmmh. You probably already thought about this: When I read "AES encryption" I think of symmetrical encryption. That would mean that the means of decryption are present on your web server. I consider that bad because if your webserver gets hacked there is a probability that the hackers could decrypt the transactions that are already present.
I would consider public key encryption for soemthing like that. This way no hacker can get at the data that is already present at the time of the hack.
You could arange for the administrative users to send the private key for decryption together with the request to send the files to the credit card processer. This would make it a little more inconvenient for the useres because they have to be in posession of the private key but I think it would make it much more secure for their customers.

The administrative users have the private key but cannot get to the transaction files. The web server has the files but no private key. This protects old transactions nicely if either were hacked. The private/public key pair can be changed as often as deemed necessary.
Hacking the web server would gve you access to all new transactions but that is something that probably cannot be protected against at all.
posted by mmkhd at 2:25 PM on April 1, 2013


To answer the question, no, Windows EFS and Linux permissions are not the same. In Windows EFS, the data exists on the disk in an encrypted format and is decrypted on the fly when it is accessed by an authorized user. It is always encrypted on the disk.

Whereas permissions are only as good as the OS heeding them. If you plug a linux disk into another box, you can see anything you want.

What you probably want to do is set up a process where the data never even hits a disk- have your database pipe its output to a ramdisk which the webserver can see. Or better yet, have the database (somehow) connect directly to the CC processor when the "submit data" button is pressed.
posted by gjc at 4:28 PM on April 1, 2013


Response by poster: Hey, I just wanted to thank everybody for their answers and give a little update. I really learned a lot from this thread and appreciate everybody's input. I marked burnmp3s' answer as best because it was really the light-bulb for me about what I was missing while thinking about this problem. I also marked straw's answer because the link to the superuser.com thread gave me a good start on researching linux disk encryption options.

We ultimately went with TrueCrypt, based on our host's recommendation. It was a pretty simple matter of installing the Fuse library and TrueCrypt and then setting up the mount directory. No code changes were required (though the code still needs some unrelated security love). Thanks again.
posted by 0 at 8:22 AM on April 11, 2013


« Older Detective Says I'm A Witness, But Won't Say To...   |   Outdoorsy things to do less than 4 hours from... Newer »
This thread is closed to new comments.