> I'll be releasing Beta-4 later in the week; you can test then. > OK, just let me know.
>> COMMENT the rest of the line will be attached as a comment to the >> Netfilter rule(s) generated by the following entries. The comment will >> appear delimited by "/* ... */" in the output of "shorewall show >> <chain>". To stop the comment from being attached to further rules, >> simply include COMMENT on a line by itself. >> >> In other words, COMMENT the command as is in the rules file - as pointed >> out in my previous post. >> > > Which is already implemented in the Alpha-level code that you have; I > just haven't gotten around to documenting it in the man pages yet. > The rpm you last sent me (two days ago I think it was) did not work as this was one of the first things I tried (I do like this feature as it gives me an instant indication of 'my' code when I look at the chains, rather than the generated stuff from iptables/Shorewall) - it gave me an error during compilation: insufficient number of columns/parameters or something. >> 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? >> > > I try to avoid adding any 'Shorewall automatically assumes ....' > features because "The vast majority of cases" is not "All cases". In > general, my approach with Shorewall has been flexibility, rather than > "works is most cases". > 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 will consider a shorewall.conf (shorewall6.conf) option as a follow-on > enhancement, but given how much more popular tcrules are than secmarks, > I would probably add the enhancement for tcrules first. > No worries, just expressing my opinion - the decision, ultimately, is for you to make, that's all. > I apologize for the rant -- I should have set your expectations when we > started. I don't run SELinux on any of my test environments and I have > no time or interest to learn how Netfilter interacts with SELinux, > except at the iptables command syntax level. I therefore needed someone > to verify that the ruleset would actually load on a SELinux-enabled > system and that the ruleset would do whatever it is intended to do. I am not SELinux expert myself either (as you've probably gathered by now!). In fact, up until about 3-4 months ago I was dead against deploying 'this monstrosity' anywhere near production environment as the headaches of dealing with security alerts would have sucked the life out of me. An incident I've had coupled with an inspiration and all the valuable help I received from genuine experts on the SELinux user list turned me around and I am now seeing the benefits of deploying such system. It is well worth it and I would advice anyone interested in SELinux to invest and spend some time to learn about it! Anyway... > So I > sent you the very first code that I produced in an effort to ensure that > the iptables-restore input produced by Shorewall will actually load and > work. I sent you a second RPM because the change you suggested to add a > USER/GROUP column involved several files and would have been hard for > you to install as a patch. > The fix you've developed does its job, and even though there are a few 'rough edges' the core of it is done, which was the main point of me starting this thread and doing the testing later on. > My ill-conceived rant was my way of pointing out that getting code that > works is only a small part of what is required to produce a complete and > supportable product. There is a lot that needs to be done after the code > apparently works before the product can be considered complete. I concur and it was never my intention to suggest otherwise! If it came out differently - well, it would be my turn to apologise! > So > please bear with me; when Beta 4 is finally released, *then* please send > me feedback about missing examples and incomplete documentation. > No worries, just let me know and I'll give it a go again. ------------------------------------------------------------------------------ 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
