bandwhich icon indicating copy to clipboard operation
bandwhich copied to clipboard

Separate network sniffer to different process to reduce sudo exposure

Open arkarkark opened this issue 5 years ago • 4 comments

Right now bandwhich is built from 153 packages (from the cargo install count). That's a really large attack surface for an app that's going to run under sudo. Could the app be split into two processes? one of which runs as the user and handles the display, the other (with a smaller number of dependencies) as root to access just the network traffic and pass it to the user process.

I'd really like to be able to run the process as me. Then that process tries to sudo the network grabbing process with the required password if sudo requires it.

arkarkark avatar Jan 05 '20 19:01 arkarkark

I'll point out that under linux (maybe there's also a way under mac?) one could only give the app the specific permissions it needs for the network and then not use sudo:

sudo setcap cap_net_raw,cap_net_admin=+ep "$HOME/.cargo/bin/bandwhich"

Even doing this though, you raise an interesting point. How do you think this would work, UX-wise? The tool would ask me for my root password? Personally I would feel less safe giving an app my actual password. Do you have a different idea?

As for the deps, we use the --locked flag in cargo when we build the release (in all forms of packaging as well as the releases here). But I of course understand and admit that while new things aren't likely to pop-up, I have not thoroughly audited all dependencies and transient dependencies before using them.

imsnif avatar Jan 05 '20 20:01 imsnif

indeed I wouldn't want to give an app my root password. Plus some systems use different ways to authenticate for sudo access (2 factor etc).

I think the easiest way to get this to work is to have the network binary have to be run with sudo. then it starts up the UI binary as the $SUDO_USER user.

a nicety would be if the network stuff fails and the command was run without sudo, then to restart the process with sudo but that's not really a division of privileges thing.

arkarkark avatar Jan 05 '20 20:01 arkarkark

Ah - I understand now. This sounds like a good change. Thanks!

We would have to find a way to transfer the utilization information between the processes (I'm guessing IPC, unless there are other better options I'm not aware of) - and be sure that doesn't hurt performance for a large volume of connections.

Would you be interested in working on this?

imsnif avatar Jan 05 '20 21:01 imsnif

I'm afraid I have zero rust experience and a security related change would very likely be a terrible first project.

arkarkark avatar Jan 05 '20 21:01 arkarkark