Do all my programs have owner rights to all my files?

Question

I'm worried about all my programs having full access to all my files.

Eg: My user is 'john'. I install some program, say Dropbox. Dropbox runs as 'john'. Therefore it not only has full rights on its files under ~/.dropbox, but to all files including ~.

1) Am I right? If so,

2) Should I worry about this?

3) Is there any way to fix this? Someone told me I could use chroot or setuid, but I'm not sure how to use them.

I'm using Ubuntu 12, in case it matters.

Answer 1

That is a reasonable thing to consider: other platforms, like MacOS-X, and applications, like Chrome, are using sandboxing to run whole applications or parts of applications in a way that they stop having full control equivalent to what you have.

So, in answer to 1, yes, if you start an application running as yourself, it has equivalent access to what you do: any file you can edit, it can edit, and so forth. The one exception is if the application itself does things to restrict privileges.

In answer to 2, you should probably be vaguely concerned about it much more than you actively worry about it. After all, every single application you run has the same access - the only thing that distinguishes DropBox is that it came from someone other than the upstream distribution.

So, 3: can you fix this? The answer is "probably not". It isn't that it is impossible, it is that it is likely to be hard to do in a way that satisfies your desires to use the applications or services.

Using chroot allows you to pretend that there is another "root directory" than the real one. This isolates applications (like dropbox) from your real root - and might allow you to escape from the risk that it can read the rest of your home directory. (Add a symlink from ~/.dropbox to ~/chroot/whatever/home/you/.dropbox and it isn't even all that inconvenient.

However, you need to be root, or use a tool like schroot to manage access to running the application, and the chroot only isolates a few parts of the system - files. Applications with root inside that can still see outside, or escape. Various other resources (IP ports, pids, etc) are still shared.

Also, I bet that DropBox has a UI component, and that doesn't work well chrooted. Even if it does, that limitation hurts other applications.

The alternative, a setuid application, is a way that you can say "no matter who runs this, start it as this other user, not the user who started it".

This is most often used to allow applications that you, a normal user, start to run as root - for example, sudo. However, it can set the user or group of the process to an unprivileged user too.

The problem with that is that it runs as a different user - just like you ran it with sudo -u another-user dropbox or whatever. Which means that it doesn't have access to your home directory and, without working hard, you don't have access to the other users home directory.

You can work around that, but it is neither trivial nor convenient in the common case. Typically, you would want to share a group, and try to arrange that files it can read are owned by that group rather than your standard group. This isn't trivial to do, even with setuid directories (which change the group or owner of files created under them), in part because you need to manage your umask, and that is a pain under Linux.

Finally, you could use AppArmor or SELinux to secure the application. I believe that AppArmor is what Ubuntu have chosen as their preferred option. While it is convincingly argued that it is less secure than SELinux, it is also conceptually simpler being based on visible names and paths more than secure labels.

You might find that an effective way to enhance your security without having to go down the more complex paths. It should, in theory, allow you to restrict DropBox to exactly only the ~/.dropbox folder and nothing else without needing to run as a different user.

So, if you really want to improve your security there, look to the chroot path. It is the least painful way to improve security of DropBox on Ubuntu - much less than a setuid application, at least.

That said, odds are your biggest risk of exposure is from an employee of DropBox - we know that they deduplicate even between users, so their systems can see the unencrypted content, which means that someone working for them could do the same.

You might consider using encfs instead to encrypt files before they ship up to DropBox...

Answer 2

1) Yes. 2) In general no. You have to trust at least some of the software that you run not to mess things up. 3) The easiest way would probably be to run the software as a different user. If it doesn't need access to anything, you could run it as the "nobody" user who has basically no rights. Otherwise, you could change the owner of all the files the application has to access to the user it runs as. Note that this would make accessing the files more difficult for you and other programs though.

In general, I wouldn't worry too much about it. You have backups of your data that you could restore files from anyway, don't you.

Answer 3

1) Am I right?

Basically yes, but it is not "programs" that have access rights but the "user" that owns the "process" that runs the "program". So if you run Dropbox, Dropbox have your access rights. If someone else runs Dropbox, it has their access rights.

2) Should I worry about this?

Not really.