By using AWS re:Post, you agree to the Terms of Use
/Lambda Layer user permissions/

Lambda Layer user permissions

0

Hi there, I'm trying to write a lambda layer in Go using the google/gopacket package for capturing network traffic packets. This uses the libpcap C library underneath, and I used https://github.com/lambci/yumda to produce a separate lambda layer that provides the libpcap.so shared library

In my layer, I've added the code as outlined here: https://pkg.go.dev/github.com/google/gopacket@v1.1.19/pcap#hdr-Reading_Live_Packets

However I am receiving the following error:

panic: vinternal_1: You don't have permission to capture on that device (socket: Operation not permitted)

I've also tried passing different network IDs, e.g. "eth0", however I am still receiving the same error

I am wondering if I do not have access to the right permissions/capabilities when using the .zip method. I had previously tested the custom lambda container image approach, and it worked, but I would prefer to use the zip file approach to avoid heavy deployment processes.

Any ideas how I can get the right permissions in a zip-file lambda layer, to allow libpcap to capture packets on the lambda-managed network interface? Thanks :)

1 Answers
1
Accepted Answer

There are a bunch of operating system permissions not given to Lambda functions. For example, sending an ICMP packet is one network function that you can't access (or at least you couldn't the last time I tried). I would suspect that capturing packets is also one of those things because it requires your process to be able to access packets at the kernel level and see traffic for other process.

There's a very strict process separation mechanism in Lambda. This has nothing to do with whatever packaging method is being used.

Why are you trying to capture packets in Lambda?

EXPERT
answered a month ago
  • Hi brettski, thanks for your reply!

    I am capturing packets for troubleshooting. Most often, this will occur at the application layer protocols (HTTP, FTP, etc) but sometimes requires troubleshooting TLS handshakes. I also prefer capturing traffic at the lower level for non-intrusive logging that doesn't require in-band protocol parsing/negotiation. For this reason, I am trying to move away from the current proxy-based solution, which also turns out to be better for performance

    I have tried a couple of other solutions for capturing packets outside the Lambda, notably: 1. AWS VPC Traffic Mirroring; and 2. Running tcpdump on a NAT instance I was able to collect packets in both scenarios, however I then found correlating packets back to their original Lambda invocations (on request ID) was fairly inexact, bordering impossible.

    I've started reading up on Firecracker, but I fear your response is correct in that there is no possible way to capture outbound traffic during function execution at the lower layers of the virtualized network interface. I don't 100% understand why - since it's my user space application generating the traffic, I should technically be able to read it?

    Can you suggest any other approaches? Thanks!

  • If I understand the way packet capture works in Linux; it's all done at kernel level (not userspace) even when you're only trying to capture your own traffic. Caveat: I haven't looked at this too deeply recently; historical knowledge only. And Firecracker was specifically designed to vastly reduce the number of kernel entry points to reduce attack footprint of malicious code. So if the Lambda designers don't think it's necessary it isn't there or it's not available from a security perspective.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions