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
