39

I have a Linux machine that contains sensitive files. Users should be able to access (read) them when they are using the computer, but should not be able to copy them to another hard drive (USB stick or another hard drive that might have been added on the same machine).

The main hard drive has been encrypted, in order to prevent someone from extracting it and stealing the files.

I am free to use SELinux or other approaches in order to achieve the goal.

UPDATE:

After reading the answers, I would like to clarify:

  • I am not very concerned about users who may take a picture of the screen. Protecting the actual file is my main goal.

  • Even though protecting each and every file would have been optimal, I am mostly concerned about protecting the dataset as a whole (it is very large). Even if a few files get leaked, the damage is manageable. Moreover, due to the large amount of files, extracting them one-by-one in an inefficient way would not be practical.

  • The users of the computer will not be given administrative privileges.

Boann
  • 221
  • 1
  • 6
Iakovos Gurulian
  • 509
  • 1
  • 4
  • 9
  • 16
    What kind of files? Is physically securing all interfaces a viable option, e.g. lock the computer in a box and only let users access keyboard and screen? In general, it's extremely difficult to protect against deliberate copying by a trusted user. – vidarlo Jun 15 '19 at 08:06
  • PDF files mainly. Physically securing the computer is ideally not what I would like to achieve, but can be done if nothing else works. I was thinking of preventing users from mounting USB or other drives (not sure if/how this is possible when using a desktop environment). – Iakovos Gurulian Jun 15 '19 at 08:15
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/95019/discussion-on-question-by-jackgu1988-how-can-i-prevent-a-user-from-copying-files). – Rory Alsop Jun 17 '19 at 15:52
  • 2
    It's been said that trying to make bytes that can't be copied is like trying to make water that isn't wet. – Mason Wheeler Jun 18 '19 at 14:37

8 Answers8

60

You can disable USB storage on Linux by blacklisting the module. 

modprobe -r usb-storage
echo blacklist usb-storage >> /etc/modprobe.d/10-usbstorage-blacklist.conf
echo blacklist uas >> /etc/modprobe.d/10-usbstorage-blacklist.conf

If your users have physical access to the machine, and knows the encryption keys, the game is up no matter what you do software-wise.

My suggestion would be to limit the access to physical interfaces of the machine. Lock it inside a box, and only let users interact via a keyboard, mouse and screen.

You should also note that you can't stop a user from copying something. Worst case? Take up the phone, and take pictures of the screen as they sift trough the files. Data loss prevention should in my opinion be targeted at stopping accidental copying to untrusted devices.

vidarlo
  • 12,850
  • 2
  • 35
  • 47
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/95089/discussion-on-answer-by-vidarlo-how-can-i-prevent-a-user-from-copying-files-to-a). – Rory Alsop Jun 18 '19 at 19:25
21

Client-server architecture

This is another approach that could make copying files much harder, but it requires investing more effort from your side.

Access to the information could be setup on a client-server architecture basis with information being stored in a database (such as MySQL or PostgreSQL) on a remote server in a secure location.

Then, provide access stations which would run a client application that retrieves information from the server and displays it to users.

So, instead of letting users access the information directly, you feed it to them.

You can make it harder for users to copy the data by limiting capabilities of the desktop environment, disabling USB ports, etc. Also, your app could display the information as an image as opposed to text, but this depends on whether or not this is appropriate from usability aspect.

But all this assumes that the only hosts that can access the database are locked-down client stations that you provide for users and that they are in a controlled environment so that they can not tamper with access stations or plug their own devices to the network.

Whether or not this is a good approach for your use case depends on your threat model, and how much effort you are ready to invest into this.

VL-80
  • 1,234
  • 1
  • 9
  • 17
  • 3
    +1 — What this can do that the other solutions can’t is limit the number of files that can be accessed. If reading a couple of files is normal while downloading the entire dataset is abuse, this can be easily enforced on the server side. – Roman Odaisky Jun 17 '19 at 23:55
19

In addition to blocking USB (see other answers above):

Disable networking, because...

  • ... otherwise user will use remote access to your machine, e.g. via scp or ftp, and copy files from your machine.
  • ... otherwise logged in users will be able to transfer file via net from your machine to some other machine via scp, ftp, samba, http.
mentallurg
  • 8,536
  • 4
  • 26
  • 41
  • 10
    yes, disable network: "mail", "telnet", "lpr", and "netcat" can also be used to move files, furthermore even DNS lookups can be used to exfiltrate data. – Jasen Jun 16 '19 at 10:07
  • 4
    And you can also bring a pocket-pc which you plug-in to the ethernet-port of the machine, if this is not physically sealed off – Falco Jun 17 '19 at 08:24
  • 2
    @Falco And while you are at it, you better physically seal off access to the keyboard and monitor ports/cables. Anything that provides input/output in any way to the PC can be circumvented for anything that can be done with any other input/output for a determined enough attacker. And of course even then the same can still be done physically with the keyboard and mouse. The more general point is that if human eyes can read the data, then you cannot prevent that data from being stolen. – Jon Bentley Jun 17 '19 at 23:30
