On Wed, 07 Sep 2016 at 03:20:31 +0530, Ramakrishnan Muthukrishnan wrote:
> On Wed, Sep 7, 2016, at 02:07 AM, Daniel Kahn Gillmor wrote:
> > To be clear: i think you're doing these operations separately because
> > you don't want to expose your secret key material to the Main Account.
> >
> > Is that right?
>
> Yes, that's correct. This is a work computer that I occasionally use
> only during travel and I was concerned that any non-free binaries that I
> may have to run at work does dubious stuff on these important files.
> While one could probably find holes in this argument, I thought it is a
> good first step to protect the keys via the good old Unix userid based
> access control mechanisms.
Sorry for digging up this old bug report thread, but I saw a reference
to it on debian-devel recently, and my reply there applies equally here:
Note that if you are trying to protect your key material from a
possibly-compromised main user account, switching from the main account
to the keyring account with su is not particularly effective: if the main
account can su to the keyring account, then it can run arbitrary code as
the keyring account. (The need to type a password into su mitigates this,
but anything in your X session could act as a keylogger to capture your
password for future use, so that's a weak protection at best.)
For real privilege-separation I would recommend making use of "fast
user switching" between different VTs, for example GNOME's "Switch User"
menu option for a graphical login, or Ctrl+Alt+F6 and starting a separate
text-mode login session.
Alternatively, you could move your key material onto a cryptographic token
(smart card) like a Nitrokey, Yubikey, Gnuk or similar.
smcv
