S Roderick wrote:
I was hoping that either via kernel capabilities or SE
Linux that
we could avoid this. Both seem to offer exactly the feature we want, opening raw sockets from unprivileged accounts. But it's really unclear from all the doc's online how these two interact. Best we could do was try all the examples and approaches we could find - none worked.
I guess I can try trolling the kernel source ... ugh! ... to see if your recollection is correct. I certainly hope there is another option ...
Thanks S
I think Ross is right. At my last contract with IBM some years back, we were doing some raw socket stuff. ISTR that we had no problems because we were real root applications. IIRC, docs specified root privileges.
I completely agree with the fact that raw sockets require root privilege, that is the situation we're currently in and don't want to continue with. But am I then completely misunderstanding when I think that SE Linux can allow non-root access to certain "normally root only" capabilities, on a per process basis? Certainly all the ping- related SE Linux examples online all show precisely this: provide access to raw sockets for a non-root process.
ping is suid root, though.
Agreed, ping normally is. But what the SE Linux examples are showing is that you can remove the potential security hole of having ping be suid root, and use a custom SE Linux module to allow it simply access to raw sockets. Then, comprimising ping gets you only raw socket access and not full root access. At least, this is my understanding ...
I think maybe you misunderstood the examples. The examples show how you can MINIMIZE or POSSIBLY eliminate the risk of having utilities run setuid root by employing selinux to limit how much can be done by such a utility, but the utility still needs to be setuid because the restriction of needing a privileged account to create a raw socket is embedded directly in the kernel and there is no override for it.
So make your utility setuid root, then setup an selinux policy for it to limit it's access to memory and file systems so if the utility is compromised it is limited in what damage in can create.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.