*SensitiveFilePermissions fails on ntfs-3g mounted filesystems #347

New Issue

2013-07-30T04:26:23+02:00

nimdahk commented

2013-07-30 04:26:23 +02:00

(Migrated from github.com)

To share my files between Windows and Linux, my ~/.config/PyBitmessage is a symlink to the filepath on Windows. The NTFS partition is mounted using ntfs-3g. Due to this, the permissions cannot be changed. This causes an exception to be raised at startup.

Suggested fix: check the filesystem rather than the platform

Current workaround: comment out line 371 in shared.py

To share my files between Windows and Linux, my ~/.config/PyBitmessage is a symlink to the filepath on Windows. The NTFS partition is mounted using ntfs-3g. Due to this, the permissions cannot be changed. This causes an exception to be raised at startup. Suggested fix: check the filesystem _rather than the platform_ Current workaround: comment out line 371 in shared.py

fiatflux commented

2013-07-30 14:42:00 +02:00

(Migrated from github.com)

Thanks for reporting this. That's a (not extreme) corner case I obviously hadn't considered.

This is a little tricky. AFAIK, there is no prepackaged platform-independent way to identify the filesystem on which a file resides. The main problem is that stat/statfs/statvfs vary between POSIX platforms, and there aren't Python bindings that unify them as far as the filesystem type goes. The Right Way® might be to start contributing these bindings. But instead I'm tempted to check platform then blacklist NTFS from fixSensitiveFilePermissions using the output of stat -f -c "%T", which I think should work for almost all linux folks. As far as I'm concerned, since I don't have a Mac with which I can experiment, OSX users will have to figure out their own solution should the need arise in their camp.

Would you please tell me what output you get upon executing:
stat -f -c "%T" ~/.config/PyBitmessage/keys.dat

Thanks for reporting this. That's a (not extreme) corner case I obviously hadn't considered. This is a little tricky. AFAIK, there is no prepackaged platform-independent way to identify the filesystem on which a file resides. The main problem is that stat/statfs/statvfs vary between POSIX platforms, and there aren't Python bindings that unify them as far as the filesystem type goes. The Right Way® might be to start contributing these bindings. But instead I'm tempted to check platform then blacklist NTFS from fixSensitiveFilePermissions using the output of `stat -f -c "%T"`, which I think should work for almost all linux folks. As far as I'm concerned, since I don't have a Mac with which I can experiment, OSX users will have to figure out their own solution should the need arise in their camp. Would you please tell me what output you get upon executing: `stat -f -c "%T" ~/.config/PyBitmessage/keys.dat`

nimdahk commented

2013-07-30 18:33:28 +02:00

(Migrated from github.com)

Notes:

Running the unmodified official source as root succeeds in not raising the exception, however running it again as a standard user afterwards again raises the exception, indicating that the permissions have not been changed.
Using chmod as root returns silently, but the permissions do not change.
Running my file browser, nemo, as root, and then attempting to change permissions or ownership results in the checkboxes, drop-down lists, etc changing and then changing back to their original value quickly.

$ stat -f -c "%T" ~/.config/PyBitmessage/keys.dat
fuseblk

fuseblk is what mount returns, but ntfs-3g is the type specified in my /etc/fstab. This is expected.

Notes: - Running the unmodified official source as root succeeds in not raising the exception, however running it again as a standard user afterwards again raises the exception, indicating that the permissions have not been changed. - Using chmod as root returns silently, but the permissions do not change. - Running my file browser, nemo, as root, and then attempting to change permissions or ownership results in the checkboxes, drop-down lists, etc changing and then changing back to their original value quickly. ``` $ stat -f -c "%T" ~/.config/PyBitmessage/keys.dat fuseblk ``` `fuseblk` is what `mount` returns, but `ntfs-3g` is the type specified in my `/etc/fstab`. This is expected.

AyrA commented

2013-07-30 22:50:01 +02:00

(Migrated from github.com)

NTFS has a complete different permission system anyway. If you have formatted an NTFS Drive correctly (aka. not manually messed with the permissions) a File usually inherits permissions from its directory. I advise to put the keys.dat in a folder, that is inside your %USERPROFILE% Directory. Then only you and administrators have accesss.

fiatflux commented

