On 9/10/10 4:08 AM, Mr Dash Four wrote: > >>>>> 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.
My point is that the save/restore rules are 2 LINES per chain, no matter how simple or complex the other entries are; a reasonably-written HOWTO can explain where to put them such that even the dimmest admin can get that part right. I'm talking about the rules for the various applications themselves. Something akin to the scripts found at http://people.redhat.com/jmorris/selinux/secmark/. > > 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? That display is not produced by Shorewall; you can get exactly the same thing using the command 'cat /proc/net/ip_conntrack'. There may be something in /proc that allows the requested translation; patches cheerfully accepted. -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
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
