Mutt barfs on sendfd when verifying S/MIME (pledge)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Mutt barfs on sendfd when verifying S/MIME (pledge)

Andreas Kusalananda Kähäri
Hi,

Saw a few of the following on my console:

    sendmsg not allowed
    mutt(11070): syscall 28 "sendfd"

This occurs when trying to verify a signature
(application/pkcs7-sign, "smime.p7s").  The specific mail
message I'm looking at is the S/MIME signed message here:
http://mail-index.netbsd.org/pkgsrc-users/2016/01/25/msg022877.html

GPG signatures (PGP/MIME) seems to work ok.

With S/MIME though, mutt dumps core, and gdb tells me this:

$ gdb /usr/local/bin/mutt mutt.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd5.9"...
(no debugging symbols found)

Core was generated by `mutt'.
Program terminated with signal 6, Aborted.
(no debugging symbols found)
Loaded symbols for /usr/local/bin/mutt
Reading symbols from /usr/lib/libncurses.so.14.0...done.
Loaded symbols for /usr/lib/libncurses.so.14.0
Reading symbols from /usr/lib/libssl.so.38.0...done.
Loaded symbols for /usr/lib/libssl.so.38.0
Reading symbols from /usr/lib/libcrypto.so.37.0...done.
Loaded symbols for /usr/lib/libcrypto.so.37.0
Reading symbols from /usr/lib/libz.so.5.0...done.
Loaded symbols for /usr/lib/libz.so.5.0
Reading symbols from /usr/local/lib/libqdbm.so.14.14...done.
Loaded symbols for /usr/local/lib/libqdbm.so.14.14
Reading symbols from /usr/local/lib/libidn.so.17.2...done.
Loaded symbols for /usr/local/lib/libidn.so.17.2
Reading symbols from /usr/local/lib/libintl.so.6.0...done.
Loaded symbols for /usr/local/lib/libintl.so.6.0
Reading symbols from /usr/local/lib/libiconv.so.6.0...done.
Loaded symbols for /usr/local/lib/libiconv.so.6.0
Reading symbols from /usr/local/lib/libgpgme.so.19.0...done.
Loaded symbols for /usr/local/lib/libgpgme.so.19.0
Reading symbols from /usr/local/lib/libassuan.so.1.1...done.
Loaded symbols for /usr/local/lib/libassuan.so.1.1
Reading symbols from /usr/local/lib/libgpg-error.so.3.9...done.
Loaded symbols for /usr/local/lib/libgpg-error.so.3.9
Reading symbols from /usr/lib/libc.so.84.2...done.
Loaded symbols for /usr/lib/libc.so.84.2
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0  0x0000123b19b549aa in sendmsg () at <stdin>:2
2       <stdin>: No such file or directory.
        in <stdin>
(gdb) where
#0  0x0000123b19b549aa in sendmsg () at <stdin>:2
#1  0x0000123b137aad69 in _gpgme_ath_sendmsg ()
   from /usr/local/lib/libgpgme.so.19.0
#2  0x0000123b137a5cc2 in _gpgme_io_sendmsg () from /usr/local/lib/libgpgme.so.19.0
#3  0x0000123b0e466016 in uds_sendfd () from /usr/local/lib/libassuan.so.1.1
#4  0x0000123b1379dd3a in gpgsm_set_fd () from /usr/local/lib/libgpgme.so.19.0
#5  0x0000123b1379df9f in gpgsm_verify () from /usr/local/lib/libgpgme.so.19.0
#6  0x0000123b1378dc06 in gpgme_op_verify () from /usr/local/lib/libgpgme.so.19.0
#7  0x00001238c878f0f6 in ascii_strcasecmp () from /usr/local/bin/mutt
#8  0x00001238c87234e7 in mutt_signed_handler () from /usr/local/bin/mutt
#9  0x00001238c87457a5 in index_make_entry () from /usr/local/bin/mutt
#10 0x00001238c87459cc in index_make_entry () from /usr/local/bin/mutt
#11 0x00001238c872dd4e in crypt_pgp_application_pgp_handler ()
   from /usr/local/bin/mutt
#12 0x00001238c872e3b9 in crypt_pgp_application_pgp_handler ()
   from /usr/local/bin/mutt
#13 0x00001238c87282f1 in crypt_pgp_application_pgp_handler ()
   from /usr/local/bin/mutt
#14 0x00001238c8734273 in index_make_entry () from /usr/local/bin/mutt
#15 0x00001238c874dd21 in mutt_parse_hook () from /usr/local/bin/mutt
#16 0x00001238c8718841 in ?? () from /usr/local/bin/mutt
#17 0x0000000000000000 in ?? ()
Current language:  auto; currently asm

kdump:
[cut]
 18350 mutt     RET   sendmsg 1
 18350 mutt     CALL  recvmsg(5,0x7f7ffffdba50,0)
 18350 mutt     GIO   fd 5 read 3 bytes
       "OK
       "
 18350 mutt     STRU  struct msghdr { name=0x0, namelen=0, iov=0x7f7ffffdbaa0, iovlen=1, control=0x7f7ffffdba80, controllen=0, flags=0 }
 18350 mutt     STRU  struct iovec { base=0x41b9de70293, len=999 }
 18350 mutt     RET   recvmsg 3
 18350 mutt     CALL  kbind(0x7f7ffffdbc88,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  kbind(0x7f7ffffdbc88,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  kbind(0x7f7ffffdbce8,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  kbind(0x7f7ffffdbcc8,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  kbind(0x7f7ffffdbce8,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  kbind(0x7f7ffffdbd28,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  kbind(0x7f7ffffdbcd8,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  kbind(0x7f7ffffdbc88,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  pipe(0x7f7ffffdbd58)
 18350 mutt     RET   pipe 0
 18350 mutt     CALL  fcntl(7,F_SETFD,FD_CLOEXEC)
 18350 mutt     RET   fcntl 0
 18350 mutt     CALL  kbind(0x7f7ffffdbc88,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  kbind(0x7f7ffffdbc88,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  kbind(0x7f7ffffdbb88,0x18,0x9fbf6a958258cd0d)
 18350 mutt     RET   kbind 0
 18350 mutt     CALL  sendmsg(5,0x7f7ffffdbc70,0)
 18350 mutt     STRU  struct msghdr { name=0x0, namelen=0, iov=0x7f7ffffdbcc0, iovle
n=1, control=0x7f7ffffdbca0, controllen=24, flags=0 }
 18350 mutt     STRU  struct iovec { base=0x7f7ffffdbcd0, len=28 }
 18350 mutt     STRU  struct cmsghdr { len=20, level=SOL_SOCKET, type=SCM_RIGHTS, da
ta=6 }
 18350 mutt     PLDG  sendmsg, "sendfd", errno 1 Operation not permitted
 18350 mutt     PSIG  SIGABRT SIG_DFL
 18350 mutt     NAMI  "mutt.core"

On Sun, Jan 17, 2016 at 07:13:41AM -0700, Stuart Henderson wrote:

> CVSROOT: /cvs
> Module name: ports
> Changes by: [hidden email] 2016/01/17 07:13:41
>
> Modified files:
> mail/mutt      : Makefile
> Added files:
> mail/mutt/patches: patch-main_c patch-mutt_sasl_c
>                   patch-mutt_sasl_h
>
> Log message:
> Add an initial pledge to mutt, from tb@. Tested so far with slang/normal,
> gpgme/normal, sasl/normal, headercache on/off, and with imap/mbox/maildir.
>
> As you'd expect with a program like this that has many configuration
> options, including at runtime, the pledge is rather wide. But even so,
> a wide pledge still prevents many system calls, and restricts use of
> others.
>
> Committing early to make it easier for people to test. Please do so,
> especially if you have an unusual configuration. If you run into problems,
> please obtain a ktrace and report back to tb@ and myself with a description,
> the last page or so of kdump output, and preferably a backtrace. Thanks!
>
--
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF
------------------------------------------------------------------------

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mutt barfs on sendfd when verifying S/MIME (pledge)

Theo Buehler
On Wed, Jan 27, 2016 at 08:22:34AM +0100, Andreas Kusalananda Kähäri wrote:
> Hi,
>
> Saw a few of the following on my console:
>
>     sendmsg not allowed
>     mutt(11070): syscall 28 "sendfd"
>

Thank you.  Fittingly, gpgme also has a corresponding recvmsg...

We're slowly approaching pledge "everything" here :(

The following patch seems to do the trick, but it really looks like mutt
is barking "I don't want to be pledged!".

Index: Makefile
===================================================================
RCS file: /var/cvs/ports/mail/mutt/Makefile,v
retrieving revision 1.72
diff -u -p -r1.72 Makefile
--- Makefile 17 Jan 2016 14:13:41 -0000 1.72
+++ Makefile 27 Jan 2016 07:48:47 -0000
@@ -3,7 +3,7 @@
 COMMENT= tty-based e-mail client
 
 DISTNAME= mutt-1.5.24
-REVISION= 4
+REVISION= 5
 EPOCH= 0
 
 CATEGORIES= mail
Index: patches/patch-main_c
===================================================================
RCS file: /var/cvs/ports/mail/mutt/patches/patch-main_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-main_c
--- patches/patch-main_c 17 Jan 2016 14:13:41 -0000 1.1
+++ patches/patch-main_c 27 Jan 2016 07:50:26 -0000
@@ -1,7 +1,7 @@
-$OpenBSD: patch-main_c,v 1.1 2016/01/17 14:13:41 sthen Exp $
+$OpenBSD$
 --- main.c.orig Sun Aug 30 19:06:38 2015
-+++ main.c Sun Jan 17 07:54:28 2016
-@@ -734,6 +734,22 @@ int main (int argc, char **argv)
++++ main.c Wed Jan 27 08:44:36 2016
+@@ -734,6 +734,30 @@ int main (int argc, char **argv)
        }
    }
 
@@ -15,11 +15,19 @@ $OpenBSD: patch-main_c,v 1.1 2016/01/17
 +  }
 +#endif
 +
-+  if (pledge("stdio rpath wpath cpath flock fattr getpw tty inet dns "
++#ifdef CRYPT_BACKEND_GPGME
++  if (pledge("stdio rpath wpath cpath flock fattr getpw tty inet dns "
++    "proc exec sendfd recvfd", NULL) == -1) {
++    fprintf(stderr, "%s: pledge: %s\n", argv[0], strerror(errno));
++    exit(1);
++  }
++#else
++  if (pledge("stdio rpath wpath cpath flock fattr getpw tty inet dns "
 +    "proc exec", NULL) == -1) {
 +    fprintf(stderr, "%s: pledge: %s\n", argv[0], strerror(errno));
 +    exit(1);
 +  }
++#endif /* CRYPT_BACKEND_GPGME */
 +
    /* collapse remaining argv */
    while (optind < argc)

Reply | Threaded
Open this post in threaded view
|

Re: Mutt barfs on sendfd when verifying S/MIME (pledge)

Stuart Henderson-6
On 2016/01/27 08:58, Theo Buehler wrote:

> On Wed, Jan 27, 2016 at 08:22:34AM +0100, Andreas Kusalananda Kähäri wrote:
> > Hi,
> >
> > Saw a few of the following on my console:
> >
> >     sendmsg not allowed
> >     mutt(11070): syscall 28 "sendfd"
> >
>
> Thank you.  Fittingly, gpgme also has a corresponding recvmsg...

Ha. Interestingly I didn't run into any problems with gpgme support and pgp
messages yet.

OK.