|Main Archive Page > Month Archives > linux-kernel archives|
Quoting firstname.lastname@example.org (email@example.com):
> I'm not sure it is you the right person to contact.
> I tried to run latest normal user wireshark with SUID dumpcap without success
> under linux-220.127.116.11. After looking around it seems to be related to the file
> in the kernel security/commoncap.c
> Inside function cap_task_kill (sorry I did not create a diff) I'm wondering if
> the check is correct:
> * Running a setuid root program raises your capabilities.
> * Killing your own setuid root processes was previously
> * allowed.
> * We must preserve legacy signal behavior in this case.
> if (p->euid == 0 && p->uid == current->uid)
> return 0;
> Should this check not be:
> if (p->suid == 0 && p->uid == current->uid)
> return 0;
> At least if I change this statement, wireshark runs correctly with as normal
> For explanation: during capture, wireshark spins a new suid process called
> dumpcap. To stop capture, wireshark sends SIGUSR1 to dumpcap. Hower, without
> changing the line, kill fails with EPERM.
> Thanks for your consideration.
> Kind Regards,
thanks for the report. Interesting. I just downloaded the wireshark source and as I suspected it's using capabilities. The problem then is that the helper starts as setuid root, sets just the capabilities it needs, then changes back to it's original userid. It's actually what we'd like people to be doing. But they then rely upon the traditional setuid behavior of the unprivileged process being able to kill the privileged one. This is why checking suid instead of euid at cap_task_kill() works for you.
Two quick fixes for you right now (apart from the one you've already got :) would be
capset cap_kill=ep /bin/wireshark
2. compile a kernel with SECURITY_FILE_CAPABILITIES=n
Andrew, this pretty much was bound to happen... we need to figure out what our approach here should be. My preference is still to allow signals when p->uid==current->uid so long as !SECURE_NOROOT. Then as people start using secure_noroot process trees they at least must know what they're asking for.
An alternative stance is to accept these things as they come up and try to quickly work with the authors of such programs to work around it. I suppose in a security sense that's the superior way :) But it also seems likely to lead to most people choosing option 2 above and not bothering to fix the problem.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html