13

OK, I'm totally not a security expert and maybe this is completely off the mark (let me know in the comments!), but...

If you can secure the box physically (otherwise all bets are off), then maybe you can let the user log on only with user A. All the sensitive files however would belong to user B and inaccessible to user A. EXCEPT for one program "PDF Viewer" that would also belong to user B, but with the setuid bit set, so when run, it would run in the context of user B and be able to access the files. Since it's a viewer, it can show the files, but not copy them.

Or something along these lines. The trick is the setuid bit.

Vilx-
  • 998
  • 2
  • 7
  • 15
  • Interesting approach. However, if you do save as from within the viewer, won't it be able to save an exact copy of the file locally? – Iakovos Gurulian Jun 16 '19 at 17:04
  • 4
    @jackgu1988 - Well, yes, you need to find a viewer that does not have a "Save as" function. Or maybe take an existing opensource one and modify it. – Vilx- Jun 16 '19 at 17:24
  • @jackgu1988 - Oh, but you did say that extracting them one by one is impractical, didn't you? – Vilx- Jun 16 '19 at 17:54
  • Yes, however if there is a shortcut for 'save as', this can be very fast, or even automated. – Iakovos Gurulian Jun 16 '19 at 22:48
  • @jackgu1988 - Yes, that's true. – Vilx- Jun 17 '19 at 06:23
  • Setgid might be an even better solution, but with the same restrictions. Perhaps more modern options exist. (ACL?) You could also combine this with restricting write access for this user or group to certain directories, so eg. they may not write to a USB drive. This probably won't help for network access, though. Could you give more information on the file types or the kind of programs which need to access these files? – idspispopd Jun 17 '19 at 08:19
  • @idspispopd - Somewhere else in this topic the OP said that it's PDF files and there's a gazillion of them. A few leaked isn't a big deal, but a large quantity is. – Vilx- Jun 17 '19 at 09:03
  • PDF files can be "_Protected_" at various levels, and prevent "save as..." and/or prevent copying text or image to the clipboard, prevent printing etc ... These settings, if applied at the original PDF document levels, will apply regardless of the PDF viewer capabilities. – Hoki Jun 17 '19 at 10:14
  • @Hoki: PDF protections/permissions at various levels are all pointless against those who know what they're doing, only PDF encryption is remotely useful. – Lie Ryan Jun 17 '19 at 12:18
  • 1
    @LieRyan - In this case it could actually work, since they cannot access the files directly and are forced to use the provided software. – Vilx- Jun 17 '19 at 12:24
  • @LieRyan, I know they are hackable by people who have the knowledge, but they would need tools for that, which shouldn't be available in the environment the OP is talking about. – Hoki Jun 17 '19 at 12:24
  • User A does not need to have write access anywhere to open a viewer. Maybe SELinux rules or Linux containers can enforce read-only of file systems (even through USB) and disable network access. – A. Hersean Jun 17 '19 at 12:46
  • 1
    @Vilx: my comment wasn't directed towards your answer. Your answer is mostly fine; setuid Viewer is one crucial part towards implementing what the OP asked, though it can use a little bit of refinements as traditional Unix file permissions and setuid aren't sufficient to completely prevent certain scenarios. My comment was directed towards Hoki's assertion that PDF permissions "... apply regardless of the PDF viewer capabilities". This isn't true at all. – Lie Ryan Jun 17 '19 at 13:05
  • Save as should be no that big problem, when User B cannot write files anywhere. So you need to secure writeable directories like ``/home/B``, ``/tmp``, ``/var/tmp`` and ``/dev/shm`` and probably some others. Using tools like selinux or sandboxes like firejail it should not be too hard to deny write access. – allo Jun 18 '19 at 09:12
10

VNC

Your files could be stored on a computer in a secure location.

Setup a VNC server on it and disable file transfer capability. Per this question on ServerFault it can be done in TightVNC.

Ensure no other ports are open on the computer that stores your files.

Provide a VNC client station and lock it down by:

  • disabling I/O ports in the OS and on the BIOS level
  • placing a lock on the case
  • limiting the desktop environment functions
  • setting a strong password for root account
  • limiting what user's account can do

This should make it harder for users to copy the information while still providing them a convenient way to interact with the files. VNC can work in a full screen mode, giving your users impression as if they interact with files on a local station.

VL-80
  • 1,234
  • 1
  • 9
  • 17
  • 1
    There are enterprise solutions like Citrix, Xen Desktop, SPICE that more or less does this. There are even ones with an browser-based client, which would eliminate the possibility of unexpected IO or open ports. – Lie Ryan Jun 17 '19 at 16:44
3

