[CentOS] Unable open raw socket in CentOS 5 - SE Linuxandkernelcapability interaction?

Ross S. W. Walker rwalker at medallion.com
Sun Mar 9 18:09:48 UTC 2008


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3971 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20080309/8105f316/attachment.bin>


More information about the CentOS mailing list