I am wondering what is the interaction between SE Linux and the kernel "capabilities" in CentOS 5.1? I'm trying to open a raw socket and keep getting permission denied errors. I've tried using the lcap library to find that CAP_SETPCAP appears to be off in the kernel. For compliance reasons, I don't want to turn this on. I've also tried a hand-crafted SE Linux module policy. I have verified that the test program runs in the correct SE Linux domain and it generates no audit errors, but it still fails to open the port with permission denied.
It appears that SE Linux is not preventing the socket being created (as evidenced by the lack of audit messages), so what am I missing? Do I still need to modify capabilities within the program, even if I'm using an SE Linux policy?
Thanks S
Source file
#include <stdio.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <sys/prctl.h> #include <netinet/in.h>
int main(void) { int fd = socket(PF_INET, SOCK_RAW, IPPROTO_TCP); if (-1 == fd) { printf("Failed to open raw socket: %d=%s\n", errno, strerror(errno)); } else { printf("Socket opened successfully\n"); close(fd); } return 0; }
SElinux .te file
policy_module(rawsox,1.0.0)
######################################## # Declarations
type rawsox_t; type rawsox_exec_t; domain_type(rawsox_t) domain_entry_file(rawsox_t, rawsox_exec_t) domain_auto_trans(unconfined_t,rawsox_exec_t,rawsox_t)
######################################## # Rawsox local policy
# these two didn't help #corenet_raw_sendrecv_all_if( rawsox_t ); #corenet_raw_sendrecv_all_nodes( rawsox_t );
require { type lib_t; type ld_so_t; type ld_so_cache_t; type usr_t; type devpts_t; type rawsox_t; type etc_t; class lnk_file read; class dir search; class file { read getattr execute }; class chr_file { read write getattr }; class rawip_socket create; class capability net_raw; }
#============= rawsox_t ============== allow rawsox_t devpts_t:chr_file { read write getattr }; allow rawsox_t etc_t:dir search; allow rawsox_t ld_so_cache_t:file { read getattr }; allow rawsox_t ld_so_t:file read; allow rawsox_t lib_t:dir search; allow rawsox_t lib_t:file { read getattr execute }; allow rawsox_t lib_t:lnk_file read; allow rawsox_t usr_t:dir search;
allow rawsox_t self:capability { net_raw setuid }; allow rawsox_t self:rawip_socket { create ioctl read write bind getopt setopt }; allow rawsox_t self:unix_stream_socket { create_socket_perms };
Does anyone have any idea on this one? Based on everything we've tried with kernel capabilities and SE Linux parameters, we're missing something. Have tried everything we can find online.
Thanks Stephen
On Mar 3, 2008, at 09:14 , S Roderick wrote:
I am wondering what is the interaction between SE Linux and the kernel "capabilities" in CentOS 5.1? I'm trying to open a raw socket and keep getting permission denied errors. I've tried using the lcap library to find that CAP_SETPCAP appears to be off in the kernel. For compliance reasons, I don't want to turn this on. I've also tried a hand-crafted SE Linux module policy. I have verified that the test program runs in the correct SE Linux domain and it generates no audit errors, but it still fails to open the port with permission denied.
It appears that SE Linux is not preventing the socket being created (as evidenced by the lack of audit messages), so what am I missing? Do I still need to modify capabilities within the program, even if I'm using an SE Linux policy?
Thanks S
Source file
#include <stdio.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <sys/prctl.h> #include <netinet/in.h>
int main(void) { int fd = socket(PF_INET, SOCK_RAW, IPPROTO_TCP); if (-1 == fd) { printf("Failed to open raw socket: %d=%s\n", errno, strerror(errno)); } else { printf("Socket opened successfully\n"); close(fd); } return 0; }
SElinux .te file
policy_module(rawsox,1.0.0)
######################################## # Declarations
type rawsox_t; type rawsox_exec_t; domain_type(rawsox_t) domain_entry_file(rawsox_t, rawsox_exec_t) domain_auto_trans(unconfined_t,rawsox_exec_t,rawsox_t)
######################################## # Rawsox local policy
# these two didn't help #corenet_raw_sendrecv_all_if( rawsox_t ); #corenet_raw_sendrecv_all_nodes( rawsox_t );
require { type lib_t; type ld_so_t; type ld_so_cache_t; type usr_t; type devpts_t; type rawsox_t; type etc_t; class lnk_file read; class dir search; class file { read getattr execute }; class chr_file { read write getattr }; class rawip_socket create; class capability net_raw; }
#============= rawsox_t ============== allow rawsox_t devpts_t:chr_file { read write getattr }; allow rawsox_t etc_t:dir search; allow rawsox_t ld_so_cache_t:file { read getattr }; allow rawsox_t ld_so_t:file read; allow rawsox_t lib_t:dir search; allow rawsox_t lib_t:file { read getattr execute }; allow rawsox_t lib_t:lnk_file read; allow rawsox_t usr_t:dir search;
allow rawsox_t self:capability { net_raw setuid }; allow rawsox_t self:rawip_socket { create ioctl read write bind getopt setopt }; allow rawsox_t self:unix_stream_socket { create_socket_perms };
Does it run as 'root'?
-Ross
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of S Roderick Sent: Friday, March 07, 2008 3:28 PM To: CentOS mailing list Subject: Re: [CentOS] Unable open raw socket in CentOS 5 - SE Linux and kernelcapability interaction?
Does anyone have any idea on this one? Based on everything we've tried with kernel capabilities and SE Linux parameters, we're missing something. Have tried everything we can find online.
Thanks Stephen
On Mar 3, 2008, at 09:14 , S Roderick wrote:
I am wondering what is the interaction between SE Linux and the kernel "capabilities" in CentOS 5.1? I'm trying to open a
raw socket
and keep getting permission denied errors. I've tried using
the lcap
library to find that CAP_SETPCAP appears to be off in the kernel. For compliance reasons, I don't want to turn this on. I've also tried a hand-crafted SE Linux module policy. I have verified that the test program runs in the correct SE Linux domain and it generates no audit errors, but it still fails to open the
port with
permission denied.
It appears that SE Linux is not preventing the socket being
created
(as evidenced by the lack of audit messages), so what am I
missing?
Do I still need to modify capabilities within the program, even if I'm using an SE Linux policy?
Thanks S
Source file
#include <stdio.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <sys/prctl.h> #include <netinet/in.h>
int main(void) { int fd = socket(PF_INET, SOCK_RAW, IPPROTO_TCP); if (-1 == fd) { printf("Failed to open raw socket: %d=%s\n", errno, strerror(errno)); } else { printf("Socket opened successfully\n"); close(fd); } return 0; }
SElinux .te file
policy_module(rawsox,1.0.0)
######################################## # Declarations
type rawsox_t; type rawsox_exec_t; domain_type(rawsox_t) domain_entry_file(rawsox_t, rawsox_exec_t) domain_auto_trans(unconfined_t,rawsox_exec_t,rawsox_t)
######################################## # Rawsox local policy
# these two didn't help #corenet_raw_sendrecv_all_if( rawsox_t ); #corenet_raw_sendrecv_all_nodes( rawsox_t );
require { type lib_t; type ld_so_t; type ld_so_cache_t; type usr_t; type devpts_t; type rawsox_t; type etc_t; class lnk_file read; class dir search; class file { read getattr execute }; class chr_file { read write getattr }; class rawip_socket create; class capability net_raw; }
#============= rawsox_t ============== allow rawsox_t devpts_t:chr_file { read write getattr }; allow rawsox_t etc_t:dir search; allow rawsox_t ld_so_cache_t:file { read getattr }; allow rawsox_t ld_so_t:file read; allow rawsox_t lib_t:dir search; allow rawsox_t lib_t:file { read getattr execute }; allow rawsox_t lib_t:lnk_file read; allow rawsox_t usr_t:dir search;
allow rawsox_t self:capability { net_raw setuid }; allow rawsox_t self:rawip_socket { create ioctl read write bind getopt setopt }; allow rawsox_t self:unix_stream_socket { create_socket_perms };
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
______________________________________________________________________ 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.
It runs fine under root and with sudo. S
On Mar 7, 2008, at 15:33 , Ross S. W. Walker wrote:
Does it run as 'root'?
-Ross
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of S Roderick Sent: Friday, March 07, 2008 3:28 PM To: CentOS mailing list Subject: Re: [CentOS] Unable open raw socket in CentOS 5 - SE Linux and kernelcapability interaction?
Does anyone have any idea on this one? Based on everything we've tried with kernel capabilities and SE Linux parameters, we're missing something. Have tried everything we can find online.
Thanks Stephen
On Mar 3, 2008, at 09:14 , S Roderick wrote:
I am wondering what is the interaction between SE Linux and the kernel "capabilities" in CentOS 5.1? I'm trying to open a
raw socket
and keep getting permission denied errors. I've tried using
the lcap
library to find that CAP_SETPCAP appears to be off in the kernel. For compliance reasons, I don't want to turn this on. I've also tried a hand-crafted SE Linux module policy. I have verified that the test program runs in the correct SE Linux domain and it generates no audit errors, but it still fails to open the
port with
permission denied.
It appears that SE Linux is not preventing the socket being
created
(as evidenced by the lack of audit messages), so what am I
missing?
Do I still need to modify capabilities within the program, even if I'm using an SE Linux policy?
Thanks S
Source file
#include <stdio.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <sys/prctl.h> #include <netinet/in.h>
int main(void) { int fd = socket(PF_INET, SOCK_RAW, IPPROTO_TCP); if (-1 == fd) { printf("Failed to open raw socket: %d=%s\n", errno, strerror(errno)); } else { printf("Socket opened successfully\n"); close(fd); } return 0; }
SElinux .te file
policy_module(rawsox,1.0.0)
######################################## # Declarations
type rawsox_t; type rawsox_exec_t; domain_type(rawsox_t) domain_entry_file(rawsox_t, rawsox_exec_t) domain_auto_trans(unconfined_t,rawsox_exec_t,rawsox_t)
######################################## # Rawsox local policy
# these two didn't help #corenet_raw_sendrecv_all_if( rawsox_t ); #corenet_raw_sendrecv_all_nodes( rawsox_t );
require { type lib_t; type ld_so_t; type ld_so_cache_t; type usr_t; type devpts_t; type rawsox_t; type etc_t; class lnk_file read; class dir search; class file { read getattr execute }; class chr_file { read write getattr }; class rawip_socket create; class capability net_raw; }
#============= rawsox_t ============== allow rawsox_t devpts_t:chr_file { read write getattr }; allow rawsox_t etc_t:dir search; allow rawsox_t ld_so_cache_t:file { read getattr }; allow rawsox_t ld_so_t:file read; allow rawsox_t lib_t:dir search; allow rawsox_t lib_t:file { read getattr execute }; allow rawsox_t lib_t:lnk_file read; allow rawsox_t usr_t:dir search;
allow rawsox_t self:capability { net_raw setuid }; allow rawsox_t self:rawip_socket { create ioctl read write bind getopt setopt }; allow rawsox_t self:unix_stream_socket { create_socket_perms };
I have read somewhere, where I can't remember, that 2.6 kernels only allow raw sockets to be opened by root.
You may need to have a write a proxy daemon to provide access to the socket from unprivileged accounts.
-Ross
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of S Roderick Sent: Friday, March 07, 2008 4:40 PM To: CentOS mailing list Subject: Re: [CentOS] Unable open raw socket in CentOS 5 - SE Linux andkernelcapability interaction?
It runs fine under root and with sudo. S
On Mar 7, 2008, at 15:33 , Ross S. W. Walker wrote:
Does it run as 'root'?
-Ross
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of S Roderick Sent: Friday, March 07, 2008 3:28 PM To: CentOS mailing list Subject: Re: [CentOS] Unable open raw socket in CentOS 5 - SE Linux and kernelcapability interaction?
Does anyone have any idea on this one? Based on everything we've tried with kernel capabilities and SE Linux parameters, we're missing something. Have tried everything we can find online.
Thanks Stephen
On Mar 3, 2008, at 09:14 , S Roderick wrote:
I am wondering what is the interaction between SE Linux and the kernel "capabilities" in CentOS 5.1? I'm trying to open a
raw socket
and keep getting permission denied errors. I've tried using
the lcap
library to find that CAP_SETPCAP appears to be off in the kernel. For compliance reasons, I don't want to turn this on. I've also tried a hand-crafted SE Linux module policy. I have verified that the test program runs in the correct SE Linux domain and it generates no audit errors, but it still fails to open the
port with
permission denied.
It appears that SE Linux is not preventing the socket being
created
(as evidenced by the lack of audit messages), so what am I
missing?
Do I still need to modify capabilities within the program, even if I'm using an SE Linux policy?
Thanks S
Source file
#include <stdio.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <sys/prctl.h> #include <netinet/in.h>
int main(void) { int fd = socket(PF_INET, SOCK_RAW, IPPROTO_TCP); if (-1 == fd) { printf("Failed to open raw socket: %d=%s\n", errno, strerror(errno)); } else { printf("Socket opened successfully\n"); close(fd); } return 0; }
SElinux .te file
policy_module(rawsox,1.0.0)
######################################## # Declarations
type rawsox_t; type rawsox_exec_t; domain_type(rawsox_t) domain_entry_file(rawsox_t, rawsox_exec_t) domain_auto_trans(unconfined_t,rawsox_exec_t,rawsox_t)
######################################## # Rawsox local policy
# these two didn't help #corenet_raw_sendrecv_all_if( rawsox_t ); #corenet_raw_sendrecv_all_nodes( rawsox_t );
require { type lib_t; type ld_so_t; type ld_so_cache_t; type usr_t; type devpts_t; type rawsox_t; type etc_t; class lnk_file read; class dir search; class file { read getattr execute }; class chr_file { read write getattr }; class rawip_socket create; class capability net_raw; }
#============= rawsox_t ============== allow rawsox_t devpts_t:chr_file { read write getattr }; allow rawsox_t etc_t:dir search; allow rawsox_t ld_so_cache_t:file { read getattr }; allow rawsox_t ld_so_t:file read; allow rawsox_t lib_t:dir search; allow rawsox_t lib_t:file { read getattr execute }; allow rawsox_t lib_t:lnk_file read; allow rawsox_t usr_t:dir search;
allow rawsox_t self:capability { net_raw setuid }; allow rawsox_t self:rawip_socket { create ioctl read write bind getopt setopt }; allow rawsox_t self:unix_stream_socket { create_socket_perms };
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
______________________________________________________________________ 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.
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
On Mar 7, 2008, at 16:44 , Ross S. W. Walker wrote:
I have read somewhere, where I can't remember, that 2.6 kernels only allow raw sockets to be opened by root.
You may need to have a write a proxy daemon to provide access to the socket from unprivileged accounts.
-Ross
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of S Roderick Sent: Friday, March 07, 2008 4:40 PM To: CentOS mailing list Subject: Re: [CentOS] Unable open raw socket in CentOS 5 - SE Linux andkernelcapability interaction?
It runs fine under root and with sudo. S
On Mar 7, 2008, at 15:33 , Ross S. W. Walker wrote:
Does it run as 'root'?
-Ross
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of S Roderick Sent: Friday, March 07, 2008 3:28 PM To: CentOS mailing list Subject: Re: [CentOS] Unable open raw socket in CentOS 5 - SE Linux and kernelcapability interaction?
Does anyone have any idea on this one? Based on everything we've tried with kernel capabilities and SE Linux parameters, we're missing something. Have tried everything we can find online.
Thanks Stephen
On Mar 3, 2008, at 09:14 , S Roderick wrote:
I am wondering what is the interaction between SE Linux and the kernel "capabilities" in CentOS 5.1? I'm trying to open a
raw socket
and keep getting permission denied errors. I've tried using
the lcap
library to find that CAP_SETPCAP appears to be off in the kernel. For compliance reasons, I don't want to turn this on. I've also tried a hand-crafted SE Linux module policy. I have verified that the test program runs in the correct SE Linux domain and it generates no audit errors, but it still fails to open the
port with
permission denied.
It appears that SE Linux is not preventing the socket being
created
(as evidenced by the lack of audit messages), so what am I
missing?
Do I still need to modify capabilities within the program, even if I'm using an SE Linux policy?
Thanks S
Source file
#include <stdio.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <sys/prctl.h> #include <netinet/in.h>
int main(void) { int fd = socket(PF_INET, SOCK_RAW, IPPROTO_TCP); if (-1 == fd) { printf("Failed to open raw socket: %d=%s\n", errno, strerror(errno)); } else { printf("Socket opened successfully\n"); close(fd); } return 0; }
SElinux .te file
policy_module(rawsox,1.0.0)
######################################## # Declarations
type rawsox_t; type rawsox_exec_t; domain_type(rawsox_t) domain_entry_file(rawsox_t, rawsox_exec_t) domain_auto_trans(unconfined_t,rawsox_exec_t,rawsox_t)
######################################## # Rawsox local policy
# these two didn't help #corenet_raw_sendrecv_all_if( rawsox_t ); #corenet_raw_sendrecv_all_nodes( rawsox_t );
require { type lib_t; type ld_so_t; type ld_so_cache_t; type usr_t; type devpts_t; type rawsox_t; type etc_t; class lnk_file read; class dir search; class file { read getattr execute }; class chr_file { read write getattr }; class rawip_socket create; class capability net_raw; }
#============= rawsox_t ============== allow rawsox_t devpts_t:chr_file { read write getattr }; allow rawsox_t etc_t:dir search; allow rawsox_t ld_so_cache_t:file { read getattr }; allow rawsox_t ld_so_t:file read; allow rawsox_t lib_t:dir search; allow rawsox_t lib_t:file { read getattr execute }; allow rawsox_t lib_t:lnk_file read; allow rawsox_t usr_t:dir search;
allow rawsox_t self:capability { net_raw setuid }; allow rawsox_t self:rawip_socket { create ioctl read write bind getopt setopt }; allow rawsox_t self:unix_stream_socket { create_socket_perms };
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
on 3-7-2008 1:48 PM S Roderick spake the following:
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 am fairly sure of the same thing. Only root has access to raw sockets. To quote the kernel hackers guide,"To use RAW sockets in Unix it it mandatory that one be a root ." I can't see something like Selinux allowing something like this, as it is a security no-no. 2.4 I believe had an ACL patch that did something in this general area, but I don't remember how or what.
On Fri, 2008-03-07 at 16:48 -0500, 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.
<snip>
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.
S
On Sat, Mar 08, 2008 at 08:44:10AM -0500, S Roderick enlightened us:
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.
Matt
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 ...
S
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.
What are your current SELinux settings??
cat /etc/selinux/config
S Roderick wrote:
Does anyone have any idea on this one? Based on everything we've tried with kernel capabilities and SE Linux parameters, we're missing something. Have tried everything we can find online.
Thanks Stephen
On Mar 3, 2008, at 09:14 , S Roderick wrote:
I am wondering what is the interaction between SE Linux and the kernel "capabilities" in CentOS 5.1? I'm trying to open a raw socket and keep getting permission denied errors. I've tried using the lcap library to find that CAP_SETPCAP appears to be off in the kernel. For compliance reasons, I don't want to turn this on. I've also tried a hand-crafted SE Linux module policy. I have verified that the test program runs in the correct SE Linux domain and it generates no audit errors, but it still fails to open the port with permission denied.
It appears that SE Linux is not preventing the socket being created (as evidenced by the lack of audit messages), so what am I missing? Do I still need to modify capabilities within the program, even if I'm using an SE Linux policy?
Thanks S
Source file
#include <stdio.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <sys/prctl.h> #include <netinet/in.h>
int main(void) { int fd = socket(PF_INET, SOCK_RAW, IPPROTO_TCP); if (-1 == fd) { printf("Failed to open raw socket: %d=%s\n", errno, strerror(errno)); } else { printf("Socket opened successfully\n"); close(fd); } return 0; }
SElinux .te file
policy_module(rawsox,1.0.0)
######################################## # Declarations
type rawsox_t; type rawsox_exec_t; domain_type(rawsox_t) domain_entry_file(rawsox_t, rawsox_exec_t) domain_auto_trans(unconfined_t,rawsox_exec_t,rawsox_t)
######################################## # Rawsox local policy
# these two didn't help #corenet_raw_sendrecv_all_if( rawsox_t ); #corenet_raw_sendrecv_all_nodes( rawsox_t );
require { type lib_t; type ld_so_t; type ld_so_cache_t; type usr_t; type devpts_t; type rawsox_t; type etc_t; class lnk_file read; class dir search; class file { read getattr execute }; class chr_file { read write getattr }; class rawip_socket create; class capability net_raw; }
#============= rawsox_t ============== allow rawsox_t devpts_t:chr_file { read write getattr }; allow rawsox_t etc_t:dir search; allow rawsox_t ld_so_cache_t:file { read getattr }; allow rawsox_t ld_so_t:file read; allow rawsox_t lib_t:dir search; allow rawsox_t lib_t:file { read getattr execute }; allow rawsox_t lib_t:lnk_file read; allow rawsox_t usr_t:dir search;
allow rawsox_t self:capability { net_raw setuid }; allow rawsox_t self:rawip_socket { create ioctl read write bind getopt setopt }; allow rawsox_t self:unix_stream_socket { create_socket_perms };
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Bart -
Matt Hyclak -
Ross S. W. Walker -
S Roderick -
Scott Silva -
William L. Maltby