Re: Question on running GnuPG 1.2.0 - PGP

This is a discussion on Re: Question on running GnuPG 1.2.0 - PGP ; John Santos writes in article dated Fri, 12 Sep 2003 19:03:10 -0400: >On Fri, 12 Sep 2003, Patrick Spinler wrote: > >> $ nopriv >> $ gpg >> gpg: can't lock memory: error -1 >> %NONAME-E-NOMSG, Message number 00000002 >> ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Question on running GnuPG 1.2.0

  1. Re: Question on running GnuPG 1.2.0

    John Santos writes in article <1030912185539.3498B-100000@Ives.egh.com> dated Fri, 12 Sep 2003 19:03:10 -0400:
    >On Fri, 12 Sep 2003, Patrick Spinler wrote:
    >
    >> $ nopriv
    >> $ gpg
    >> gpg: can't lock memory: error -1
    >> %NONAME-E-NOMSG, Message number 00000002
    >> $ set proc/priv= PSWAPM
    >> $ gpg
    >> gpg: Go ahead and type your message ...
    >>
    >> -- Pat

    >
    >I don't know why it needs PSWAPM, but it does.


    It must be locking pages into memory. The question is why. Normally this
    feature of VMS is for performance, but it doesn't affect the result. But in
    this case could it be for security? If you allocate a bunch of memory and
    don't initialize it, might you get somebody else's private key in your data?

    Second question -- does preventing the pages from being swapped out to disk
    actually make it secure, or is there another way memory contents might fall
    into the hands of another user? I'm guessing that GPG writes over the
    memory before releasing it (under normal termination conditions at least).

    Unless the page-locking is both necessary and reliable for preventing this
    kind of attack, the maintainers of the VMS version of GPG should change it
    so that it still works even if it can't lock the pages into physical memory.
    As is, a non-privileged VMS user can build it but not run it.

    >Other weirdnesses is it
    >only works on STREAM_LF files, so you need to convert text files to/from
    >STREAM_LF before/after using it. I imagine for binary files, you could
    >just lie about the attributes with "$ set file/attribute=RFM:STMLF" and
    >convert back to sequential fixed 512 after, but I haven't tried this.


    Typical of apps written for Unix. I have found that any kind of file can
    survive gzip/gunzip if you record the attributes somewhere and then execute
    the command you mention above before you compress the file, then after you
    decompress it, restore the attributes.

    >The first time you run it, it creates a subdirectory (under your
    >default login directory) to hold key rings, etc. and then complains
    >if the subdirectory has world or group read access.
    >
    > $ set file/prot=(w,g) sys$login:gnupg.dir
    >makes it shut up.
    >
    >--
    >John Santos
    >Evans Griffiths & Hart, Inc.
    >781-861-0670 ext 539


    --Keith Lewis klewis$mitre.org
    The above may not (yet) represent the opinions of my employer.

  2. Re: Question on running GnuPG 1.2.0

    Keith A. Lewis wrote:
    > John Santos writes in article <1030912185539.3498B-100000@Ives.egh.com> dated Fri, 12 Sep 2003 19:03:10 -0400:
    >
    >>On Fri, 12 Sep 2003, Patrick Spinler wrote:
    >>
    >>
    >>>$ nopriv
    >>>$ gpg
    >>>gpg: can't lock memory: error -1
    >>>%NONAME-E-NOMSG, Message number 00000002
    >>>$ set proc/priv= PSWAPM
    >>>$ gpg
    >>>gpg: Go ahead and type your message ...
    >>>
    >>>-- Pat

    >>
    >>I don't know why it needs PSWAPM, but it does.

    >
    >
    > It must be locking pages into memory. The question is why. Normally this
    > feature of VMS is for performance, but it doesn't affect the result. But in
    > this case could it be for security? If you allocate a bunch of memory and
    > don't initialize it, might you get somebody else's private key in your data?


    It's not for the initialization case so much as the chance that the key
    material will get swapped out to disk.

    > Second question -- does preventing the pages from being swapped out to disk
    > actually make it secure, or is there another way memory contents might fall
    > into the hands of another user? I'm guessing that GPG writes over the
    > memory before releasing it (under normal termination conditions at least).


    Yes, it does.

    > Unless the page-locking is both necessary and reliable for preventing this
    > kind of attack, the maintainers of the VMS version of GPG should change it
    > so that it still works even if it can't lock the pages into physical memory.
    > As is, a non-privileged VMS user can build it but not run it.


    I'm one of the GnuPG maintainers in general. I'm not sure what changes,
    if any, HP made to the GnuPG source for VMS, but with regards to the
    memory locking question, this error should not happen. If memory cannot
    be locked, GnuPG should continue working after issuing a warning to the
    user.

    It would be helpful to know the settings of USE_CAPABILITIES,
    HAVE_BROKEN_MLOCK, HAVE_MLOCK, and HAVE_PLOCK from config.h.

    >>The first time you run it, it creates a subdirectory (under your
    >>default login directory) to hold key rings, etc. and then complains
    >>if the subdirectory has world or group read access.
    >>
    >> $ set file/prot=(w,g) sys$login:gnupg.dir
    >>makes it shut up.


    Hmm. That is strange. GnuPG creates the directory with user-only
    permissions. What is the setting of MKDIR_TAKES_ONE_ARG in config.h ?

    For what it is worth, the latest version of GnuPG is 1.2.3. There have
    been a number of significant changes since 1.2.0.

    David


+ Reply to Thread