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
> > t
On Thursday, April 03, 2014 08:42:32 PM Michael Pyne wrote:
> 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 unlock
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.
Apparentl
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.
>
> Co
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 open
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117157/#review54849
---
Please see different approach in https://git.reviewboard.kde.o
On Monday 31 March 2014 11:46:58 Thiago Macieira wrote:
> 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 graph
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 so
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 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 wo
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 gd
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 suc
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.
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 p
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 result
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 t
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 password
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 th
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 sentenc
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 als
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 problemati
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
> 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 h
> 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 h
> 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 ha
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 a
On Sat, Mar 29, 2014 at 11:25 PM, 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 result
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 session being killed.
You can attach gdb to ksmserver and mak
> 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 h
> 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 h
> 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 ha
> 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 h
> 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 h
> 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 ha
> 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 a
---
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 and
> 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 usecase
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117157/#review54536
---
what is the valid (read: not malicious) usecase for this?
i'd
---
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.
39 matches
Mail list logo
