Bug 249764 - SELinux interfered with wireless nic acquiring address from dhcp server
Summary: SELinux interfered with wireless nic acquiring address from dhcp server
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 7
Hardware: i686
OS: Linux
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-26 21:12 UTC by David Thurston
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-08-14 12:32:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
SELinux Alert file (2.12 KB, text/plain)
2007-07-26 21:12 UTC, David Thurston
no flags Details

Description David Thurston 2007-07-26 21:12:01 UTC
Description of problem:
I used RuTilt to attach my RT61 based wireless nic to my local private netrwork,
and got an SELinux alert.

Version-Release number of selected component (if applicable):


How reproducible:
Using RuTilt configure nic to attach to private local non-broadcasting network
and and aquire an address from dhcp server on gateway. Apply the profile.


Steps to Reproduce:
1.
2.
3.
  
Actual results:
Got SELinux alert and nic eventually acquired an address.

Expected results:
No SELinux alert and nic aquires address.

Additional info:

Comment 1 David Thurston 2007-07-26 21:12:01 UTC
Created attachment 160075 [details]
SELinux Alert file

Comment 2 Daniel Walsh 2007-08-14 12:32:02 UTC
I think the best thing to do here would be for you to add these rules directly.

grep dhpc /var/log/audit/audit.log | audit2allow -M mydhcp
semodule -i mydhcp.pp


Comment 3 David Thurston 2007-08-14 20:38:52 UTC
Yes, once I figured out how to use audit2allow I added a module for the RutilT
utility. I also built a module for SWAT (Samba Web Administrative Tool) if any
one needs it. I must say that SELinux is a royal pain. It took me Hours to build
the Module for SWAT using Audit2allow, because the avs denials came layer after
layer: I'd get one set of denials allowed only to be confronted with another set
of newly exposed requests. I can't believe that nobody has done a module for
SWAT. Is it now the responsibility of the programmer to provide an SELinux
module for their software? Would you trust such a module? Sounds like we're
asking for someone to build a backdoor to SELinux and "Package" it with some
useful utility or such. Open source or no, who has time (or the knowledge) to
check every SELinux module provided?

Is there an easier way?

Comment 4 Daniel Walsh 2007-08-15 00:49:34 UTC
There is a policy for swat.  What was the path to the swat executable?

THe swat policy comes with the samba policy.  

# ls -lZ /usr/sbin/swat 
-rwxr-xr-x  root root system_u:object_r:swat_exec_t    /usr/sbin/swat


Comment 5 David Thurston 2007-08-16 16:12:26 UTC
[root@Service ~]# whereis swat
swat: /usr/sbin/swat /usr/share/swat /usr/share/man/man8/swat.8.gz
[root@Service ~]# ls -lZ /usr/sbin/swat
-rwxr-xr-x  root root system_u:object_r:swat_exec_t    /usr/sbin/swat
[root@Service ~]# 


Here is the swat.te I had to build in order for SELinux to stop complaining:

module swat 1.0;

require {
	class capability { sys_resource net_bind_service };
	class dir { write add_name create setattr remove_name };
	class file { lock read getattr create write execute_no_trans unlink setattr
rename };
	class process { signal signull setrlimit };
	class sock_file { create unlink };
	class tcp_socket name_bind;
	class udp_socket name_bind;
	class unix_stream_socket connectto;

	type initrc_var_run_t;
	type nmbd_exec_t;
	type nmbd_port_t; 
	type nmbd_t;
	type nmbd_var_run_t; 
	type samba_log_t; 
	type samba_secrets_t; 
	type samba_var_t; 
	type smbd_exec_t; 
	type smbd_port_t; 
	type smbd_t;
	type smbd_var_run_t; 
	type swat_t; 
	type winbind_exec_t; 
	type winbind_var_run_t; 

	role system_r; 
};
allow swat_t initrc_var_run_t:file { read write };
allow swat_t nmbd_exec_t:file execute_no_trans;
allow swat_t nmbd_port_t:udp_socket name_bind;
allow swat_t nmbd_t:process { signal signull };
allow swat_t nmbd_var_run_t:file { lock read unlink };
allow swat_t samba_log_t:dir { write add_name create setattr };
allow swat_t samba_log_t:file { create getattr };
allow swat_t samba_secrets_t:file { read write lock getattr setattr };
allow swat_t samba_var_t:dir { write add_name remove_name };
allow swat_t samba_var_t:file { read getattr create lock write setattr rename
unlink };
allow swat_t self:capability { sys_resource net_bind_service };
allow swat_t self:process setrlimit;
allow swat_t self:unix_stream_socket connectto;
allow swat_t smbd_exec_t:file { execute_no_trans read };
allow swat_t smbd_port_t:tcp_socket name_bind;
allow swat_t smbd_t:process signal;
allow swat_t smbd_var_run_t:file { lock unlink };
allow swat_t winbind_exec_t:file { execute_no_trans read };
allow swat_t winbind_var_run_t:dir { write add_name remove_name };
allow swat_t winbind_var_run_t:sock_file { create unlink };


Most of this had to do withy starting and stoping smbd, nmbd, and winbind using
SWAT.


Comment 6 Daniel Walsh 2007-08-20 21:39:56 UTC
I am not sure this is correct.  If swat is simply restarting the daemons then
you probably need something like

domtrans_pattern(swat_t, winbind_exec_t, winbind_t)
domtrans_pattern(swat_t, nmbd_exec_t, nmbd_t)
domtrans_pattern(swat_t, smbd_exec_t, smbd_t)


Note You need to log in before you can comment on or make changes to this bug.