on Thu, Nov 30, 2000 at 04:36:18PM -0500, Chris Gray ([EMAIL PROTECTED]) wrote: > >>>>> "kmself" == kmself <kmself@ix.netcom.com> writes: > > kmself> I'd also confirmed this on another box. Though I can > kmself> never remember what the [EMAIL PROTECTED]&*() mode bit is for > SUID. > kmself> '4577' was what I was looking for, IIRC. > > 4755. Though you should probably use suidregister (see > /var/lib/dpkg/info/gnupg.postinst for how to do it). > > >> 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. > > kmself> So: the locked pages are still accessible to other root > kmself> processes, but not to user-land programs, and they're not > kmself> swapped to disk? > > The other root programs shouldn't be looking at memory other than > their own, or else they'd segfault. The major thing with > memory-locking is that the memory never gets written to disk.
What about /proc/kcore or /dev/mem? -- Karsten M. Self <kmself@ix.netcom.com> http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
pgpEZyOwu53Dl.pgp
Description: PGP signature
