-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, Jun 10, 2017 at 12:17:29PM +0200, Patrik Hagara wrote:
> On 06/10/2017 05:47 AM, Andrew Morgan wrote:
> > Another way to mark files is to just list and later read their
> > filepaths, line-by-line. However if one is marking a folder of thousands
> > of files as untrusted, that tracking file can quickly become very long.
> > Perhaps a database option would suffice, do any of our tools use a
> > database already? I'd like to keep these efficient as possible without
> > harming the UX.
>
> How about using a DB (I'm not sure whether qubesdb would yield
> reasonable performance,
QubesDB is _not_ a persistent storage. It's a configuration exposed by
dom0 to a VM, re-created at each VM startup.
> but SQLite should work just fine for VM-local
> stuff) and monitoring files/folders via the inotify [0] API to keep
> track of new files created in untrusted folders, files getting
> deleted/renamed and generally avoiding race conditions?
This will easily desynchronize. And if that happens, a file would be
opened locally instead of in DispVM, which is a security issue.
> The API even provides events for extended attribute changes, so you
> could, theoretically, reapply them when discarded by text editors.
> However, this would likely result in more race-y behavior.
>
> One possible solution might be to create a FUSE [1] stub file system
> driver that would proxy all the FS commands to a real driver (eg. ext4),
> but discard (refuse with EPERM or similar error) all calls violating the
> "only use in dispVM" per-file/folder policy as listed in its database.
That's an interesting idea, but IMO great overkill. Proxying every fs
access, just to filter few files in Downloads directory (or such).
> Alternatively, it may be possible to use SELinux [2] object tags for
> Mandatory Access Control (MAC) -- which should be, compared to extended
> file attributes, sticky -- and write a policy that would refuse to let
> those files be open()'ed. This approach would IMO work the best, as it
> should (presumably, since SELinux is security-oriented) avoid all race
> conditions. Plus, I'd imagine it would be easier to code than a custom
> stub FUSE FS driver.
What about simply using file permissions? When a file is marked as "open
in Disposable VM", it gets extended attribute and loose read/write
access (`chmod 0 file`). Then qvm-open-in-dvm will check file permission
and extended attribute, and if file is marked as "open in Disposable
VM", it will temporarily add read access (for for the open() syscall),
read it, and send it to Disposable VM. And similarly when retrieving the
file back - it should adjust both extended attributes (preserve it) and
set file permissions to "0".
This will make user mistakes harder (not impossible, but at least
opening file by launching an editor and then selecting a file will not
work), and also allow better control over those extended attributes and
who access those files.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJZO8+VAAoJENuP0xzK19csT/AH/RRTmq1zF5wBA7T1LFztAqGY
JZvV1OoAJ79Iv5qHmibGAstDgmVa6kffbhz3jQMCxyad7EDK735box/o1wbvFf+g
bgnXxNqIVoSFdtdunjpacpA4H/H3aXWpCmwP53b+6tTlkTrObrBRd7seB5hZgDAP
4D7rXfSK7yPP/UBrJ1DlDxqknzUXeQy0tikLXKBbA8cHvdgChDnwJXhxkVl81f0H
oPnwGsSR5xVVWz2/mDlcY7hP+MCIV9TfvcvMjolG3OkbZIcfxVUvbfM8k3XPWy03
mktnSaXxUL3TT4+icEnuSPi7WZKRZxie9nWOKdcJeEK4RDM6vW3i3OJ1k5rOe5E=
=Ic5i
-----END PGP SIGNATURE-----