[securedrop-export] Change umask on export device files to permit access from other computers with other uids

[airblag]

This issue should replace this one opened in the wrong repository : freedomofpress/securedrop-workstation#822

The files exported on the usb drive are owned by uid 1000. The umask is set to 077 which makes the file readable only by uid 1000 on the system it is going to.

https://github.com/freedomofpress/securedrop-export/blob/1d50f383f90510fb2f545659f39f2d03085b805f/securedrop_export/export.py#L79

In our case, we have Journalists working on Debian workstations, with some central LDAP authentication. A journalist trying to read the export files from securedrop on his daily workstation cannot get access to the files.

I do not see a lot of scenarios where the file permissions on the export stick improves security in any way.
The usb drive is encrypted, so the user first needs to unlock it.
The daily computer should not be trusted. uid 0 would be able to read the files once they are mounted on the daily computer and don't care about the file system permission.

The only situations where the file permissions could increase security would be accessing the file from some unprivileged user on the system, but the exported files are already meant to become public, so I would evaluate the risk as acceptable in my situation.

On top of that, the USB drive is mounted by the system under /media/$USERNAME/ with no permissions for group or others (tested on debian bullseye but I hope it's standart). So the permissions on the filesystem on top of it don't really matter for this attack vector. An unprivileged user would not be able to read the file, if another uid mounted the usb disk.

So I would propose to change the os.umask(0o077) into os.umask(0o022) to give permissions to others to read the files, so the journalists can at least copy files to their working environment independently from their uid, when the device got mounted by themselves.

[lsd-cat]

Agreed that the permissions are not a security boundary and we should aim for proper workflow compatibility.

[rocodes]

Thanks @lsd-cat, will aim to include in #1777