If you just want to disable all usb devices, have a look at usb-storage.ko (USB Mass Storage driver under Linux). Disabling the driver would affect all usb devices, keyboards/mice included. To disable the driver, you could blacklist it by modifying /etc/modprobe.d/blacklist.conf. Just add the line:

blacklist usb-storage

This solution assumes other users don't have sudo rights.

borizzzzz
  • 203
  • 1
  • 8
2

Following the principle of "only gives one the rights needed to achieve his task", maybe you can implement a restricted shell that will enforce that users of your system only do what you allow them to do.

If your users are not able to:

  • scp
  • mount
  • launch any network utility (firefox, netcat, curl)
  • Use bash builtins to open network stream.

Then the only way they can exfiltrate data is by hacking one of the command they are allowed to run...

A "restricted shell" can be implemented quite easily by:

  1. Reading command from user
  2. Testing if command is allowed for user
  3. If yes, run it.

Moreover, there's tons of restricted shell availables for GNU/Linux.

binarym
  • 744
  • 4
  • 8
2

How about something like a human bottleneck via procedure instead of automation and access to all files at once? All of the proposed solutions propose making the computer restrict access. This suffers from the problem that computers are ultimately stupid at the lowest level, and do what they're told. Since the HD is using whole disk encryption, all files are available in plaintext while the machine is powered up.

In addition to full disk encryption, encrypt all the files on the hard drive, each with a different, randomly generated password, but make still have some sort of keyword search ability through an index. For the user to request a file, they must make a request to the administrator. Passwords are stored offline on some resource unavailable to the user. The administrator then obtains the password(s) for requested file(s), then enters in the password, and decrypts the files for the user. Depending on the viewing software, you might even be able to force the file to only be in memory, and not on disk. The administrator could be instructed to only decrypt a limited amount of files/day.

This would be in addition to the methods above, like disabling USB/Network/etc access. The advantage of this method is that it severely limits any method of copying. If a copying method is discovered, the damage is limited to only the files that have been requested decrypted.

This of course may not be feasible depending on your scenario, but it offers a very high level of security since each file is individually protected.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • Managing millions of encrypted keys would be problematic. Moreover, this likely doesn't actually solve the problem, since the user that the OP is referring to is likely someone that's supposed to be doing the role of the adminstrator that you're proposing. You're just then moving the problem to having a computer or another administrator that needs to rate limit the dispensation of the decryption keys. – Lie Ryan Jun 17 '19 at 16:52
  • @LieRyan I'm not sure I agree. Someone, presumably the person setting this up has access to these files. They _could_ copy them, if they so choose, so you have to trust someone with access. Also, a million is simply not a very large number. It would certainly not be difficult to store all these passwords on another computer, also encrypted. – Steve Sether Jun 17 '19 at 17:44
  • If you are storing the passwords on another computer, why not just store the files on this other computer and dispense with the whole encryption scheme (or encrypt them all with the same key). The user (who controls only the client machine) requests the file, and the administrator (who controls the server machine) authorises the file to be sent to the user. You also don't need a human administrator. The server can easily handle the rate limiting itself. – Jon Bentley Jun 17 '19 at 23:36
  • @JonBentley Storing both on the admin machine would mean the file would have to be copied to the users machine. Exactly the scenario trying to be avoided. Also, automation, and software control is also the risk being avoided here. Well trained humans and trusted humans are more trusted than automation. Generally we create automation because it's cheaper, not because it's more secure. – Steve Sether Jun 18 '19 at 03:01
  • The scenario trying to be avoided is not copying files **to** the user's machine, but rather copying files **from** the user's machine (e.g. to an external drive). The OP expects that the user's machine will have copies of the files. I disagree with your argument that well trained humans and trusted humans are more secure than servers. Well trained humans can make mistakes, and trusted humans today can become untrusted tomorrow. Servers can be programmed incorrectly but can always be trusted to do what they were programmed to do. Either can be more secure than the other depending on the facts. – Jon Bentley Jun 18 '19 at 04:40
  • @JonBentley Since we're started relying more on software to control access rather than people and physical access we've gone from an era with few large-scale data breeches to an era where it happens constantly. The one high-profile data security breech before widespread information automation I can think of was Daniel Elsberg and the Pentagon Papers. In the automation era, Chelsea Manning and Edward Snowden made Elsberg look like a minor incident. Not to mention the massive leak of SS#s from Experian, the massive Sony Pictures data spill, and countless other data spills. – Steve Sether Jun 18 '19 at 19:07
  • @SteveSether Correlation != causation. Yes, there have been more data breaches, but there is also a *lot* more data to be stolen than there ever used to be. Not to mention that a high proportion of breaches result from errors from trusted humans, rather than software issues. For example, the Sony breach happened because employees let the hackers into the building, and their internal software security was abysmal. If they had had better automated security, it may have been prevented – Jon Bentley Jun 19 '19 at 12:17