[Plasma Vault] [Bug 385984] Activity integration can be more fine-grained.

[Matthias Kretz]

https://bugs.kde.org/show_bug.cgi?id=385984

Matthias Kretz  changed:

   What|Removed |Added

 CC||kr...@kde.org

--- Comment #6 from Matthias Kretz  ---
I just wanted to mention another option: Opening and closing the vault could be
linked to starting and stopping an activity. Conceptually, while the activity
is not stopped, I'm saying I'm multitasking on several activities at once. So
why would I want the vault closed. Having the vault opened when starting the
activity would also enable the use of e.g. files linked to the activity inside
of the vault to show up in a folder view desktop.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Plasma Vault] [Bug 385984] Activity integration can be more fine-grained.

[Ivan Čukić]

https://bugs.kde.org/show_bug.cgi?id=385984

Ivan Čukić  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #5 from Ivan Čukić  ---

> What about we add the following auto-close behaviour;
>
> * on screensaver start.
> * 120 seconds after we stopped being on one of the associated activities.

That sounds good. One thing that I'd add - having the delay option in
~/.config/plasmavaultrc without exposing it in the UI - for people who really
really want to change the default. :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[Plasma Vault] [Bug 385984] Activity integration can be more fine-grained.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=385984

--- Comment #4 from cryptod...@libertymail.net ---
> For the same reason, I don't expect people to have the habit to close 
> the vaults manually.

I can understand that point :)

> My main question here is this - what is the use-case of Vault being visible
> only in certain activities, but being open but hidden (hidden only in the
> applet, and only if the vault is currently closed*) in others?

The main reason I suggested it is to avoid accidental closes. If it closes too
often people will stop using the auto-close and we'd be hurting the security we
were aiming for.

I fully agree on your point of checkbox-overload. I never figured out how the
kwallet auto-close stuff worked. The UI is too complex for me.

One thing that the kwallet auto-close has is a feature that closes it after 10
minutes of no app accessing the kwallet. I think we can mirror this by
replacing the idea of application with activity.
So if we leave our activity of choice for more than N seconds, we close it.
That would satisfy my reasons for this report.

I would do that without a configurable GUI, I personally think that closing on
screensaver start should also be default and not GUI configurable. So theres
that.

So, building on your idea, the only UI is we can optionally associate a vault
to an activity. So no change.

What about we add the following auto-close behaviour;

* on screensaver start.
* 120 seconds after we stopped being on one of the associated activities.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Plasma Vault] [Bug 385984] Activity integration can be more fine-grained.

[Ivan Čukić]

https://bugs.kde.org/show_bug.cgi?id=385984

--- Comment #3 from Ivan Čukić  ---

> Protecting against non-root users is actually pretty easy, just make sure 
> that the
> vault is read protected (chmod 700) and you are good.

The problem is not in the non-root-non-us users. If that was the main problem,
then having an encrypted $HOME (which most distributions I've tried support)
would be a good solution.

Here, the main aim is to thwart malicious people that pretend to be us.
>From co-workers that might have the access to our system while we go to
the kitchen to brew a cup of tea, to hackers that managed to get into
our use account.

The rationale behind the current design is that most people do not have
the habit to lock their computers when they leave them, but instead rely
on the screen locker to pop up after some time passed.

For the same reason, I don't expect people to have the habit to close 
the vaults manually.


> Your workflow doesn't reflect mine, I often switch activities just for a 
> couple of
> seconds to check on the progress of something for instance. (I have an 
> activity
> for all my virtual machines, for instance, where i may install a piece of 
> software
> or do a system upgrade).

This is a fair point. I also sometimes switch activities for a moment - but
so far I haven't seen this as a problem. Sometimes the vault gets closed 
when I didn't want it to (most of the time it stays open because an application
is a accessing it) and I have to reopen it.


> I'm hoping you can make that a little more flexible to allow this software 
> to be used for more people that don't all work the same way you do.

My main question here is this - what is the use-case of Vault being visible
only in certain activities, but being open but hidden (hidden only in the
applet,
and only if the vault is currently closed*) in others?

One thing that we could do here, if the use-case fits into this, is to add the
following configuration options (all on by default):

Automatically close:

[x] When switching from an activity the vault is linked to
[x] When the screen locker is activated

I'd like to avoid per-vault configuration for this if it is possible.



*) I don't want to ever hide an open Vault - it would make it even easier
to forget that something is unlocked.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Plasma Vault] [Bug 385984] Activity integration can be more fine-grained.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=385984

--- Comment #2 from cryptod...@libertymail.net ---
I'm all for taking security seriously, maybe its good to take a look at the
thread-assessment for these kind of FUSE mounts.

We obviously want to make sure that users that are not 'us' do not have access
to either the encrypted or decrypted files. Definitely not the decrypted,
obviously, not giving access to the encrypted files is easy with filesystem
permissions and as such it gives us protection against brute-forcing.

The exception to this is the administrator (aka root). But we have to be honest
here, root can install keystroke-loggers, change plasma-vault to one that just
writes the password to a file and anything else you can come up with.
Protecting against root is useless.

Protecting against non-root users is actually pretty easy, just make sure that
the vault is read protected (chmod 700) and you are good.


With these facts, I'm personally absolutely fine that as long as I'm personally
sitting behind my system, the vault is open. I honestly see no security
implications doing otherwise.


Your workflow doesn't reflect mine, I often switch activities just for a couple
of seconds to check on the progress of something for instance. (I have an
activity for all my virtual machines, for instance, where i may install a piece
of software or do a system upgrade).


When you write;
"Vaults are meant to be smaller containers that should be open for as short as
possible."

I'm hoping you can make that a little more flexible to allow this software to
be used for more people that don't all work the same way you do.

For instance I worked in my vault for most of the day yesterday working on some
data files and then some Scribus files to print those to a PDF. The vault was
open for at least 6 hours. And its giving me a peace of mind that they are
still "locked up" today.

Thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.

[Plasma Vault] [Bug 385984] Activity integration can be more fine-grained.

[Ivan Čukić]

https://bugs.kde.org/show_bug.cgi?id=385984

--- Comment #1 from Ivan Čukić  ---


> What took me by surprise is that limiting a vault to an activity
> will actively attempt to close the vault when you go to another one. 
> I don't see the point of that.

The problem with full-device encryption is that once you log in, everything is
accessible to people who have access to your system.

Vaults are meant to be smaller containers that should be open for as short as
possible. When you switch to another activity, this implies you stopped working
on the project you worked on in the previous activity, and the vault
automatically closes to minimize the time it is kept open. Having to manually
close a vault is problematic for forgetful users (myself included).

If it is not possible to close it (an application is using it), you get a
notification with an option to kill the applications and forcefully close the
vault.

Automatic closing will also be implemented for when the screen locker is
started, and similar situations.


As far as the recent documents are concerned, the files belonging to a vault
will not be tracked in future at all (like the "Baloo" issue). We do not have
the infrastructure to have distributed databases for usage statistics and text
indexing to allow "chunks" of the database to be stored in a separate file
located in an encrypted directory.

-- 
You are receiving this mail because:
You are watching all bug changes.