[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gpg: "Warning: using shared memory" - SUID?



On Thu, Nov 30, 2000 at 12:05:58PM -0800, kmself@ix.netcom.com wrote:
> Response redirected to list.
> Follow-up set to list.

Yea, sorry. I would suggest that the list set Reply-To, but I'd just get flamed

> > It depends on how much you trust gnupg. Setting it SUID means that is
> > can lock pages sure. But it also means that it has to be really secure
> > - if you are running a single-user box then I shouldn't think you're
> > too bothered that someone could find an exploit - but by default it
> > should be secure.
> 
> First, this is somewhat nonresponsive to my question:  is there a
> specific reason why gpg was not SUID?  It's possible that postinstall
> configs didn't run on it, I've had a couple of apt problems in the past
> day or so.

I'm not involved in the package, but on my box it is SUID:
-rwsr-xr-x    1 root     root       563624 Oct 17 17:35 /usr/bin/gpg

I have gnupg 1.0.4-1

> Second, what do you want to trust:  a single SUID program, earmarked as
> a high-priority security issue, or every application running on the box
> with access to priviledged memory.

Applications with access to gnupg's memory are either running as root or
as the user owner of the gnupg process. You must trust root, and I don't think
that a bad process running as you would read gnupg's memory (strace the shell
and hook exec, for example). 

The issue is the swap; locked pages are never swapped out, so the disk never
seeks them. If someone could pick over your swap then they could pickout 
sectors with high-entropy and possibly they would be your privkey.

On a single-user box SUID gpg is a good thing - on a multi-user box you might
(rightly) be worried about another SUID binary.

AGL

-- 
If you think things can't get worse it's probably only because you lack sufficient imagination.

Attachment: pgpoGAm2ToMTQ.pgp
Description: PGP signature


Reply to: