Please do not recommended sudo install

[schwehr]

It is typically considered bad for users to install python modules on top of their system python modules without proper package management (e.g. without using things like apt, rpm, etc.). It would be better to recommend virtualenv installs and/or the system method for installing. e.g.

http://www.secdev.org/projects/scapy/doc/installation.html says:

$ cd /tmp
$ wget scapy.net
$ unzip scapy-latest.zip
$ cd scapy-2.*
$ sudo python setup.py install

[insomniacslk]

Alternatively the docs can suggest to use python setup.py install --user (and --user --prefix= for mac users)

[p-l-]

Normally, packages installed with sudo python setup.py install should go to /usr/local/lib/python while those installed with distribution packages should go to /usr/lib/python, or did I miss something?

[schwehr]

Yes. Those of us who do package management often suffer from what ends up in /usr/local. Too many packages go looking in /usr/local and so those of us packaging stuff are continually trying to block managed packages from grabbing things that are not controlled. Rather than tell a use to use sudo, virtualenv is a great way to contain things to a truly local install. Baring that, have the use make an in their home dir location. I've spent too much of my time undoing strange collisions over the years. If an experienced person wants to sudo python setup.py install, then they will already know how to do that and so be it, but please please please don't tell everyone to do that. I just had to help someone undo some things on a mac last week just because of that. Note that the system python on macosx will not use /usr/local. It ends up in /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/, which is fine for Apple managing things, but you are sending users into that land and who knows what will happen on a system update. How do you cleanly uninstall on all the major Oses out there if the user did a sudo install?

[p-l-]

I do agree that virtualenv is a great option, but on the other hand, people might want to really install Scapy on their system, and not in a virtualenv.

Since Scapy is often run as root, I think it is a bad idea to have it installed in a regular user's home directory, since that would provide a privilege escalation path.

[schwehr]

If a user installing it in their tree with virtualenv and using sudo is really a bigger security risk than uncontrolled installs laying over the system tree and running sudo against that, then perhaps you should be providing instructions for chroot, sandboxing, or other container that has limited access beyond the external network interfaces?

[p-l-]

You do understand that a user installing software in his home and running it (often) as root makes this software a good target for an attacker to get root once the user account has been compromised, don't you?

I for one would really welcome detailed and sensible installation instructions, for one or better several OSes, on how to install and run Scapy with minimum privileges.

[optimistck]

@schwehr I'm happy to document the proper way to install scapy for the benefit of the community if you an help me / guide me through the process so that (a) I can get it working correctly on my end and (b) capture notes to produce some sort of a guide. Let me know.

[guedou]

@optimistck Cool ! Which OS are you targeting ? I can share some info concerning OS X (using macports or homebrew).

[optimistck]

@guedou El Captain 10.11.3. There are many options to consider (including homebrew, virtual environments, PyCharm installer, El Captain built-in Python vs. self-install, etc.) and none got me to the finish line just yet. My inspiration was hacking the Dash Button, but to get that snippet of code to run turned into an adventure.

[guedou]

On OS X, so far, you need to install pcap & dnet Python modules. On macports, they are called py-pylibpcap & py-dnet. Homebrew is more tricky as pylibpcap is not available. dnet can be installed as follows:
brew install --with-python libdnet.
The following file can be used to easily install pylibpcap: https://raw.githubusercontent.com/guedou/ci_python_multi-os/master/pylibpcap.rb

However, the best solution is to give a try to https://github.com/guedou/scapy-bpf This fork natively supports OS X (and other *BSD flavors), and does not require any external Python modules. It will be merged soon to the main repository as soon some small issues are fixed, see #104

[optimistck]

As admirable as my goal was it looks like someone beat me to this: Installing Scapy for Mac OS X a link I found on NetworkWorld. This helped my next hurdle: sudo chmod go+r /dev/bpf*

[guedou]

@optimistck you should definitely give a try to https://github.com/guedou/scapy-bpf as there is nothing to install to be able to send and receive packets. You only need to clone the repository and launch ./run_scapy (or import Scapy as a module).

[schwehr]

I'd recommend having virtualenv as your first install method. For Mac OSX installs, I'm a fink developer, so I think it's always awesome when projects include instructions on how to use homebrew, macports, fink, or other packaging systems, but it's not critical.

And things like sudo chmod go+r /dev/bpf are really bad ideas if you care about security. I think it would be reasonable to start with instructions for the security conscious... e.g. install via a virtualenv and sudo to run the commands. Then put up a large warning about dragons ahead and then describe things like changing read permissions on /dev drivers and such.

Maybe useful... haven't really read it https://realpython.com/blog/python/python-virtual-environments-a-primer/

[p-l-]

I do not want to recommend virtualenv as an installation method.

To install a stable version, I think the best option is to recommend either pip or the distribution's packages, when they exist and are not outdated.

To install the development version from the Git repository, we could recommend either setup.py install or unstable packages when they exist (the AUR package scapy-git for ArchLinux is the only one I know of).

I totally agree there should be warnings explaining clearly the security consequences of every "dangerous" instruction.