[qubes-users] Re: [qubes-devel] is intent to automatically remove empty subdirs in QubesIncoming acceptable?

[Oleg Artemiev]

On Tue, Feb 28, 2017 at 2:12 AM, Marek Marczykowski-Górecki
 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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABunX6O_qgUp_rr6XBZgzAzi_VGwZ7XpLLjYDkwGUJM9mzJLrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-devel] is intent to automatically remove empty subdirs in QubesIncoming acceptable?

[Marek Marczykowski-Górecki]

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170227231255.GE1146%40mail-itl.
For more options, visit https://groups.google.com/d/optout.