2013-07-30 23:26:37 +02:00

(Migrated from github.com)

Hi AyrA, we understand very well that NTFS has a different permission system. That is precisely the source of the problem. nimdahk is having trouble because, for dual-boot reasons, their keys.dat resides on an NTFS filesystem mounted on a Linux system.

Hi AyrA, we understand very well that NTFS has a different permission system. That is precisely the source of the problem. nimdahk is having trouble because, for dual-boot reasons, their keys.dat resides on an NTFS filesystem mounted _on a Linux system_.

AyrA commented

2013-07-31 00:06:28 +02:00

(Migrated from github.com)

Why do we need to change permissions at all? Aren't the permissions in the users home directory set correctly by default?

nimdahk commented

2013-07-31 01:38:13 +02:00

(Migrated from github.com)

If we remove the read-other permission, it protects the user's private keys.

AyrA commented

2013-07-31 07:47:57 +02:00

(Migrated from github.com)

But why are others allowed to read the file in your personal profile in the first place? It kinda negates the purpose of having it if others can just read your files anyway per default.

fiatflux commented

2013-07-31 07:52:29 +02:00

(Migrated from github.com)

@AyrA Permissions are set "correctly" to the (customizeable) default, which is usually 633 (i.e. owner read/write, group read, other read). But that is not "correct" for key files. It is imperative that sensitive files be created under a more restrictive "umask" that prevents files from ever letting group members or other users get a file handle. http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html

fiatflux commented

2013-07-31 07:54:58 +02:00

(Migrated from github.com)

But why are others allowed to read the file in your personal profile in the first place? It kinda negates the purpose of having it in the first place if others can just read your files anyway per default.

Security is not the purpose of a home directory. In fact, there is no one purpose. It all depends on use and configuration.

> But why are others allowed to read the file in your personal profile in the first place? It kinda negates the purpose of having it in the first place if others can just read your files anyway per default. Security is not the purpose of a home directory. In fact, there is no one purpose. It all depends on use and configuration.

AyrA commented

2013-07-31 16:13:07 +02:00

(Migrated from github.com)

I don't know why we need to fix an issue, that is obviously accepted in the Linux world. (Not having a private location for my files would actually be an instant reason to switch OS if I weren't using windows already). Instead we should possibly just implement encryption and decryption for files, because an admin can take ownership of your files anyway. We can encrypt and decrypt messages in bitmessage, so doing the same with a file shouldn't be any harder: http://eli.thegreenplace.net/2010/06/25/aes-encryption-of-files-in-python-with-pycrypto/

fiatflux commented

2013-07-31 17:45:20 +02:00

(Migrated from github.com)

Instead we should possibly just implement encryption and decryption for files, because an admin can take ownership of your files anyway.

Yes, root can take ownership of your files. But they also can do anything they bloody want ... like directly access decrypted keys in-memory. If you don't trust root, you have much bigger problems. Yes, encryption is lovely. But that is no replacement for correctly using the POSIX permission system in the first place.

Not having a private location for my files would actually be an instant reason to switch OS if I weren't using windows already

Not having a private location for my files would be an instant reason for me to, you know, make one. Or change the default umask. BFD.

> Instead we should possibly just implement encryption and decryption for files, because an admin can take ownership of your files anyway. Yes, root can take ownership of your files. But they also can do anything they bloody want ... like directly access decrypted keys in-memory. If you don't trust root, you have much bigger problems. Yes, encryption is lovely. But that is no replacement for correctly using the POSIX permission system in the first place. > Not having a private location for my files would actually be an instant reason to switch OS if I weren't using windows already Not having a private location for my files would be an instant reason for me to, you know, make one. Or change the default umask. BFD.

nimdahk commented

2013-07-31 17:47:24 +02:00

(Migrated from github.com)

I don't know why we need to fix an issue, that is obviously accepted in the Linux world. (Not having a private location for my files would actually be an instant reason to switch OS if I weren't using windows already).

What in the world do you mean? Private from whom?

