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

[Hauke Laging]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20120306/bc17a0bd/attachment.pgp>