Requesting classic confinement for bettercap snap

store
1

Hi all! bettercap is the swiss army knife for 802.11, BLE and ethernet networks reconnaissance and MITM attacks. It is relying on libcap, libnetfilter-queue and libusb for many of its attacks, therefore a strict confinement basically makes the user experience very bad and the snap almost unusable.

GitHub repo: https://github.com/bettercap/bettercap
Website: https://www.bettercap.org/

2

Can you describe specifically what is blocked? I would think bluetooth-control, network, network-control and raw-usb to give you what you need, based on your request.

3

Unfortunately I’m not very familiar with Snap so it’s very hard for me, each time I add a new feature, determining which “channel” that feature is connected to. That’s the main problem.

4

I’ve worked with @evilsocket separately on the snap.

Bettercap needs a whole bunch of interfaces that are not autoconnected.

  • bettercap:bluetooth-control
  • bettercap:firewall-control
  • bettercap:netlink-audit
  • bettercap:netlink-connector
  • bettercap:network-control
  • bettercap:network-observe

We can test:

  • How things work in devmode.
  • How things work with the above connected (manually first, we can work on assertions later).
  • We can try to debug any additional errors via snappy debug.

@evilsocket, let’s try these venues:

Step 1: Change confinement from strict to devmode, run snap, check errors in the messages/syslog.
Step 2: Keep confinement strict, install snappy debug, check errors in a separate console.

snap install snappy-debug
snappy-debug.security scanlog

Step 3: Keep confinement strict and manually connect the not-auto-connected interfaces listed above.

snap connect bettercap:xyz (network-control, network-audit, etc).

Check if the snaps works correctly.

If we still have problems, we can then request classic.

5

@Igor this adds way too much complexity for bettercap’s quick developement and release cycles, especially because there’s no easy and quick way to map a “permission denied” error to whatever props I need to add or channel I need to connect to, meaning that whenever I’ll have such problem (and considering the type of tool, I’ll have such problem quite often), I’ll have to either spend a considerable amount of time debugging this system, or just asking here until I’ve figured it out …

6

Hey @jdstrand and @Igor, may I have a yes or no about my request for classic confinement so I can decide if using snapcraft as bettercap’s main distribution channel or not?

Thanks a ton, I appreciate your time and assistance.

7

As a first pass, we could give this classic, and then debug in parallel, but I still think having the interfaces auto-connected is a better idea long term, and would also give the necessary functionality.

@jdstrand, what do you think?

8

Ok, I’ve been blocking the release until now in order to wait for someone to give me a final answer, I’m done waiting. I’m removing Snap from our documentation as an available distribution option.

9

I’m not the one that decides on classic or not, but I am one of the gatekeepers in terms of understanding the requirements of why something needs classic. I appreciate that this process has taken some time, but it still isn’t clear why this snap needs classic… I would suspect that this could be made strict, but without the requested information we can neither address snapd to allow this to work in strict mode nor assess why it needs classic.

@evilsocket - I appreciate your timelines for the new release. If/when you are ready to dive a bit deeper, we can take another look. Thanks

10

no specific requirements other than this, strict simply makes snap unusable in our pipeline … no worries, github release system is more than enough, bettercap is no more distributed via snapcraft.

:wave: