Mailing List Archive: GnuPG: users

Separate user account (was Re: invalid gpg key revocation)

Index | Next | Previous | View Threaded

peter at digitalbrains

Mar 6, 2012, 1:00 PM

Post #1 of 3 (252 views)
Permalink

Separate user account (was Re: invalid gpg key revocation)

On 06/03/12 21:14, Hauke Laging wrote:
> You probably don't even use a seperate user account for key handling.

I don't even do that either. Sounds to me like mainly snake oil with an
insignificantly reduced actual hacking risk.

To clarify, an attacker is able to get into your personal user account on your
desktop machine, but then unable to escalate his privileges to administrator
level? That's an odd combination of skills and lack of skills at the same time.

It only takes one vulnerable program which he can (install and?) run. Or he just
needs to wait until you become superuser from your own user account and hitch
the ride.

And you also can't access that separate user account from your own, or you face
the same problem: the attacker is effectively you on your personal account.
Watches you access the separate user account, and bingo.

These are just the most obvious ones. The subtle ones are probably much cooler.
I'm not a hacker.

>> I need to fix my mistake so that it does not happen again.
>
> Above you refused to do so because it was too much effort for you.

I find this unnecessarily harshly formulated. He hasn't refused to do anything,
even though he's not making it easy by being so secretive.

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

mailinglisten at hauke-laging

Mar 6, 2012, 1:31 PM

Post #2 of 3 (229 views)
Permalink

Re: Separate user account (was Re: invalid gpg key revocation) [In reply to]

Am Dienstag, 6. März 2012, 22:00:05 schrieb Peter Lebbing:
> On 06/03/12 21:14, Hauke Laging wrote:
> > You probably don't even use a seperate user account for key handling.
>
> I don't even do that either.

So don't I.

> Sounds to me like mainly snake oil with an
> insignificantly reduced actual hacking risk.

That certainly depends on the way you use the system.

> To clarify, an attacker is able to get into your personal user account on
> your desktop machine, but then unable to escalate his privileges to
> administrator level? That's an odd combination of skills and lack of
> skills at the same time.

AFAIK there is nearly no skill level required in order to get into an average
user account. There is software which creates malware. You don't have to write
it yourself. Just wait for the next exploit in a widely used (or known to be
used) software.

> Or he
> just needs to wait until you become superuser from your own user account
> and hitch the ride.

That's obviously something one shouldn't do then.

> And you also can't access that separate user account from your own, or you
> face the same problem: the attacker is effectively you on your personal
> account. Watches you access the separate user account, and bingo.

Not being an expert I consider user switching safe both under Windows and
Linux.

> These are just the most obvious ones. The subtle ones are probably much
> cooler. I'm not a hacker.

Sure, but there's cool stuff on the other side, too. A user need not be
capable of installing software. A processes capabilities can be limited (I run
my Internet software under AppArmor profiles). The access to X can be limited.

I see the biggest problem in hijacking a running process by feeding in data
that exploits a bug and thus being able to read and write data locally and
over the Internet with the biggest threat (on a well configured system) being
a privilege escalation bug in the kernel which can be triggered from the
hijacked process.

Some time ago I suggested on this list to add an option to gpg-agent which
would open a message box every time a cached passphrase is used. I don't like
the idea that I don't know what gpg-agent is doing. This suggestion was denied
with the argument that the overall security level was so low that there were
many possibilities to deactivate (or even manipulate) such a feature and thus
it would just give a false feeling of security...

> >> I need to fix my mistake so that it does not happen again.
> >
> > Above you refused to do so because it was too much effort for you.
>
> I find this unnecessarily harshly formulated. He hasn't refused to do
> anything, even though he's not making it easy by being so secretive.

Then I misunderstood him. I remember that he objected to the idea of having
completely seperate environments as a reliable key protection.

What do you have to to to be "really" safe?

1) Boot the system from a read-only medium.

2) Read the data from the unsafe medium.

3) Create the signature.

4) Take the key and signature out of the current environment.

5) The fun part (for most data types): Check (on as many different systems as
"seems" necessary) whether the data is correct (how do you search for unknown
exploits?).

6) Make the signature available to the unsafe world.

Hauke
--
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

Attachments:

signature.asc (0.54 KB)

peter at digitalbrains

Mar 6, 2012, 1:51 PM

Post #3 of 3 (235 views)
Permalink

Re: Separate user account (was Re: invalid gpg key revocation) [In reply to]

On 06/03/12 22:31, Hauke Laging wrote:
> AFAIK there is nearly no skill level required in order to get into an average
> user account. There is software which creates malware. You don't have to
> write it yourself. Just wait for the next exploit in a widely used (or known
> to be used) software.

I don't see the counterargument here: why is the situation different for
becoming that other user account or the superuser? Just because they use less
programs? Wait slightly longer, for an exploit in the programs that do expose
those accounts.

BTW, I do hope there is some skill level needed to get into the user account of,
for example, seasoned computer users (remotely, not counting physical
access). For a suitable definition of "seasoned".

>> Or he just needs to wait until you become superuser from your own user
>> account and hitch the ride.
>
> That's obviously something one shouldn't do then.

Yes, I get that. Like I said, I only gave the obvious ones. Unfortunately the
small-scale remedy to those is also obvious. However, you might plug a hole, but
the sieve as a whole keeps going.

> Sure, but there's cool stuff on the other side, too. A user need not be
> capable of installing software. A processes capabilities can be limited (I
> run my Internet software under AppArmor profiles). The access to X can be
> limited.

I'm not saying you should give up protecting yourself. I just don't see a
significant role of the separate user account in those efforts.

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads