is intent to automatically remove empty subdirs in QubesIncoming acceptable?

16 views
Skip to first unread message

Oleg Artemiev

unread,
Feb 27, 2017, 5:23:27 PM2/27/17
to qubes...@googlegroups.com, qubes...@googlegroups.com
Hello.

From anti-forensic point of view empty dir in some app-VM in
QubesIncoming (except dom0) leaking fact of presence a VM some time
ago.

All we need is add command like "rm /home/user/QubesIncoming/*/* -p
--ignore-fail-on-non-empty" into default VM startup script for all
linux based template VMs.

I could provide a simplest pull requiest if this change will be
accepted (good if you point me to a repo where it should go). Should
I?

--
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

Marek Marczykowski-Górecki

unread,
Feb 27, 2017, 6:13:00 PM2/27/17
to Oleg Artemiev, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Feb 28, 2017 at 01:23:24AM +0300, Oleg Artemiev wrote:
> Hello.
>
> From anti-forensic point of view empty dir in some app-VM in
> QubesIncoming (except dom0) leaking fact of presence a VM some time
> ago.
>
> All we need is add command like "rm /home/user/QubesIncoming/*/* -p
> --ignore-fail-on-non-empty" into default VM startup script for all
> linux based template VMs.

This particular command looks dangerous - you probably meant rmdir
instead. And probably one '*' less. Or actually more ('**', after
enabling 'starglob' shell option).
Maybe something like this instead:

find /home/user/QubesIncoming -type d -empty -delete

Anyway, I don't think it should be enabled by default - automatic
removal (or in any other way altering) user files in home directory is
not something we'd like to do. If anything, it should be disabled by
default.

As for anti-forensic - I'd expect that there are much more places like
this - like file manager cache/history, shell history, various
application's caches etc. If you want non-persistence (of VM existence
fact in this case), use DispVMs.

> I could provide a simplest pull requiest if this change will be
> accepted (good if you point me to a repo where it should go). Should
> I?
>

- --
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

iQEcBAEBCAAGBQJYtLJ2AAoJENuP0xzK19csVh8H/i/QgWKBhd8QWDMBimqNdM6y
cDQMw9h4rdndOc5MuxI1Wilyy+e6DgoXKdXLslruQteCRgSM1F95eA8A50S+KQUF
pNjiW+821Y0MADdQJzHKNRdVFPg82OmzWbl/uvEArSavJsLURLDrm/kFu852Gy7T
bEuSR8945RVMxkMCD0oqbWAdY48KkffCB0RXLANiJphR60S9yh/Q+cyNcnUAFzi/
BgtR8A3U64Fm5fASBdkLvaikkPBpf3yOSBfUP4SsD107Yve0A9nQyxSaMNM5oobk
Au/GR6kSfDCg0VA4j1lxj8JRZ1QKuIx3AJSg9bJr4YN5sQnaPUR7Bf9H3UT4QDU=
=l2YV
-----END PGP SIGNATURE-----

Oleg Artemiev

unread,
Feb 27, 2017, 7:50:12 PM2/27/17
to Marek Marczykowski-Górecki, qubes...@googlegroups.com, qubes...@googlegroups.com
On Tue, Feb 28, 2017 at 2:12 AM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Tue, Feb 28, 2017 at 01:23:24AM +0300, Oleg Artemiev wrote:
>> Hello.
>>
>> From anti-forensic point of view empty dir in some app-VM in
>> QubesIncoming (except dom0) leaking fact of presence a VM some time
>> ago.
>>
>> All we need is add command like "rm /home/user/QubesIncoming/*/* -p
>> --ignore-fail-on-non-empty" into default VM startup script for all
>> linux based template VMs.
>
> This particular command looks dangerous - you probably meant rmdir
> instead.
yep

> And probably one '*' less. Or actually more ('**', after
> enabling 'starglob' shell option).
> Maybe something like this instead:
> find /home/user/QubesIncoming -type d -empty -delete
also good. linux rmdir always ignore non-emty directories and all files.

After reading your reply I changed my opinion - no ''**' - only one
'*' or if made by find - add maxdepth 1 to never touch
sub-dirs below source VM name - user may copy some hierarchy. Though
user usualy has no need to create the 1st level subdir in
QubesIncoming - this is made by file copy utils.

> Anyway, I don't think it should be enabled by default - automatic
> removal (or in any other way altering) user files in home directory is
> not something we'd like to do. If anything, it should be disabled by
> default.
This is not _user_ content, at least from the moment the user has deleted
all content of a sub-directory under the QubesIncoming and it is empty.

This _directory_ artefact is created by OS file handling tools on user
intent to copy a _file_ and is unneeded anymore = is not properly
cleaned. Even more - having these empty dirs is somewhat attention
stealer - a few months later user may probably spend time doing 'ls'
there - to
be sure nothing forgotten there.

> As for anti-forensic - I'd expect that there are much more places like
> this - like file manager cache/history,
oops.. didn't think about this. Isn't those expire? QubesIncoming
sub-dirs aren't ever.

> shell history,
only if data copied in both direction.

> various application's caches etc.
any cache should expire. Directories persist till removal.

> If you want non-persistence (of VM existence
> fact in this case), use DispVMs.
When I copy from some hidden_app_vm to some not-that-hidden-appvm and
want those files be in not-that-hidden-appvm finally - dispVM
as proxy for copying will solve all. Though if that will be cleaned
up w/o my intervention it could be just better.

>> I could provide a simplest pull requiest if this change will be
>> accepted (good if you point me to a repo where it should go). Should
>> I?
intent not accepted. ok
Reply all
Reply to author
Forward
0 new messages