Re: netif labelling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Further to my previous post a few days ago, I found what was causing the 
AVCs when I was executing iptables to create my SELinux packet context, 
though it was not iptables to blame - it was my own fault, which boiled 
down to lack of knowledge really.

Using my previous example, if I wish to mark connections to lo:3306 with 
security context system_u:object_r:mysqld_t:s0 using the statement

iptables -t mangle -A INPUT -p tcp --dst 127.0.0.1 --dport 3306 -j 
SECMARK --selctx system_u:object_r:mysqld_t:s0

That won't work! The reason why it does not work turned out to be very 
simple - mysqld_t was already an existing type (defined with mysqld.te) 
and this type did not have the "packet_type" attribute attached to it. 
The appropriate way to use this, generally, is to create another policy 
file (or extend mysqld.te) and define another type specifically defined 
for use with packets, something like:

type mysqld_packet_t, packet_type;

With that defined when I implement the policy and execute iptables with:

iptables -t mangle -A INPUT -p tcp --dst 127.0.0.1 --dport 3306 -j 
SECMARK --selctx system_u:object_r:mysqld_packet_t:s0

all is well and the control is enforced as expected, though there is a 
'side' effect in that when I loaded the module I started getting AVCs 
for all other applications, which have their traffic unlabelled 
(basically any other application needing some sort of internet access). 
To mitigate that, temporarily, I had to include the following statement 
in the same policy file:

# Allow all unlabelled packets to all domains.
#
allow domain unlabeled_t:packet { send recv };

This is, of course, NOT secure and it will be removed as soon as I 
define the appropriate policy captures for every application, which 
needs/uses net traffic.

There is one small issue remaining, however, which I hope the more 
knowledgeable on here will help me out with!

There are 3 different attributes defined in the policy: packet_type 
(which I take it is a general-purpose, encompassing packet traffic in 
both directions), client_packet_type and server_packet_type. What I 
would like to know is when the client_packet_type and server_packet_type 
are used?

Do I define/use the server_packet_type in 'server' connections (i.e. 
when the application/process I am writing the policy for listens on a 
particular port and accepts client connections only, hence that sort of 
traffic should be defined with server_packet_type attribute - i.e. recv 
only permission)? If that is the case and I am writing a policy for the 
connecting application (which connects to the same port) do I have to 
use the same type, but the client_packet_type attribute attached to it 
and then 'send' only permission?

Without using server_packet_type and client_packet_type (utilising 
packet_type only) when writing policy for both server- and client- 
processes connecting/using the same port the general type attribute 
(packet_type) is doing the job, provided I attach the appropriate 
permissions ('send' for the client part and 'recv' for the server part) 
to the type I defined, though I am not sure if using server_packet_type 
and client_packet_type is the better way of doing it, so help would be 
much appreciated by the more knowledgeable on here!
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux


[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux