>>>> Instead of manually adding "SAVE I:N", "SAVE O:N" and then "RESTORE >>>> I:ER", "RESTORE O:ER" etc. at the end of each chain (as this would be >>>> the most efficient way of dealing with SELinux contexts once they are >>>> established) it would be nice if these things are 'optimised' and added >>>> automatically by Shorewall when an appropriate option is turned on in >>>> shorewall.conf (like "AUTO_CONNSECMARK=Yes" for example) so that I do >>>> not have to put these manually. >>>> >>>> As I already pointed out - in vast majority of cases SAVE and RESTORE >>>> would make sense to be placed in the above form at the end of each chain >>>> so that they take care of preserving and restoring SELinux contexts in >>>> connections, so why not add them automatically? >>>> >> Flexibility indeed! Hence why I suggested that you could add an option >> (or include it as another optimisation level as you currently do with so >> many other things on Shorewall) and let Shorewall users decide what to use. >> >> Another reason for this is that mistakes with SAVE and RESTORE are >> *very* easy to make as I found out to my own cost (using SAVE >> "I:N"/"RESTORE I:ER" with attaching additional parameters - ports etc - >> which is an absolute rubbish thing to do!) - hence if I know that my >> network deploys SELinux (which is what I aim for really) and all network >> traffic is controlled I just switch this option on, Shorewall attaches >> SAVE/RESTORE statements at the end of each CHAIN 'automatically' and the >> only thing I need to concentrate on, as far as secmarks are concerned, >> is defining the SELinux contexts for the traffic I am controlling. >> >> For others, who do not need/do not want to use this approach and prefer >> to do everything 'manually' they can switch this option off and get on >> with it without additional hassle. Very much like the optimisation >> levels you have currently built in Shorewall. >> >> You don't take anything away, on the contrary - you provide flexibility >> and keep everyone happy! >> > > I wonder if a better way to approach this might be with "secmark > macros"; canned blocks of rules that can be invoked easily. > If by that you mean macros like 'Ping', 'Drop' etc I don't see much benefit in doing that.
My understanding of how SAVE/RESTORE works is that it makes sense to include SAVE at the end of each chain when STATE=NEW (statement like 'SAVE X:N') - at the very end where all SECMARK rules are specified; and use RESTORE also at the end of each chain when STATE=ESTABLISHED, RELATED (statement like 'RESTORE X:ER') for the SELinux context to be restored to its (previously) saved state on already established connections. With macros, as far as I know, you can include them anywhere, so it defeats the whole purpose - I may as well put the actual statement (which isn't very long as you can see from above) instead of using a macro. The benefit of 'automatically' (for want of better word) including SAVE/RESTORE in the way I listed above is to 'automatically' save and restore the SELinux context state and allow people like my to concentrate on writing down the actual SECMARK rules. Again, with an option (may be in the shorewall.conf) this behaviour could be switched on/off as desired so that nobody feels excluded or 'boxed-in'. > We really should take this discussion onto the Development Mailing List. > Just did and slightly altered the title of the thread - feel free to move/alter this as desired! As an aside question - when I list my active connections (with 'shorewall show connections') I get the secmark field, but it is numerical (something like 'secmark=xxx'). Is it possible to somehow convert this numerical value to the actual security context I specified so that I can trace which is which? ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
