> Please look at the example in the manpage from the updated RPM;
> hopefully, it will make this clearer. You might also consult the SELinux
> documentation about how to use the CONNSECMARK target.
>
My observations after applying the latest changes (I'll start with the
bugs):
1. When I put "system_u:object_r:voip_sandbox_packet_t:s0 I:N
eth1:212.12.176.12 - tcp 8006 - root" for example this compiles to and
produces "-A tcin -m conntrack --ctstate NEW -p 6 --dport 8006 -m owner
--uid-owner root -i eth1 -s 212.12.176.12 -j SECMARK --selctx
system_u:object_r:voip_sandbox_packet_t:s0", which, when executed with
iptables gives me the following error: "kernel: ip_tables: owner match:
used from hooks INPUT, but only valid from OUTPUT/POSTROUTING".
I presume the same rules apply as in the /etc/shorewall/rules, i.e. NO
UID/GID in the incoming chains (net->fw for example), so this needs to
be corrected.
2. Currently there is no ability to add comments in secmarks - it would
be nice if I could do that as is the case with the rules file (I am not
sure if the Shorewall adds comments automatically in secmarks as is the
case with the rules file - when common port numbers are used for example).
3. The example given in shorewall-secmarks uses SELinux type "mysqld_t",
which even though works, it WILL fail when this is run for the simple
reason that this type is already defined and it does not contain the
appropriate SELinux attributes ("packet_type", "server_packet_type" or
"client_packet_type"). Type "mysqld_t" is dedicated to the MySQL Daemon
domain - not its packets. The appropriate type to use in the example
given would be something like "mysqld_packet_t", so the appropriate
security context for mysqld packets would therefore be
"system_u:object_r:mysqld_packet_t:s0".
4. CONNSECMARK - that was a true eye opener for me!!!
Having now examined, in great detail, how this mechanism works and then
seeing it in action I am well-pleased I took the time to learn about
this, because it makes a huge amount of difference - both from a point
of view of security as well as performance. I am also ready to make a
few suggestions for "optimisation" of Shorewall in this regard.
The SAVE command, in vast majority of cases, makes sense to be executed
LAST in the NEW packets chain and WITHOUT any additional restrictions,
i.e. "SAVE I:N" or "SAVE O:N". This would save any SELinux context for
which there was a match in the previous secmarks statements for this
chain type. So, if that is the case, why not integrate it with the
optimisation mechanism which exist in Shorewall - it could be specified
to be included as an end statement of each chain in the NEW section
without being explicitly declared in the secmarks file.
Exactly the same would apply for RESTORE as well, but with ESTABLISHED
and RELATED type packets.
The reason I am pushing for this is because I just experienced first
hand what impact this mechanism has, particularly on performance - I
used it to push VOIP traffic to an external server and with SAVE/RESTORE
it is faster - a lot faster! Not to mention that I do not need to worry
about security implications as that is not an issue any more -
connections are tracked and SELinux contexts are re-established
'automatically' so to speak.
5. Just a direction of thought for now - I am a bit uncomfortable with
the "CHAIN" column in secmarks - it would be nice if the secmarks file
could be adapted to have sections in the same way as is in the rules
file (like SECTION NEW, SECTION ESTABLISHED etc) - it would make it more
consistent. Don't know whether that would be possible though.
6. Finally, two minor bits, which I am sure will be ironed out by the
time the new version of Shorewall is released - it would be good to have
a 'sample' secmarks file in the distribution and all man-pages (except
shorewall-secmarks) need to reference shorewall-secmarks as is done with
all the other sections of the manual.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