Read Permission is granted to all normal users for files in other user directories (Bob can read John's keys.dat)
Since it's not encrypted, anyone with physical access to the machine can get at your files within 30 seconds (CD/USB Boot)

At the very least, popular Linux install disks include an option to fix that second point automatically.

> I don't know why we need to fix an issue, that is obviously accepted in the Linux world. (Not having a private location for my files would actually be an instant reason to switch OS if I weren't using windows already). What in the world do you mean? Private from _whom_? - Read Permission is granted to all normal users for files in other user directories (Bob can read John's keys.dat) - Since it's not encrypted, anyone with physical access to the machine can get at your files within 30 seconds (CD/USB Boot) At the very least, popular Linux install disks include an option to fix that second point automatically.

fiatflux commented

2013-07-31 17:52:49 +02:00

(Migrated from github.com)

I don't know why we need to fix an issue, that is obviously accepted in the Linux world.

Oh, yeah, I forgot to answer this. It's because previous versions of this software failed to umask sensitive files appropriately. That's all.

> I don't know why we need to fix an issue, that is obviously accepted in the Linux world. Oh, yeah, I forgot to answer this. It's because previous versions of this software failed to umask sensitive files appropriately. That's all.

fiatflux commented

2013-07-31 18:10:50 +02:00

(Migrated from github.com)

Anyway, @nimdahk, there are two solutions that I think are reasonable in different ways:

Keep the loud failure, but blacklist fuseblk just like Windows. Advantage: loud failure can help alert a user to a very serious problem into which they should intervene. Disadvantage: not particularly good at crossing platforms. It's likely we'd have to add further things in the future.
Just drop the raise statement. For most systems administered by inexperienced users, chmod should just work... unless NTFS is far easier to use these days than it was when I last played with it. Advantage: "Just works". Disadvantage: unlikely but unfortunate corner cases leaving keys.dat more vulnerable to all sorts of gross attacks.

Anyway, @nimdahk, there are two solutions that I think are reasonable in different ways: - Keep the loud failure, but blacklist fuseblk just like Windows. Advantage: loud failure can help alert a user to a very serious problem into which they should intervene. Disadvantage: not particularly good at crossing platforms. It's likely we'd have to add further things in the future. - Just drop the raise statement. For most systems administered by inexperienced users, chmod should just work... unless NTFS is far easier to use these days than it was when I last played with it. Advantage: "Just works". Disadvantage: unlikely but unfortunate corner cases leaving keys.dat more vulnerable to all sorts of gross attacks.

nimdahk commented

2013-07-31 22:59:24 +02:00

(Migrated from github.com)

unless NTFS is far easier to use these days than it was when I last played with it
How long ago was that?

For one thing, we have write support now...

I think we should err on the side of caution. That is, raise when non-fuseblk, error (but no raise) when fuseblk, and preferably add a warning to the GUI when fuseblk (with some guid for googling).
This fixes the problem in the only known-to-currently-exist case (mine) without putting others at risk.

Alternatively, just replace the raise with a big print statement and a pause before returning, followed by a warning in the GUI (status bar, messsage box...) if the GUI is actually opened.

> unless NTFS is far easier to use these days than it was when I last played with it > How long ago was that? For one thing, we have write support now... I think we should err on the side of caution. That is, raise when non-fuseblk, error (but no raise) when fuseblk, and preferably add a warning to the GUI when fuseblk (with some guid for googling). This fixes the problem in the only known-to-currently-exist case (mine) without putting others at risk. Alternatively, just replace the raise with a big `print` statement and a pause before returning, followed by a warning in the GUI (status bar, messsage box...) if the GUI is actually opened.

fiatflux commented

2013-08-05 22:14:19 +02:00

(Migrated from github.com)

Hey @nimdahk, would you mind double-checking this fix for me?

nimdahk commented

2013-08-06 00:42:32 +02:00

(Migrated from github.com)

2013-08-05 18:35:19,507 - INFO - Skipping file permissions check for /home/nimda/.config/PyBitmessage/keys.dat. Filesystem fuseblk detected.

👍 Works great, thanks. Hurray for symlinks!

> 2013-08-05 18:35:19,507 - INFO - Skipping file permissions check for /home/nimda/.config/PyBitmessage/keys.dat. Filesystem fuseblk detected. :+1: Works great, thanks. Hurray for symlinks!

nimdahk commented

2013-08-13 00:08:44 +02:00

(Migrated from github.com)

Resolved by pull request #378

This repo is archived. You cannot comment on issues.