34

My question is about filesystem permissions (specifically the Unix style permissions) and how they relate to security.

Say I have access to a computer with a guest user account and a user named Bob. I don’t know Bob's password, but I can use the guest account. The guest account has absolutely no read permissions for all of Bob’s files, so I can't read any of Bob’s files while logged in as guest.

However, from a true “adversary” perspective, I have full access to this unencrypted disk. I could image it, save it for later, run some other OS to simply read Bob’s files while ignoring the filesystem permission settings.

From this, I get to the question:

  1. A filesystem permission setting on an unencrypted disk is just a flag, correct? And the only thing stopping me from reading files to which I don’t have permission is the fact that the OS will say “Oh, you can’t read that, you don’t have permission.” That file is still on the disk in raw form and I could read it by just ignoring the filesystem flags (say, via some shady bootable OS that simply ignores permissions). Is this all correct?

Now say I don’t have direct access to the disk, and I’m just ssh-ing into a machine. I don’t have permission to read any of Bob’s files. There's really nothing I can do about it, correct?

  1. Given my limited permissions, I simply can’t access Bob's files no matter how hard I try, no? What if I use some exploit to gain root access? Can I now bypass the OS's permission flags? Is this a thing that ever happens?
2
  • 4
    yes and yes. you appear to understand the related concepts correctly. An escalation of privlege attack will be required to bypass the permissions if you cannot get physical access to the system. Sep 27, 2015 at 5:22
  • 2
    Wouldn't it be a good idea to migrate this to Security.SE? It seems like the more logical place for it. Sep 28, 2015 at 11:47

2 Answers 2

30

Shorter answer.

If you have physical access to a computer system—PC or data storage system—and the only “protection” in place are file permissions, you have 100% no protection.

That unencrypted data can be copied and cloned with minimal effort with almost no tools other than having another device you can hook up to the system drive to make a copy of the data with.

And yes, potentially some evidential aspects of physical penetration might need to be factored into access on a physical level; like making sure no fingerprints are left behind and any “tamper evident” seals are dealt with as well. But honestly, the vast majority of systems out there can have their drives physically removed for a physical copy of data with the end user never knowing any better. If you have the drive, you have the drive and you then have the data if it’s unencrypted.

This is why per-user encryption or full-disk encryption is such a big thing nowadays; laptops other portable computing devices are such a big part of the market nowadays the risk of data loss from device theft or casual borrowing of a PC is much higher than it’s ever been before in the past.

If the disk is unencrypted the data on it is an open book ready to be read. This concept is not limited to Linux/Unix machines but any OS anywhere; if you have physical access to an unencrypted system you have the system.

That said, file permissions are a useful security measure for remote servers of all kinds.

Longer answer.

My question is about filesystem permissions (specifically the Unix style permissions) and how they relate to security.

First, keep in mind security on computers—and everything—is a really just a deterrent that slows things down and does not necessarily provide absolute security.

For example, the weakest piece of security in any physical building is the door you have to open when entering/exiting it or the window you have to open to allow air in. Yeah, you can lock doors and windows and setup alarms but if somebody truly wants access to something—and they have the time, resources, wealth and effort to pursue it—they will get access to it.

Say I have access to a computer with a guest user account and a user named Bob. I don’t know Bob's password, but I can use the guest account. The guest account has absolutely no read permissions for all of Bob’s files, so I can’t read any of Bob’s files while logged in as guest.

The issue here is the context of access. If you have physical access to a computer, pretty much anything is possible. But if you are only connected via remote connection—over a network of some sort—then the file system ownership is definitely an effective method of security. And in the case of Linux/Unix servers, permissions and ownership are effective forms of security to deter remote intrusion.

That is why in the Linux/Unix world gain root access to a remote system is considered such a grand prize. Gain root to a remote system and then you have truly done something that gives you greater access without needing to walk into a data center and clone a drive.

However, from a true “adversary” perspective, I have full access to this unencrypted disk. I could image it, save it for later, run some other OS to simply read Bob’s files while ignoring the filesystem permission settings.

Yes. Exactly. If you have physical access to machine, then—as explained at the outset—all bets are off. You can gain access to the files and directories owned by others by making an image of the disk—or even just pursuing the raw contents of the drive itself—with little to no deep technical effort.

Anyone who—for example—loans you their personal computer and sets up a new account just for you without thinking of this scenario is basically giving away any personal data they have on their machine without really knowing it.

Slight tangent, but I think this is why so many casual users donate old PCs without making the slightest effort to wipe data on the drive. They setup a user password and they assume that kept their data secure to the extent they could just toss the drive in the trash and not think twice. When the reality is without true encryption or a data wipe, any drive tossed in the trash or sold used can just be read by anyone anywhere without much any heavy lifting or deep technical effort.

1
  • 6
    I think this answer misses something rather obvious that is worth mentioning. Security isn't just computational security. Threat models matter too, because attackers are human: attackers generally want to avoid leaving trails. If you give someone physical access to a device but you do it in such a way that the device cannot be tampered with without leaving a trail (anything from fingerprints to tamper markers to the destruction of the device during manipulation), then it can indeed increase the security of your system despite the fact that the data is physically accessible.
    – user541686
    Sep 27, 2015 at 8:44
16

Your three points:

  1. If you are SSH’ing in as a regular user, you don’t have access to the raw disk device. You typically need root or permission to access the raw and logical disk devices.

  2. If you get root through an exploit, then you are the most powerful user on the system and have access to most anything, including the device. Since you are root, you can directly access Bob’s files, so no need to access the disk device.

  3. Physical access beats root. Root is a logical layer. You can ignore it with physical access to the disk. This includes loading said disk in a separate OS where you are root.

Of course, systems are supposed to be hardened against root exploits, but new exploits come out daily. No system is 100% secure but you can make one secure for practical purposes by limiting access.

File system permissions are only expected to work in Limited User access situations, where the OS is not compromised. It's an "keep honest (and typical) users honest" system, like bike locks. It works to prevent "crimes of opportunities" more than fail safe total protection.

1
  • FS permission rules are pretty robust. They work as long as no attacker has root. The POSIX filesystem semantics (and Linux-specific extensions) are carefully designed to not open up more access than you can get with just open(2). e.g. linkat(2) lets you create a directory entry for an open file descriptor, but only if the link-count isn't already zero, so a process that receives an open FD for a deleted file can't link it back into the filesystem. Obviously an attacker getting root or physical access means you're toast. Encryption helps with physical but not so much root. Sep 27, 2015 at 23:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .