Bug 236819 - [tcpdump] capsicum-related changes broke reading IPsec ESP decryption keys from a file
Summary: [tcpdump] capsicum-related changes broke reading IPsec ESP decryption keys fr...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.2-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-net mailing list
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2019-03-27 03:31 UTC by Eugene Grosbein
Modified: 2019-04-16 23:27 UTC (History)
2 users (show)

See Also:
koobs: mfc-stable11?
koobs: mfc-stable12?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Grosbein freebsd_committer 2019-03-27 03:31:45 UTC
tcpdump(8) manual page documents command line option -E that may involve reading keys from a file:

              In addition to the above syntax, the syntax ``file name'' may be
              used to have tcpdump read the provided file in. The file is
              opened upon receiving the first ESP packet, so any special
              permissions that tcpdump may have been given should already have
              been given up.

This is currently broken in stable/11:

# tcpdump -E 'file /tmp/keys.txt' -s0 -np -i em0 host 1.1.1.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump: print_esp: can't open /tmp/keys.txt: Not permitted in capability mode
Comment 1 Ed Maste freebsd_committer 2019-04-01 13:33:07 UTC
Does it work in stable/12?
Comment 2 Eugene Grosbein freebsd_committer 2019-04-02 02:23:03 UTC
(In reply to Ed Maste from comment #1)

I do not have any stable/12 system to verify. But it should be easy to run mentioned "tcpdump ..." command there as it does not need any real IPSEC configuration or traffic other than simple outgoing ESP packet generated with something like "traceroute -nP ESP 1.1.1.1". This triggers the bug for 11.2-RELEASE without any IPSEC configuration and Should trigger for stable/12, too.
Comment 3 Ed Maste freebsd_committer 2019-04-02 15:39:03 UTC
(In reply to Eugene Grosbein from comment #2)

Reproduced here:

% tcpdump --version
tcpdump version 4.9.2
libpcap version 1.9.0
OpenSSL 1.0.2o-freebsd  27 Mar 2018

# ktrace -i tcpdump -E 'file foo' -s0 -np -i wlan0 host 1.1.1.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump: print_esp: can't open foo: Not permitted in capability mode
Comment 4 Ed Maste freebsd_committer 2019-04-02 15:51:46 UTC
(In reply to Ed Maste from comment #3)
From the man page:

> The file is opened upon receiving the first ESP packet, so
> any special permissions that tcpdump may have been given
> should already have been given up.

Most expedient way to restore -E 'file foo' functionality is to add to the cansandbox test in tcpdump.c and avoid sandboxing when -E file is used. Proper fix will require a bit more consideration.
Comment 5 commit-hook freebsd_committer 2019-04-16 04:13:09 UTC
A commit references this bug:

Author: oshogbo
Date: Tue Apr 16 04:12:42 UTC 2019
New revision: 346263
URL: https://svnweb.freebsd.org/changeset/base/346263

Log:
  tcpdump: disable Capsicum if -E option is provided.

  The -E is used to provide a secret for decrypting IPsec.
  The secret may be provided through command line or as the file.
  The problem is that tcpdump doesn't support yet opening files in capability mode
  and the file may contain a list of the files to open.

  As a workaround, for now, let's just disable capsicum if the -E
  the option is provided.

  PR:		236819
  MFC after:	2 weeks

Changes:
  head/contrib/tcpdump/tcpdump.c