On 9/6/10 3:28 PM, Mr Dash Four wrote: > >> 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.
Done. > > 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). COMMENT is supported in the secmarks file. See http://www.shorewall.net/configuration_file_basics.html#COMMENT > > 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". It was your example, not mine. See the post that started this thread. I know nothing about SELinux. But I've updated the manpages. > > 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. So exactly what are you pushing for? > 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. It's possible but it's not going to happen. > > 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. That's not going to happen either. <rant> This is basically a one-man project. I get excellent help from a group of people that produce packages for various distributions and that help with support. But I produce almost all of the code and documentation. And writing code is about 20% of my time spent on Shorewall; the rest is support, writing documentation, and answering posts like yours. </rant> -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
