Annotation of embedaddon/mtr/SECURITY, revision 1.1.1.3

1.1       misho       1: SECURITY ISSUES RELATED TO MTR
                      2: 
1.1.1.3 ! misho       3: mtr invokes a sub-process, mtr-packet, which requires extra privileges
        !             4: to send custom packets, and there are security implications from
        !             5: granting this.
        !             6: 
        !             7: There are several different ways to provide the privileges:
        !             8: 
        !             9: 1. Add limited privileges on systems that support this. (Preferred.)
        !            10: 2. Run mtr as the root user.
        !            11: 3. Make mtr-packet a setuid-root binary.
        !            12: 
        !            13: Details:
        !            14: 
        !            15: 1. Add limited privileges on systems that support this.
        !            16: 
        !            17: Some operating systems allow binaries to be run with only the subset
        !            18: of security privileges that are actually needed.
        !            19: 
        !            20: Linux:
        !            21: On Linux, privileges are known as capabilities. The only additional
        !            22: capability that mtr-packet needs is cap_net_raw. To give this
        !            23: capability to the mtr-packet binary, run the following command as root:
        !            24: 
        !            25: # setcap cap_net_raw+ep mtr-packet
        !            26: 
        !            27: 
        !            28: 2. Run mtr as the root user.
        !            29: 
1.1       misho      30: You can limit mtr usage to the root user by not putting a setuid bit
1.1.1.3 ! misho      31: on the mtr-packet binary. In that case, the security implications are
        !            32: minimal.
1.1       misho      33: 
                     34: 
1.1.1.3 ! misho      35: 3. Make mtr-packet a setuid-root binary.
1.1       misho      36: 
1.1.1.3 ! misho      37: The mtr-packet binary can be made setuid-root, which is what "make install"
        !            38: does by default.
1.1       misho      39: 
1.1.1.3 ! misho      40: When mtr-packet is installed as suid-root, some concern over security is
        !            41: justified.  mtr-packet does the following two things after it is launched:
1.1       misho      42: 
1.1.1.3 ! misho      43: *  mtr-packet open sockets for sending raw packets and for receiving
        !            44:    ICMP packets.
        !            45: *  mtr-packet drops root privileges by setting the effective uid to
        !            46:    match uid or the user calling mtr.
        !            47: *  If capabilities support is available, mtr-packet drops all privileged
        !            48:    capabilities.
1.1       misho      49: 
1.1.1.3 ! misho      50: See main() in packet.c and init_net_state_privileged() in probe_unix.c
        !            51: for the details of this process.
        !            52: 
        !            53: This should limit the possibilities of using mtr to breach system security.
        !            54: The worst case scenario is as follows:
        !            55: 
        !            56: Due to some oversight in the mtr-packet code, a malicious user is able to
        !            57: overrun one of mtr-packets's internal buffers with binary code that is
1.1       misho      58: eventually executed.  The malicious user is still not able to read
1.1.1.3 ! misho      59: from or write to any system files other than those normally accessible
        !            60: by the user running mtr.  The only privileges gained are access to the raw
        !            61: socket, which would allow the malicious user to listen to all ICMP packets
        !            62: arriving at the system, and to send forged packets with arbitrary contents.
        !            63: 
1.1       misho      64: 
                     65: If you have further questions or comments about security issues,
1.1.1.3 ! misho      66: please see the README file for details on how to submit them.

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>