On Freitag, 4. April 2014 02:42:32 CEST, Michael Pyne wrote:
Of course if an attacker is running code they'd probably just
find it easier
to open the .kwl directly and read the folder and key names,
since apparently
those are stored unencrypted, if the API docs are to be believed.
On Friday, April 04, 2014 10:08:36 PM Thomas Lübking wrote:
On Freitag, 4. April 2014 02:42:32 CEST, Michael Pyne wrote:
Of course if an attacker is running code they'd probably just
find it easier
to open the .kwl directly and read the folder and key names,
since apparently
those are
On Sunday, March 30, 2014 05:25:58 PM Michael Pyne wrote:
In fact the list of folders and keys present in KWallet (though
not their values) can be queried without unlocking KWallet, or even causing
it to prompt to unlock.
AFAIK, all data access operations on KWallet require it to be opened
On Fri, April 4, 2014 02:20:28 Valentin Rusu wrote:
On Sunday, March 30, 2014 05:25:58 PM Michael Pyne wrote:
In fact the list of folders and keys present in KWallet (though
not their values) can be queried without unlocking KWallet, or even
causing
it to prompt to unlock.
Could you
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117157/#review54849
---
Please see different approach in
On Sunday 30 March 2014 18:06:52 Thiago Macieira wrote:
Leaving access to an open shell is certainly bad enough - beyond question.
The question is whether gaining direct access to a running session and
random open clients (and leaving the stage untraced) is more valuable and
thus worth
Em seg 31 mar 2014, às 08:55:05, Martin Gräßlin escreveu:
Personally I have to disagree. To me the graphical login is a an asset
which needs to be protected in a stronger way. Access to a tty should not
equal access to the graphical system. The fact that X is broken should not
result in us
On Sunday 30 March 2014 15:36:29 Thiago Macieira wrote:
Em seg 31 mar 2014, às 00:01:13, Thomas Lübking escreveu:
If they can gain access to a TTY login we are already screwed
leaving aside the present issue (/MainApplication quit being exposed
to dbus) and given ptrace (gdb solution)
On Sonntag, 30. März 2014 00:07:15 CEST, Martin Klapetek wrote:
However many distros disable gdb attach to running processes by default;
you have to either be root or echo 1 somewhere in /proc (for which you also
need to be root).
/proc/sys/kernel/yama/ptrace_scope
On top of this, one could
On March 29, 2014, 1:05 p.m., Martin Gräßlin wrote:
I also have problems imagining what a use case for this is and I consider
this as a security issue. It basically means that the session can get
unlocked without going through authentication.
Kirill Elagin wrote:
You have to
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote:
I also have problems imagining what a use case for this is and I consider
this as a security issue. It basically means that the session can get
unlocked without going through authentication.
Kirill Elagin wrote:
You have to
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote:
I also have problems imagining what a use case for this is and I consider
this as a security issue. It basically means that the session can get
unlocked without going through authentication.
Kirill Elagin wrote:
You have to
Em dom 30 mar 2014, às 10:12:11, Thomas Lübking escreveu:
On Sonntag, 30. März 2014 00:07:15 CEST, Martin Klapetek wrote:
However many distros disable gdb attach to running processes by default;
you have to either be root or echo 1 somewhere in /proc (for which you
also
need to be root).
Em dom 30 mar 2014, às 10:10:06, Thomas Lübking escreveu:
un/locking depending on HW dongles (bluetooth, USB) is certainly a nice
feature, but requires some sort of internal support (where you'd just
configure the HW id to trigger this)
Unlocking via a dbus command is imo very problematic.
On Sonntag, 30. März 2014 19:14:32 CEST, Thiago Macieira wrote:
/proc/sys/kernel/yama/ptrace_scope
I'd never heard of Yama.
https://www.kernel.org/doc/Documentation/security/Yama.txt
Kinda new, but it's a stock kernel feature:
http://kernelnewbies.org/Linux_3.4
On top of this, one could
On Sonntag, 30. März 2014 19:26:21 CEST, Thiago Macieira wrote:
Em dom 30 mar 2014, às 10:10:06, Thomas Lübking escreveu:
Unlocking via a dbus command is imo very problematic.
I disagree. The user already authenticated via their password
I should have been more precise in the first
Em dom 30 mar 2014, às 19:38:14, Thomas Lübking escreveu:
I disagree. The user already authenticated via their password
I should have been more precise in the first sentence:
Unlocking via a dbus command [that requires password authentication] is
imo very problematic [because that
On Sonntag, 30. März 2014 20:53:01 CEST, Thiago Macieira wrote:
Em dom 30 mar 2014, às 19:38:14, Thomas Lübking escreveu:
Unlocking via a dbus command [that requires password authentication] is
imo very problematic [because that will end up exposing the password
on-disk]
How does the
Em dom 30 mar 2014, às 21:40:36, Thomas Lübking escreveu:
On Sonntag, 30. März 2014 20:53:01 CEST, Thiago Macieira wrote:
Em dom 30 mar 2014, às 19:38:14, Thomas Lübking escreveu:
Unlocking via a dbus command [that requires password authentication] is
imo very problematic [because that will
On Sat, March 29, 2014 15:25:59 Thiago Macieira wrote:
Em sáb 29 mar 2014, às 12:25:48, Martin Gräßlin escreveu:
no, the lockscreen is secure. If you are logged in at a tty there is no
way
to unlock the screen - the only way to bypass the lock is to kill
ksmserver
which results in the
On Sonntag, 30. März 2014 23:25:58 CEST, Michael Pyne wrote:
I'll note I've actually done this before, during the
development process for
the new QML-based screenlocker.
Me fixed the issue in the greeter code (while doing multiscreen/input
handling), installed the greeter and SIGTERM'd the
Em seg 31 mar 2014, às 00:01:13, Thomas Lübking escreveu:
If they can gain access to a TTY login we are already screwed
leaving aside the present issue (/MainApplication quit being exposed to
dbus) and given ptrace (gdb solution) is denied: in how far? (beyond
killing the session, ie. being
On Montag, 31. März 2014 00:36:29 CEST, Thiago Macieira wrote:
They can already access all of the other applications
depends on whether they actively suppress such.
and the user's files.
true.
They can attach gdb to any of the user processes.
depends on whether they actively suppress
Em seg 31 mar 2014, às 01:43:22, Thomas Lübking escreveu:
On Montag, 31. März 2014 00:36:29 CEST, Thiago Macieira wrote:
They can already access all of the other applications
depends on whether they actively suppress such.
and the user's files.
true.
They can attach gdb to any of
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117157/
---
(Updated March 29, 2014, 11:58 a.m.)
Review request for kde-workspace.
On March 29, 2014, 12:02 p.m., Thomas Lübking wrote:
what is the valid (read: not malicious) usecase for this?
i'd rather say that if quitting the greeter to exit the lock w/o password,
that should be fixed to *not* exit the lock w/o password provision.
There are some usecases
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117157/#review54538
---
I also have problems imagining what a use case for this is
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote:
I also have problems imagining what a use case for this is and I consider
this as a security issue. It basically means that the session can get
unlocked without going through authentication.
You have to authenticate anyway to access
On March 29, 2014, 1:05 p.m., Martin Gräßlin wrote:
I also have problems imagining what a use case for this is and I consider
this as a security issue. It basically means that the session can get
unlocked without going through authentication.
Kirill Elagin wrote:
You have to
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote:
I also have problems imagining what a use case for this is and I consider
this as a security issue. It basically means that the session can get
unlocked without going through authentication.
Kirill Elagin wrote:
You have to
On March 29, 2014, 1:05 p.m., Martin Gräßlin wrote:
I also have problems imagining what a use case for this is and I consider
this as a security issue. It basically means that the session can get
unlocked without going through authentication.
Kirill Elagin wrote:
You have to
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote:
I also have problems imagining what a use case for this is and I consider
this as a security issue. It basically means that the session can get
unlocked without going through authentication.
Kirill Elagin wrote:
You have to
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote:
I also have problems imagining what a use case for this is and I consider
this as a security issue. It basically means that the session can get
unlocked without going through authentication.
Kirill Elagin wrote:
You have to
33 matches
Mail list logo
