On Monday 18 October 2010, Faramir wrote:
El 17-10-2010 22:09, Doug Barton escribió:
On 10/17/2010 5:43 PM, Faramir wrote:
|That may be true. However, remember feeling secure is part of
|security
|
| too, so if that feature doesn't break anything, and make people
| sleep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
El 15-10-2010 14:31, Doug Barton escribió:
On 10/15/2010 9:23 AM, Werner Koch wrote:
Nevertheless, the confirmation prompt for a cached passphrase is not
entirely unfounded
...
The other problem with the confirmation proposal is that (unless I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
El 15-10-2010 20:29, Jameson Rollins escribió:
No, I was just curious why, if you were an ssh-agent user, you would be
ok with the implementation there but not for gpg-agent. If you're not
an ssh-agent user then you have nothing to get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/17/2010 5:43 PM, Faramir wrote:
|
|That may be true. However, remember feeling secure is part of security
| too, so if that feature doesn't break anything, and make people sleep
| better...
Two problems with that theory. The first is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
El 17-10-2010 22:09, Doug Barton escribió:
On 10/17/2010 5:43 PM, Faramir wrote:
|
|That may be true. However, remember feeling secure is part of security
| too, so if that feature doesn't break anything, and make people sleep
| better...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
El 17-10-2010 23:47, Robert J. Hansen escribió:
...
And if one day the user finds it has been disabled somehow, the user
might become aware of some malware in the machine...
By this logic every user should have a big piece of Scotch tape on
On Wed, 13 Oct 2010 17:51, d...@fifthhorseman.net said:
If i run the agent locally, and forward access to it to a constrained
account, then the constrained account (which is talking to the agent)
*does not* have the ability to simulate such X11 events.
You mean to a different X server? For
Am Freitag 15 Oktober 2010 12:28:33 schrieb Werner Koch:
If there is malicious code running on your machine with access to
resources under your control, I can only say: game over. No external
button will help you here.
That's why we try to restrict the access of malicious code, isn't it?
On Thu, 14 Oct 2010 20:03, sascha-ml-reply-to-201...@silbe.org said:
One instance where the proposed mechanism (in conjunction with the new
version of gpg-agent that will handle the secret keys itself) would be
Just for the records: This is no new mechanism of the agent. It is in
use for
On Fri, 15 Oct 2010 12:55, mailinglis...@hauke-laging.de said:
Following your pessimistic attitude there would hardly be any reason not to
work as root.
Nope. Not working under root is important to keep the system stable and
provide access restrictions to the non-malicious users.
OTOH, it
On 10/15/2010 9:23 AM, Werner Koch wrote:
Nevertheless, the confirmation prompt for a cached passphrase is not
entirely unfounded
I've really been biting my tongue on this thread because it seemed like
the right people were saying the right things already, but you're making
me nervous now
On 10/15/10 1:31 PM, Doug Barton wrote:
The other problem with the confirmation proposal is that ... the
intersection between plausible attack vectors and vulnerabilities
that [this proposal] would actually fix seems [very] small.
I seem to recall saying something similar to this a few days
On 10/15/10 2:49 PM, Jameson Rollins wrote:
Without use confirmation in the agent, a malicious program running under
your account could access your secret key without you knowing it.
This can still happen with a confirmation prompt. Confirmation cannot
protect against malware running under
Ok, then this protects against malicious programs that are not
intercepting the dialog box.
Which means that six months after this feature gets implemented, the malware
authors will write exploits that intercept the dialog box.
Arms races are inevitable, but stupid arms races should be
On 10/15/10 5:04 PM, Jameson Rollins wrote:
Don't let the perfect be the enemy of the good.
But is it good? To me this feature seems like security theater. It
makes you feel all warm and fuzzy and lets you sleep at night, but
doesn't provide any real protection.
Is it good to have users
On Fri, 15 Oct 2010 18:23:04 -0400, Robert J. Hansen r...@sixdemonbag.org
wrote:
I'm not. This idea isn't good.
Do you use ssh-agent? Do you think their implementation of the same
thing is not good? If so, have you complained to them about it, or
asked why the implemented it?
jamie.
Am Samstag 16 Oktober 2010 00:23:04 schrieb Robert J. Hansen:
Ok, then this protects against malicious programs that are not
intercepting the dialog box.
Which means that six months after this feature gets implemented, the
malware authors will write exploits that intercept the dialog box.
Do you use ssh-agent? Do you think their implementation of the same
thing is not good? If so, have you complained to them about it, or
asked why the implemented it?
This seems to be an argument from implication of hypocrisy: as if, were I a
user of ssh-agent, my opinion regarding gpg-agent
This implies the strange claim that it will forever be possible to do that.
It does not. It states that at present the OS infrastructure we have makes
implementing this a losing proposition.
As soon as the OS infrastructure changes enough to make this a winner, then we
should revisit this
On Sat, 16 Oct 2010 01:05:11 +0200, Hauke Laging
mailinglis...@hauke-laging.de wrote:
I just don't like the idea that access to the agent is not noticed by
design.
I strongly agree with this point. Let's think about it another way:
what if the user is themselves doing something that is
On Fri, 15 Oct 2010 19:12:21 -0400, Robert J. Hansen r...@sixdemonbag.org
wrote:
Do you use ssh-agent? Do you think their implementation of the same
thing is not good? If so, have you complained to them about it, or
asked why the implemented it?
This seems to be an argument from
I strongly agree with this point. Let's think about it another way:
what if the user is themselves doing something that is unintentionally
accessing the key?
Then that's the user's own problem. They're the one who decided to enable
passphrase caching and to set a large timeout window. They
On 10/13/2010 07:02 PM, MFPA wrote:
The user can type their password once per session into a text file and
paste it every time it is requested. This reduces the annoyance factor
and does not train the user to constantly re-type the passphrase.
This strikes me as the worst suggestion on this
also sprach MFPA expires2...@ymail.com [2010.10.14.0102 +0200]:
The user can type their password once per session into a text file
and paste it every time it is requested. This reduces the
annoyance factor and does not train the user to constantly re-type
the passphrase.
That's a great idea.
On 13/10/2010 4:02 PM, MFPA wrote:
The user can type their password once per session into a text file and
paste it every time it is requested. This reduces the annoyance factor
and does not train the user to constantly re-type the passphrase.
I use a program called KeePass to keep track of my
Excerpts from Robert J. Hansen's message of Tue Oct 12 15:25:50 +0200 2010:
These two attack modes (root and user access) cover the overwhelming
majority of instances today, so already this hypothetical attack is an
exotic.
That most mainstream systems are painfully easy to attack doesn't
On 10/13/10 11:51 AM, Daniel Kahn Gillmor wrote:
From a different perspective, i could run the agent itself in a
constrained account, and replace the prompting tool with a tool that
requires, say, an ACPI event, or a special keypress (not an X11 event)
from a designated hardware button. in
On 10/14/2010 04:31 PM, Grant Olson wrote:
But ultimately once you start trying to fix the problem by offloading
the checks to special hardware, you might as well just key a smart card
reader with an integrated keypad. Then you can use a simple pin. Not
quite as convenient as hitting Y/N,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 14 October 2010 at 3:18:47 PM, in
mid:4cb71147.5090...@fifthhorseman.net, Daniel Kahn Gillmor wrote:
This strikes me as the worst suggestion on this thread
so far. Please, do not store the passphrase to your
secret key in the
Am Dienstag 12 Oktober 2010 04:44:41 schrieb Daniel Kahn Gillmor:
(e.g. one process can send a simulated mouseclick to another process
pretty easily)
I am not familiar with X details (let alone that other one OS). Does grabbing
the mouse prevent other processes from knowing where the click
On Thu, October 14, 2010 4:54 pm, Daniel Kahn Gillmor wrote:
On 10/14/2010 04:31 PM, Grant Olson wrote:
But ultimately once you start trying to fix the problem by offloading
the checks to special hardware, you might as well just key a smart card
reader with an integrated keypad. Then you can
On 10/12/2010 02:46 PM, Werner Koch wrote:
Anyway, if you are already have these permissions you can attack the
keys with all kind of simple tricks. Thus it is mood.
i'm not convinced it's moot, especially if i understand the model you're
advancing for the agent for 2.1 correctly.
If i run
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Tuesday 12 October 2010 at 4:05:45 AM, in
mid:4cb3d089.3010...@fifthhorseman.net, Daniel Kahn Gillmor wrote:
re-entering the passphrase each time is significantly
more annoying than confirming its use in a reasonable
context. (and
On Tue, 12 Oct 2010 04:44, d...@fifthhorseman.net said:
(e.g. one process can send a simulated mouseclick to another process
pretty easily) but that doesn't mean no one is running with a
The standard pinentry grabs mouse and keyboard and thus we should be
protected against this kind of attack.
On 10/12/2010 02:26 AM, Werner Koch wrote:
On Tue, 12 Oct 2010 04:44, d...@fifthhorseman.net said:
(e.g. one process can send a simulated mouseclick to another process
pretty easily) but that doesn't mean no one is running with a
The standard pinentry grabs mouse and keyboard and thus we
Am Dienstag 12 Oktober 2010 06:34:48 schrieb Robert J. Hansen:
If my attack gives me unprivileged access I'm going to escalate it to root.
going to, yes.
This is straight out of the malware
playbook, and malware authors have a great many ways to achieve it.
I think that it is not useful
Am Dienstag 12 Oktober 2010 09:05:56 schrieb Daniel Kahn Gillmor:
I think that grabbing mouse and kbd prevents other tools from *reading*
the kbd and mouse events. It doesn't prevent synthesized events from
triggering those inputs (e.g. clicking OK on a button).
But this may change in the
On 10/12/2010 1:54 AM, Daniel Kahn Gillmor wrote:
yes, of course this isn't going to be able to protect the user from
someone with full access to their user account or their current session.
These two attack modes (root and user access) cover the overwhelming
majority of instances today, so
On Tue, 12 Oct 2010 09:05, d...@fifthhorseman.net said:
the kbd and mouse events. It doesn't prevent synthesized events from
triggering those inputs (e.g. clicking OK on a button).
You are right. However it is the only protection we can use on X; it
might be helpful in some cases, but as you
On Tue, 12 Oct 2010 11:10, mailinglis...@hauke-laging.de said:
There are ways to prevent this. E.g. I protect important and hardly ever
changed files like ~/.gnupg/options with root priviledge (chattr immutable on
It doesn't help - you need to protect gpg.conf and gpg.conf-2 and
gpg.conf-2.0
Hello,
I just had the idea that it might be a good countermeasure against malicious
software not to use a cached passphrase without any user interaction (and thus
without user notice). A good compromise would be to open a dialog which does
not ask for the passphrase but just for the
On 10/11/2010 09:25 PM, Hauke Laging wrote:
I just had the idea that it might be a good countermeasure against malicious
software not to use a cached passphrase without any user interaction (and
thus
without user notice). A good compromise would be to open a dialog which does
not ask for
On 10/11/2010 9:25 PM, Hauke Laging wrote:
I just had the idea that it might be a good countermeasure against
malicious software not to use a cached passphrase without any user
interaction (and thus without user notice).
The most obvious way I see to circumvent this involves throwing a
On 10/11/2010 10:20 PM, Robert J. Hansen wrote:
On 10/11/2010 9:25 PM, Hauke Laging wrote:
I just had the idea that it might be a good countermeasure against
malicious software not to use a cached passphrase without any user
interaction (and thus without user notice).
The most obvious way
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hauke Laging wrote:
Hello,
I just had the idea that it might be a good countermeasure against malicious
software not to use a cached passphrase without any user interaction (and
thus
without user notice). A good compromise would be to open a
On 10/11/2010 09:56 PM, Larry Brower wrote:
This seems like something that would get really annoying really
quickly. Why not just change settings to not cache the passphrase if
you do not like using it this way ?
re-entering the passphrase each time is significantly more annoying than
On 10/11/2010 10:44 PM, Daniel Kahn Gillmor wrote:
It would help against the situation where the malicious client does
*not* have superuser access and cannot directly override the prompting
mechanism through other mechanisms.
This attack mode appears to me to be so niche that I don't see any
On 10/12/2010 12:34 AM, Robert J. Hansen wrote:
Heck, this doesn't even defend against an *unprivileged* attack. Give
me unprivileged access to your user account I'll edit your .profile to
put a .malware/ subdirectory on your PATH and drop my trojaned GnuPG in
there. Once the malware
48 matches
Mail list logo
