raw socket access as normal user on linux 2.4

Question

In an embedded system (2.4 kernel) I need raw socket access to the eth0 interface from a process not running as root.

I tried to address this problem by setting the CAP_NET_RAW capability from the command line and programmatically using cap_set_proc(), both with no success. It seems that I do not have the permission to do so, in the program I get an EPERM error, on the command line

Failed to set cap's on process `1586': (Operation not permitted)

Is there an easier way to do what I want? If not, what steps are necessary to successfully set the CAP_NET_RAW capability?

EDIT: I have root access, but running the process permanently as root is no option. The version of libcap is 1.10, there is no 'setcap' binary, but a 'setpcaps'.

EDIT - answering George Skoptsov:

If I get you right, your suggestion is to start a process with setuid, then set the CAP_NET_RAW capability and then drop the privileges. I tried this with the following code, but it does not seem to work, even though the caps command do not return errors. With the seteuid() commented out, raw access works, but only since the process is running as root then:

cap_t caps = cap_get_proc();
cap_value_t cap_list[1];
cap_list[0] = CAP_NET_RAW;
if (cap_set_flag(caps, CAP_EFFECTIVE, 1, cap_list, CAP_SET) == -1)
{
    printf("cap_set_flag error");
}
if (cap_set_proc(caps) == -1)
{
    printf("cap_set_proc error");
}

if (seteuid(getuid()) != 0) 
{
    printf("seteuid error");
}

function_that_needs_raw_access();

Thanks for your help. Chris

Wanitawanneeickel

If you follow my suggestion below, your process will not be run as root, but will have root privileges at start-up, which would allow it to set the capabilities you want. – Disturbing

Thanks for your suggestions George, however, I had no success... see my edits. – Wanitawanneeickel

Chris, maybe you can be very careful with escalating privileges when needed explicitly in the function_that_needs_raw_access()? – Disturbing

Answer 1

Generally, you need root permissions to receive raw packets on an interface. This restriction is a security precaution, because a process that receives raw packets gains access to communications of all other processes and users using that interface.

However, if you have access to root on the machine, you can use the setuid flag to give your process root privileges even when the process is executed as a non-root user.

First, ensure that this capability is set successfully when the process is run as root. Then use

sudo chown root process
sudo chmod ugo+s process 

to set root as owner of the process and set the setuid flag. Then check that the capability is set when the process is run by other users. Because this process will now have all superuser privileges, you should observe security precautions, and drop the privileges as soon as your code no longer requires it (after enabling the CAP_NET_RAW).

You can follow this method to ensure you're dropping them properly.

Disturbing

I don't know how to enable the CAP_NET_RAW. There is not setcap command. When running the process with setuid flag everything works, but I don't want to run the process as root... – Wanitawanneeickel

You are not running the process as root. You can drop these privileges as soon as you're done setting the capabilities, which is working for you under root. – Disturbing

My original problem is not really solved, but I accept this answer since George tried to help me and this is the "closest" solution. – Wanitawanneeickel

@Wanitawanneeickel this one is real solution to permission problem... just follow basic rules: 1. chmod a+s procfile, 2. ./procfile as normal user, 3. in procfile do setuid(0) to become root, 4. do whatever requires privileges (careful, best to not accept user input here), 5. do setuid( NORMAL_USER ) again to drop root privileges, 6. continue program normally. (remember that setuid() probably does not work from scripts and that my code is just pseudocode to show simple steps to do it right) – Crenation

Answer 2

You can give an executable program the ability to use the CAP_NET_RAW privilege without giving it other root privileges.

$ setcap cap_net_raw=pe *program*

You cannot give this privilege without having this privilege. Certainly root can give this privilege to programs.

Thruster

There are no File Capabilities under linux 2.6.24. That's what the question is about. – Loathly

Answer 3

The process must be run as root, or have the CAP_NET_RAW capabilities on the executable.

In order to set CAP_NET_RAW, you need to run the setcap command as root. Once set, you can run the executable as another user, and it'll have access to raw packet capturing.

If you do not have root access in anyway, nor can get anyone with root access to set CAP_NET_RAW or setuid root on the executable, you'll not be able to do packet capturing as a non-root user.

Wei

There is no setcap command, only setpcaps. I have tried to run setpcaps as root to set the caps for the running process, but that won't work (see error message in original post). – Wanitawanneeickel

Answer 4

TL;DR IMHO not supported in kernel < 3.0.

There was a discussion about supporting it in kernel netdev mailing list: https://lwn.net/Articles/420800/ and https://lwn.net/Articles/420801/.

And included it in commit c319b4d76b9e583a5d88d6bf190e079c4e43213d, released in kernel 3.0:

commit c319b4d76b9e583a5d88d6bf190e079c4e43213d
Author: Vasiliy Kulikov <[email protected]>
Date:   Fri May 13 10:01:00 2011 +0000

    net: ipv4: add IPPROTO_ICMP socket kind

Follows: v2.6.39-rc2
Precedes: v3.0-rc1

Running ping without CAP_NET_RAW (i.e. without setting capabilities or without set-uid) was implemented for ping in revision 87dbb3a5db657d5eae6934707beaf0507980a1c3, released in iputils s20150815:

commit 87dbb3a5db657d5eae6934707beaf0507980a1c3
Author: Nikos Mavrogiannopoulos <[email protected]>
Date:   Fri May 29 11:01:00 2015 +0200

    This patch allows running ping and ping6 without root privileges on
    kernels that support it. Almost identical to Lorenzo
    Colitti's original patch except:
    ...

Follows: s20140519
Precedes: s20150815

Insolvency